pqm-submit: support for bound branches

[Robert Collins]

On Mon, 2006-03-06 at 17:27 -0500, Aaron Bentley wrote:
> -----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.

could be.

> I think we really have:
> 
> a. 1 read-only pull location (for pull, and readonly bound branch ops)

'pull' is a perfect fit appending of data, so the place you are pulling
from is the same branch in a logical sense.

> b. n public locations for a. (defaults to a if not supplied)

These are presumably aliases/perfect copies ?

> c. 1 writable push location (for push, and readwrite bound branch ops)

yes.

> d. n merge-from locations

I think there is a topological 'parent' here - I agree that the meaning
of parent is confused. To me 'parent' implies a tree of branches, rather
than the same logical branches. I agree that there may be multiple
places one merges from... but there is a 'primary' place.

> e. 1 submit-to location

Yes. This should default to the primary merge-from location.. or
something like tat.

> > 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.

I agree and would consider the current push behaviour a bug.

> > 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.

So do I, and I test updating of such a beast. However both checkouts and
bound branches deliver the same centralised workflow, the difference is
more storage overhead than workflow, and for that reason I think update
should be used for both.

> > '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.

Ok. So what do we need to do to the current variables:
'push_location'
'bound'
'parent'

to adequately, and nicely, represent a...e above.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060307/69c26b3a/attachment.pgp