Multiple whoami?

[Eric Berry]

Hi all, I was working on my demonstration to my team when I came up with an
interesting idea.

Occasionally developers will pair up (not quite pair programming, but close)
and work on a project together, or do a quick code review together.

I noticed that I can set the bzr whoami to a "pair" of users:
[code]
bzr whoami "Eric Berry <***@gmail.com>, Joe Smith <***@example.com>"
[/code]

This succeeds in setting the whoami to the full string, but when I use the
--email option, I only get the first entry.

One interesting point I was going to make to my team was the separation
between storage and identity. Meaning, I have a separate user/password for
my ftp server (where the repo is hosted), and my bzr whoami value. This is a
nifty feature in that it allows the creation of a branch or checkout
specific to the paired work done, as well as a separate identity for that
specific branch/checkout.

Would it be a terrible feature request to have BZR accept multiple email
addresses for the whoami configuration?

Thanks,
Eric

[Aaron Bentley]

Post by Eric Berry
Would it be a terrible feature request to have BZR accept multiple email
addresses for the whoami configuration?

Supporting this properly would be a lot of work. I don't think it's
worth it.

Aaron

[Eric Berry]

Ah. Ok.

How exactly is the whoami property used? Is it for automatically sending
patches to?

In the case where I have supplied to email addresses, would only the first
one be used, or would having two actually break something?

Thanks,
Eric

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Eric Berry
Would it be a terrible feature request to have BZR accept multiple email
addresses for the whoami configuration?

Supporting this properly would be a lot of work. I don't think it's
worth it.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmjIzQACgkQ0F+nu1YWqI26ZwCffmJiqXsjxvJZZ+VREjR7TUQL
sdsAn2LLiC2B1tbDVjseIJjU+gaHi2t3
=n+Oh
-----END PGP SIGNATURE-----

[Aaron Bentley]

Post by Eric Berry
How exactly is the whoami property used?

It's stored as the "committer" attribute of the revision. That field is
expected to contain a single emai-id, of the format "Firstname Lastname

Post by Eric Berry
Is it for automatically sending patches to?

No, it is for tools and people to identify authors.

Post by Eric Berry
In the case where I have supplied to email addresses, would only the
first one be used, or would having two actually break something?

It will break things.

Aaron

[Jelmer Vernooij]

Post by Eric Berry
Hi all, I was working on my demonstration to my team when I came up with an
interesting idea.
Occasionally developers will pair up (not quite pair programming, but close)
and work on a project together, or do a quick code review together.
[code]
[/code]
This succeeds in setting the whoami to the full string, but when I use the
--email option, I only get the first entry.

It sounds like you would like to be able to have more than one author
recorded for a commit (as opposed to more than one committer). See this
bug report:

https://bugs.edge.launchpad.net/bzr/+bug/185772

Cheers,

Jelmer

[Eric Berry]

Ah Cool! I didn't know about the --author option.

This will work. This option's value isn't used in anything where it needs to
be a single value right?

I don't mind setting the whoami value to whoever is actually doing the
committing, and have the author option take the names of the actual authors.

Is there a way to set a default value on a per branch basis?

Thanks for all the help!
Eric

Post by Eric Berry

Post by Eric Berry
Hi all, I was working on my demonstration to my team when I came up with

an

Post by Eric Berry
interesting idea.
Occasionally developers will pair up (not quite pair programming, but

close)

Post by Eric Berry
and work on a project together, or do a quick code review together.
[code]
[/code]
This succeeds in setting the whoami to the full string, but when I use

the

Post by Eric Berry
--email option, I only get the first entry.

It sounds like you would like to be able to have more than one author
recorded for a commit (as opposed to more than one committer). See this
https://bugs.edge.launchpad.net/bzr/+bug/185772
Cheers,
Jelmer

[Aaron Bentley]

Post by Eric Berry
Ah Cool! I didn't know about the --author option.
This will work. This option's value isn't used in anything where it
needs to be a single value right?

Sure it is. Launchpad, for example.

Aaron

[Eric Berry]

K. So bottom line is, bzr doesn't currently support multiple authors or

[Colin D Bennett]

On Mon, 23 Feb 2009 15:32:14 -0800

Post by Eric Berry
K. So bottom line is, bzr doesn't currently support multiple authors or
committers.

I've been trying to get my team at work excited about switching from
their crummy proprietary VCS tool to Bazaar, and supporting multiple
authors would really be a huge win in their eyes. We do Agile/XP and a
pair programming, and this would be really cool to have.

Regards,
Colin

[Tim Penhey]

Post by Aaron Bentley

Post by Eric Berry
Ah Cool! I didn't know about the --author option.
This will work. This option's value isn't used in anything where it
needs to be a single value right?

Sure it is. Launchpad, for example.

Is this the get_aparent_author stuff?

Launchpad uses this to attribute the revision to an individual and allocates
them some karma :)

Tim

[Robert Collins]

Post by Tim Penhey

Post by Aaron Bentley

Post by Eric Berry
Ah Cool! I didn't know about the --author option.
This will work. This option's value isn't used in anything where it
needs to be a single value right?

Sure it is. Launchpad, for example.

Is this the get_aparent_author stuff?
Launchpad uses this to attribute the revision to an individual and allocates
them some karma :)

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.

-Rob

[James Westby]

Post by Robert Collins
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

[John Arbash Meinel]

...

Post by James Westby
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.

I would change 'author' to allow multiple fields with '\n' as the
separator. Then update 'get_apparent_author' to return one value but
deprecate it. And add 'get_apparent_authors()' which returns a list.

Post by James Westby
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

John
=:->

[Aaron Bentley]

Post by Tim Penhey

Post by Aaron Bentley

Post by Eric Berry
Ah Cool! I didn't know about the --author option.
This will work. This option's value isn't used in anything where it
needs to be a single value right?

Sure it is. Launchpad, for example.

Is this the get_aparent_author stuff?

Yes.

Aaron