Confusion over locations

[Aaron Bentley]

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

Barry Warsaw wrote:
>> 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.

> What about a situation where you want to synchronize your divergent
> branch with your local upstream mirror?

Just to make sure I understand this example:
1. There is a branch "REMOTE" at a remote location which is the main
branch of a project you are working on
2. You have a local mirror of "REMOTE" called "LOCAL"
3. You have a diverged branch of "LOCAL" called "DIVERGED".
4. When you submit your code, you'll be submitting it to "REMOTE".

This is my standard case.

The submit_branch of "DIVERGED" is set to "LOCAL".  The public_location
location of "LOCAL" is set to "REMOTE".

When I merge into "DIVERGED", the default merge location is "LOCAL".
When I pqm-submit, the default target branch is "REMOTE".

> I want to merge from the divergent branch's parent,
> which is my local upstream mirror.

Yes, this setup gives you that.

> A second common use case for me is where I branch from my local upstream
> mirror, then merge a completely different remote branch into it. 
> Although I'll rarely do subsequent merges, when I do, I almost always
> want to merge from the remote branch again, not the local mirror.

If the submit_branch is not set and you specify a location to "merge",
it will be stored as the submit_branch.  If submit_branch is already
set, you can override it with "merge --remember".

> The difference in these two cases is that in the former, the very first
> merge I do will have no explicit branch argument, because I'm
> assuming/hoping it will automatically come from the parent branch.

It will, if the submit_branch is unset.  If the submit_branch is set to
your local mirror (e.g. by a locations.conf rule), it also will.

> Why does merge by default choose the submit_branch?

Merging and submitting are both operations that happen in a diverged
relationship.  Most of the time, you branch from trunk (or a local
copy), make local changes, merge from trunk (or a local copy) and then
submit back to trunk.  It doesn't sound like your "hack on my own stuff"
case is different from this.

>  When I think of
> "submit" I'm thinking about submitting the branch for review, or for
> pqm.

The separate location for submitting came about first, and we started
using it as a merge location later.

>  It's a request for a particular action that I'm making to someone
> or something else.  For me, that request is always to a remote mirror of
> my local divergent branch.  I can't understand why I'd ever want to
> merge /from/ that remote branch /into/ my local hacking branch, because
> it's never going to have anything in it that's not in my local hacking
> branch.  I've never needed to merge from that branch into my local
> branch.  What's the use case for that?

So, merging from the remote branch instead of its mirror isn't *wrong*
in a semantic way.  It's too slow, sure.  But if your local mirror is
up-to-date, it will not produce the wrong output.

But if you specify the public_location of your remote mirror, you can
use that as your submit branch.

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

> To make the target of my pqm-submit
> inspired star-merge command be the right url, I have to set
> submit_branch to the remote parent of my local upstream mirror.

No you don't.  "pqm-submit" knows all about public locations.  If the
public location of your local mirror is correctly set, pqm-submit will
use that.

> Sure, I could use --remember but over time that's just going to end up
> littering my locations.conf file with scores of long-defunct branches,

No, --remember sets the value in .bzr/branch.conf, not in ~/locations.conf.

> and I still have to remember to use --remember ;).

You can always set your submit_location in locations.conf so that it
applies to all branches in a subdirectory.  As long as all branches in
that subdirectory *should* have the same submit location, it all works
nicely.

These days, my location.conf is customized such that I never have to set
push_location, public_location, or submit_location when creating a new a
branch of Launchpad or Bazaar.

> [1] There's an oddity to the star-merge target when I set submit_branch
> to my local upstream mirror.  In that case the target appears to use my
> public_branch, ignoring public_branch:policy.  That one I don't get and
> I can't see how that could possibly be correct.

No.  I don't see how it can possibly ignore public_branch:policy.  That
policy handling is done at a very low level, and would be a lot of work
to ignore.

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

iD8DBQFILQR50F+nu1YWqI0RAo9+AJ0dkeq4Mr46neZ28zoZ4EHx4ik64gCfbiMe
rMdn5lPJronWWBi2tGEi9AY=
=DsKC
-----END PGP SIGNATURE-----