bzr version-info is accessing bound branch location

This is fallout from fixing bug 230903, and also fulfilling the behaviour bug 148030 asks for. But bug 882541 shows it's still causing pain.

I see two possible approaches for resolving this issue:

1) When creating a bound branch, get the explicit or implied remote nick, and set it as the explicit local nick. This means it won't then requery for it each time, at the cost of not detecting if the remote branch's nick changes. It also won't fix the issue for people who've already created bound branches, they'll want to set the nick explictly themselves.

2) In version_info rather than doing `self._branch.nick` do `self._branch._get_nick(local=True)` which has basically the same effect as the above, but leaves the slow nick fetch problem around for other commands. It also may surprise some people by starting to return the name of the local directory rather than whatever the remote branch has as the nickname.

1 seems sensible to me. Perhaps update should also make sure that the local branch has the same nick as the remote branch?

Cheers, jelmer

Martin Packman <email address hidden> wrote:

>This is fallout from fixing bug 230903, and also fulfilling the
>behaviour bug 148030 asks for. But bug 882541 shows it's still causing
>pain.
>
>I see two possible approaches for resolving this issue:
>
>1) When creating a bound branch, get the explicit or implied remote
>nick, and set it as the explicit local nick. This means it won't then
>requery for it each time, at the cost of not detecting if the remote
>branch's nick changes. It also won't fix the issue for people who've
>already created bound branches, they'll want to set the nick explictly
>themselves.
>
>2) In version_info rather than doing `self._branch.nick` do
>`self._branch._get_nick(local=True)` which has basically the same
>effect
>as the above, but leaves the slow nick fetch problem around for other
>commands. It also may surprise some people by starting to return the
>name of the local directory rather than whatever the remote branch has
>as the nickname.
>
>** Changed in: bzr
> Importance: Low => Medium
>
>--
>You received this bug notification because you are a member of
>bzr-core,
>which is subscribed to Bazaar.
>https://bugs.launchpad.net/bugs/629150
>
>Title:
> bzr version-info is accessing bound branch location
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/bzr/+bug/629150/+subscriptions

--
Sent from my phone. Please excuse my brevity.

> 1 seems sensible to me. Perhaps update should also make sure that the local branch has the same nick as the remote branch?

Making update ensure that the local branch has the same nick as the remote branch is going to be an incompatible change for those users who already manually set the local branch nickname, no? I think without introducing an extra field in branch.conf you can't distinguish between "this nickname has been set on checkout to avoid talking to the server" and "this nickname has been set by the user". So the following sequence could have unexpected (to the user) results:

# lp:foo has nickname "foo-trunk"
$ bzr checkout lp:foo
$ cd foo
$ bzr nick
foo-trunk
# set local nickname
$ bzr nick foo-local
$ bzr update
$ bzr nick
foo-trunk
# huh?

Am 17/11/11 11:02, schrieb Lawrence Mitchell:
>> 1 seems sensible to me. Perhaps update should also make sure that the
> local branch has the same nick as the remote branch?
>
> Making update ensure that the local branch has the same nick as the
> remote branch is going to be an incompatible change for those users who
> already manually set the local branch nickname, no? I think without
> introducing an extra field in branch.conf you can't distinguish between
> "this nickname has been set on checkout to avoid talking to the server"
> and "this nickname has been set by the user". So the following sequence
> could have unexpected (to the user) results:
For all other uses, the local branch is considered the equivalent of the
master branch - it is just a local convenience copy of it. "bzr up"
takes care of making sure that the local branch is in sync with the
master branch - I think the branch nick should be part of that.

I realize it is possible to set a local nick that diverges from the
master branch at the moment, but I would argue that the fact that it can
diverge at the moment is an implementation flaw.

Perhaps we should ask a different question. What is the use case for
allowing local branch nicks that diverge from the master branch?

Cheers,

Jelmer

tor 2011-11-17 klockan 11:41 +0000 skrev Jelmer Vernooij:

