pqm-submit: support for bound branches

Aaron Bentley aaron.bentley at utoronto.ca
Mon Mar 6 22:27:18 GMT 2006


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

Robert Collins wrote:
> On Mon, 2006-03-06 at 11:25 -0500, Aaron Bentley wrote:
> 
>>I have to say, I think it will be unusual for a branch to be bound to
>>its public location, because the binding implies writing, implies SFTP,
>>implies non-public.
> 
> 
> I think the question is 'how to represent a branches public
> location' :).

I think we may be trying to get too much behaviour out of too few
variables.  The original idea of the 'parent' was 'x-pull', the location
that you pull from.  Lazy folk adopted it as the location you merge
from, and then its name was changed.

I think we really have:

a. 1 read-only pull location (for pull, and readonly bound branch ops)
b. n public locations for a. (defaults to a if not supplied)
c. 1 writable push location (for push, and readwrite bound branch ops)
d. n merge-from locations
e. 1 submit-to location

> the bound location says 'this branch is the same as that one over
> there', and will try to commit to it at the same time - but commit
> --local plus a push to the branches push_location will let you manually
> simulate a bound branch easily. 

My notion is that when you are bound and you push, you should push to
the location c for the master branch.

> So, heres another way you could simulate your bound branches. Checking I
> have your topology right you have:
> 
> panometrics http: 'public'
> panometrics sftp: 'master'

Actually, it's panometrics rsync.

> home: 'slave 1'
> work: 'slave 2'
> 
> if you configure slave 1 and slave 2 to push to 'master' and to be bound
> to 'public', you can set 'parent' to be
> http://bazaar-vcs.org/bzr/bzr.dev, and the following workflow will work:
> 
> 
> 'bzr update': in home or work: gets the latest code the other slave did.

I'm not thrilled with using 'update' for bound branches *and* with
checkouts.  John Meinel has a use case for checkouts of bound branches.

> 'bzr commit --local && bzr push': publish a commit to the public branch.
> 'bzr merge': merge in work from bzr.dev.
> 'bzr pqm-submit -m something': send in a merge request with a source of
> public and a target of bzr.dev.

Right.  What I do is the same effect, but I use pull instead of update,
and normal commit instead of commit --local.

> Thats what I'm using now, and really, I'd love to teach bound branches
> that it has two places for the bound location - public and private, then
> I would not need to commit --local & push.

Yes, that's sort of the whole point of bound branches.

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

iD8DBQFEDLdG0F+nu1YWqI0RAujJAJ0XgpeBk9itukwurxkc/2Aynq/FggCfXJBy
fsKks3UsqSJ97uzOCXXGVgE=
=KTG8
-----END PGP SIGNATURE-----




More information about the bazaar mailing list