bzr whoami --branch on lightweight checkout changes whoami settings for everyone

I think it's a dupe of my old bug where I've suggested that for light checkout whoami should be set not at the master branch level but at the local working tree level. Unfortunately there is no tree.conf yet.

I agree with Alexander, commits are created from a working tree, it makes sense to define the committer at the tree level rather than at a branch level.

Is there a workaround for this ... i.e to remove the --branch whoami setting on the server?

Craig Hewetson пишет:
> Is there a workaround for this ... i.e to remove the --branch whoami
> setting on the server?
>
like edit branch.conf on the server? using hitchhicker?

--
All the dude wanted was his rug back

Well I removed the email="blah@blah" line from the branch.conf... Will using the "hitchhicker" be an better improvement to avoid this from happening until its fix?

What would be the best way to solve this problem? I'm willing to implement a patch, if the solution is not too complicated and if its agreed upon before the time.

Maybe another solution is to have another branch.conf file locally and if bzr finds one locally it will make use of it (for certain fields i.e author).

There are other problems because of this bug and one of them is when you run bzr info, the submit branch location (amongst others) gets changed when a developer commit code ...

I think the easiest way to solve the problem is to clarify what you want to share in branch.conf with the other branch users.
Obviously you *don't* want to share the email, so don't set it there. Instead, define it in locations.conf in a section specific to your branch or at any level that allow you reuse it for several branches.

That may not be ideal but seems like the best you can achieve until we rework the internal config which is a pre-requisite to implementing tree.conf. One could argue that the local branch.conf should take precedence over the master branch.conf for the email configuration option but while you can try to write a patch for that against the current code base, I'm not sure the result will be pretty (and will be confusing for users to always remember which option is set where).

Great, I manually added the email under a specific location within the locations.conf file and it worked.

So basically I must change "bzr whoami --branch" to add an entry in the locations.conf file when there is no local branch.conf file present (determining that will be interesting)?

>>>>> Craig Hewetson <email address hidden> writes:

    > Great, I manually added the email under a specific location within the
    > locations.conf file and it worked.

    > So basically I must change "bzr whoami --branch" to add an entry in the
    > locations.conf file when there is no local branch.conf file present
    > (determining that will be interesting)?

Hmm, no. THere *are* valid use cases to set 'email' in branch.conf so
'bzr whoami' shouldn't be changed in this respect.

IMHO, the problem here is that setting 'email' in branch.conf for
*lightweight' checkout can confuse users.

What is your use case here ?

>
> Hmm, no. THere *are* valid use cases to set 'email' in branch.conf so
> 'bzr whoami' shouldn't be changed in this respect.
>

IMHO, the problem here is that setting 'email' in branch.conf for
> *lightweight' checkout can confuse users.
>
> What is your use case here ?
>
> The same use case for having multiple authors:
Contractors need to commit code from the same machine (eg: laptop) to
multiple projects with different email addresses.

For me:
When I contribute to opensource projects I use my gmail account and when at
work I use my work email address for our in-house projects.
I don't want to have my work address accidentally used in other projects and
visa versa.

We make use of lightweight checkouts at work (especially for "release"
branches).
So what I do, is set my default whoami as my gmail address and then for each
light weight checkout, I set it to my work address using the --branch
option.

BTW: Light weight checkouts are really starting to get important for us,
since our code history is almost 400MB big and its getting bigger every
month.

>>>>> Craig Hewetson <email address hidden> writes:

<snip/>

    > Contractors need to commit code from the same machine (eg: laptop)
    > to multiple projects with different email addresses.

    > For me:
    > When I contribute to opensource projects I use my gmail account and when at
    > work I use my work email address for our in-house projects.
    > I don't want to have my work address accidentally used in other projects and
    > visa versa.

Yup, so the best solution for this is indeed locations.conf.

    > We make use of lightweight checkouts at work (especially for
    > "release" branches). So what I do, is set my default whoami as my
    > gmail address and then for each light weight checkout, I set it to
    > my work address using the --branch option.

Which, as you discover, doesn't work, since in this case the *remote*
branch.conf is modified, i.e. the branch is shared by all the
lightweight checkouts that point to it.

Note that sections are inherited when you use locations.conf so if you
stup your work env like:

  /home/craig/proj1/~/proj1
  /home/craig/proj1/lightweightco1
  /home/craig/proj1/lightweightco2
  /home/craig/proj2
  /home/craig/proj2/lightweightco1
  /home/craig/proj2/lightweightco2

You can put in locations.conf:

[/home/craig/proj1]
email = craig@proj1
[/home/craig/proj2]
email = craig@proj2

And all checkouts will inherit the right config option.

http://doc.bazaar.canonical.com/latest/en/user-reference/configuration-help.html#the-branch-location-configuration-file-locations-conf

On 25 October 2010 05:54, Vincent Ladeuil <email address hidden> wrote:
>>>>>> Craig Hewetson <email address hidden> writes:
>
>    > Great, I manually added the email under a specific location within the
>    > locations.conf file and it worked.
>
>    > So basically I must change "bzr whoami --branch" to add an entry in the
>    > locations.conf file when there is no local branch.conf file present
>    > (determining that will be interesting)?

I think the correct fix here would be to add a tree.conf. Is that very hard?

--
Martin

tree.conf it is...

About tree.conf:
1) When should there be a tree conf? (whenever there is a working tree?)
2) What configuration settings should it contain? (email and xx?)
3) When and what should read/write from/to tree.conf? (bzr whoami, xx?)
4) Is there documentation that would need to be written (like the webpage that Vincent posted)
5) Am I missing something?

This is why I find it a bit tricky to implement. (besides not knowing bzr source as well as I would like)

If someone doesn't have the time to write the code, I'll give it a shot, but someone might have to take the time to clarify the questions so I know exactly what it is that I need to implement.

BTW: Thanks for giving this bug attention.

On 26 October 2010 15:50, Craig Hewetson <email address hidden> wrote:
> tree.conf it is...
>
> About tree.conf:
> 1) When should there be a tree conf? (whenever there is a working tree?)

yes

> 2) What configuration settings should it contain? (email and xx?)

Just getting user id should be ok to start with; you could search the
other configuration items that would be good to add.

> 3) When and what should read/write from/to tree.conf? (bzr whoami, xx?)

Off the cuff I think if it exists, it should override everything, but
probably whoami should by default override tree.conf. You could start
an rfc thread with a proposal.

> 4) Is there documentation that would need to be written (like the webpage that Vincent posted)

It should at least be mentioned in the 'configuration' section of the
user guide, and in the configuration help topic.

> 5) Am I missing something?
>
> This is why I find it a bit tricky to implement. (besides not knowing
> bzr source as well as I would like)
>
> If someone doesn't have the time to write the code, I'll give it a shot,
> but someone might have to take the time to clarify the questions so I
> know exactly what it is that I need to implement.

We can help; don't hesitate to ask. (Sorry i was slow to reply; I'm
at UDS this week.)

If you look at BranchConfig this should be very similar.

--
Martin

Thanks for the feedback ...

It might take me awhile to do this, since I don't get much free time to
code...