> Perhaps we should ask a different question. What is the use case for
> allowing local branch nicks that diverge from the master branch?

Can't think of any. But then I do not see much uses of branch nicks in
that context other than to unify different developers local branch
naming styles to a common project-wide model in the recorded history.

But probably not a good idea to add additional operations to "bzr
update" unless really needed.

branch nicks change very infrequently, and are not version controlled.

I think a reasonable compromize is to have "bzr bind" always set the
local branch nick, not only if the local branch already have a nick (how
it works today)

another note is that it seems it's very hard to remove the nick from a
branch. You can set it to the same as the default value, but it's still
a nick and bzr bind will kindly overwrite it at any time you bind the
branch.

A related question is what do do with the nick on "bzr unbind".

My suggestion is to

a) Change "bzr bind" to always record the nick of the master branch at
the time.
b) Add a "bzr nick --clear" option to remove any nick from a branch

and document that the branch nick is not cleared automatically on "bzr
unbind" or updated unless you "bzr bind" again.

If there is other more creative uses of branch nicks then the branch
nick concept as such probably needs an upgrade, making it a versioned
property somehow.

Regards
Henrik

Am 17/11/11 14:08, schrieb Henrik Nordström:
> tor 2011-11-17 klockan 11:41 +0000 skrev Jelmer Vernooij:
>
>> Perhaps we should ask a different question. What is the use case for
>> allowing local branch nicks that diverge from the master branch?
>
> Can't think of any. But then I do not see much uses of branch nicks in
> that context other than to unify different developers local branch
> naming styles to a common project-wide model in the recorded history.
>
> But probably not a good idea to add additional operations to "bzr
> update" unless really needed.
Why would it be a bad idea to not have "bzr update" update the branch nick?

Making sure the brach nick of the local branch is updated to the master
branch nick is a lot simpler than having to explain in what situations
the branch nick is updated.

Cheers,

Jelmer

tor 2011-11-17 klockan 13:46 +0000 skrev Jelmer Vernooij:

> Why would it be a bad idea to not have "bzr update" update the branch nick?

a) bzr update is something done often. and adding new network operations
to update should be avoided. Especially when the result of that
operation will in ca 99.999% of all cases be the same as when binding
the branch.

b) forcing nick updates so forces a new branch nick management compared
to earlier releases, while the proposed change only makes bound brances
inherit their nick by default, without changing existing branches.

my main concern is 'a', but see a risk that 'b' may affect some people.

Regards
Henrik

Am 17/11/11 18:00, schrieb Henrik Nordström:
> tor 2011-11-17 klockan 13:46 +0000 skrev Jelmer Vernooij:
>
>> Why would it be a bad idea to not have "bzr update" update the branch
> nick?
>
> a) bzr update is something done often. and adding new network operations
> to update should be avoided. Especially when the result of that
> operation will in ca 99.999% of all cases be the same as when binding
> the branch.
The nick name is stored in the branch configuration file of the master
branch, which will be read in its entirety anyway. There is no extra
overhead in always checking the branch nick.

> b) forcing nick updates so forces a new branch nick management compared
> to earlier releases, while the proposed change only makes bound brances
> inherit their nick by default, without changing existing branches.
>
> my main concern is 'a', but see a risk that 'b' may affect some people.
The question is whether we want to support local branches having a
different nick. I don't think we do, since bound branches behave as
perfect copies of the master branch in all other regards. If we do want
to make it possible for local branch nicks to diverge, we should not set
the local branch nick during bind (since not having the nick set would
mean "use whatever the master branch nick is"). If do we want to keep
the local and master branch nicks in sync, I think we should do it
whenever we sync with the master branch.

If we only set the branch nick on bind, then that also means that people
who do have a local branch at the moment without a nick set explicitly
will lose their branch nick. This is because we would stop checking the
master branch nick on all operations but "bzr update".

Cheers,

Jelmer