Confusion over locations

[Aaron Bentley]

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

Barry Warsaw wrote:
> Aaron went on to explain that afahk,
> submit_branch was used by merge, send, pqm-submit, '-r submit:' and an
> internal review-submit plugin.

I suppose I should also add that for at least 4 of these,
submit-location is used due to my influence :-)

>'help merge'
> does say: "If neither is specified, the default is the upstream branch
> or the branch most recently merged using --remember".  Well, I would
> have thought the "upstream branch" would be the parent branch by
> default, or my-shared-repo in the example above.

merge previously did use the parent branch, and when I changed it, I
should have updated that documentation.  My apologies.

> Further, it's confusing to me that 'bzr merge' uses submit_branch but
> 'bzr pull' uses parent_branch.  In my own mental model of Bazaar, these
> two commands would calculate their default locations in exactly the same
> way.  Why is my model wrong?

Merge and pull are designed for two different relationships.

Pull is for mirrors-- a relationship where one branch is a copy of
another.  A good example would be my local mirror of bzr.dev.  You
should always pull into a mirror, never merge into it.  If you updated
by merging, then you'd have to commit, and then you'd have a diverged
branch, not a mirror.

Merge is for diverged branches.  A good example would be my "bzr.ab"
branch, where I put fixes too small to merit their own branch.  You
should always merge into a branch, never pull into it.  If you pulled
into it and it succeeded, your local branch would become a mirror.  You
would lose your local point-of-view, so that log would no longer prefer
the revisions you'd committed, and their revnos would become dotted revnos.

Can a branch be in both relationships at the same time?  Absolutely.  A
good example would be "bzr.ab", before I worked at Canonical.  I had a
copy on my computer at home, and a copy on my computer at work.  I would
use "pull" to mirror my changes from one computer to another.  And I
would use "merge" to integrate the latest changes from (my local mirror
of) bzr.dev.  I think this is not an uncommon situation.

So that is why "pull" and "merge" do and should have different locations.

> ISTM that the most logical default
> location for 'bzr merge' is in fact parent_location, and that's almost
> always what I want.  Having to always override it is an annoying speed
> bump.

You shouldn't have to always override it.  I almost never need to.  (The
exception is when I accidentally cause two mirrors to become diverged,
and have to get them back in sync.  This used to happen occasionally
with bzrtools.)

Could you explain a bit more about why submit_branch is almost never
right for you?

> You might say, well, just change submit_branch, but that's not quite
> right either.  What if changing that breaks 'bzr send', 'bzr pqm-submit'
> or some other vital command I don't yet realize also uses that
> variable?  The overloaded use of submit_branch is problematic because
> there's no way to really know what uses it, and even if I did, I suspect
> that the different commands will conflict in what they want it to be set
> to.

When I changed merge to use a different location from pull, I
contemplated adding a new location divorced from the submit_location.
At the time, I wasn't convinced that it was necessary for the default
merge location to be different from the submit_location-- they both
describe a "diverged branch" relationship.  I was leery of adding extra
configuration complexity, so I decided not to add an extra configurable
location.  So far, we haven't had many complaints on that front, but the
possibility of separating merge_location from submit_location is still open.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIK3B10F+nu1YWqI0RAuEXAJ9aDXGw9VrczgoMFIMjB97oB07AywCggbkR
xLb5HJOf4PIwszPZjaPDG/g=
=C0ou
-----END PGP SIGNATURE-----