Multiple whoami?

[James Westby]

On Tue, 2009-02-24 at 19:57 +1100, Robert Collins wrote:
> Sounds like a case where multiple authors would make sense :) Andrew and
> I would have liked to do this for the last week or so while we've been
> pairing heavily, I think.

I want to extract this information from the debian/changelog where it
is often recorded in a structured way to accredit the change to multiple
people.

Basically, I want this too, and I want this now. Rather than implement
my own multi value revision property for the extra authors I would 
prefer to fix this in bzr.

I'd like some guidance on the best way to do this.

We could make the "author" property multi-value using a "\n" separator
or something that is unlikely to be in any existing revision properties,
and then define that the result of "get_apparent_author" should be
split on this character to get the list of authors.

That of course comes with a risk of breaking existing things. We could
invent a new multi-value property, e.g. "other-authors" and put any
overflow in there. Then we can add "get_apparent_authors" that knows
what to do.

The other alternative as I see it is to have lots of author revision
properties. We can have "author", "author2", "author3", etc. It's not
very cute, but it avoids the need to reject a single character in the
author string, and doesn't risk breaking existing users of the property.

We could have a "author-count" property as well that would save some
"while author_num in revision.properties:" code, but adds duplication.

What's the best way for me to approach this?

Thanks,

James