Checkouts? Or just light bound branches?

[Jan Hudec]

On Fri, Jan 27, 2006 at 09:58:55 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> >>It also bothers me that bound branches and checkouts will have the same
> >>behaviour implemented around last-revision: if local last-revision is
> >>not the same as upstream last-revision, fail.
> > 
> > 
> > for commits you mean? Yes, that workflow would be the same. But I would
> > expect that it is implemented *by the checkout code* in both cases. A
> > bound branch has a checkout that is generally the local branch, so if
> > you pull the remote branch into the local branch without altering the
> > checkout, then trigger the commit, you'll get the same behaviour with no
> > duplicate code.
> 
> If the checkout last-revision is separate from the branch last-revision,
> there will be repeated steps in commit:
> 1. verify that the checkout is up-to-date with the branch
> 2. verify that the branch is up-to-date with the branch it is bound to

The last-revision can't be separate when they are one!

Definition:
Checkout = Bound branch with working tree and dislocated storage
(sharing storage with the branch it is bound to).

> 3. generate the new revision data, update the bound-to branch's repository
> 4. set the bound-to branch's last-revision (currently, by appending to
> revision history)
> 5. update the bound branch's repository
> 6. set the bound branch's last-revision
> 7. set the checkout's last-revision
> 
> (4 and 5 can be swapped, if you prefer)
> 
> >>Bound branches and checkouts will serve very similar use cases, so it
> >>seems funny that they use different concepts, and will require different
> >>day-to-day operations.
> > 
> > 
> > I'm not sure what different operations you are thinking of here...
> > except that bound branches can work offline
> 
> I mean that bound branches are produced with 'bzr branch --bind', while
> checkouts are produced with 'bzr checkout'.  I mean that you can't
> unbind a checkout.  It's been suggested that bound branches are updated
> with 'bzr update', but how do you update a checkout, then?  It gets
> complicated for a checkout of a bound branch.  Do you always update both?

Under the proposal there is no both. 'bzr checkout' is an alias for
'bzr branch --bind --share-storage'. And 'bzr update' would be an alias for
'bzr pull'.

> I'm not sure the offline distinction is going to be very relevent.  I
> think the recommended case for (checkouts/light bound branches) will be
> that the repository is on the same host, anyhow, because even LANs
> aren't as fast as local storage.  Either that, or we cache.

Well, I think that they would likely share storage when the parent is local
(and thus it'd be a "checkout"), while if the parent is remote, it would copy
the data (and thus it'd be a "bound branch"). There is no other difference
between the two things.

> > codewise:
> > I think that this would be somewhat artificial, as I think all the
> > workflow code for bound branches is most appropriate to live in the
> > workingtree anyway.
> 
> I think at minimum, a bound branch's set-revision-history must enforce
> the requirement that the bound branch may not diverge from the bound-to
> branch.
> 
> I don't see how you get away from having to verify both the checkout's
> last-revision and the branch's last revision, e.g. when you have a
> checkout of a bound branch.

It's not a checkout of a bound branch. It is that checkout IS a bound branch.

> > uiwise:
> > I'm not sure from a UI perspective if its a problem or not to expose
> > both checkouts and bound branches or not - but using 'lightweight bound
> > branches' would have the same ui consequences anyway.
> 
> I think that, for users, it would be most intuitive to present the same
> UI for bound branches and for checkouts/light bound branches.
> 
> And if we're presenting the same UI to bound branches and checkouts,
> there will be an advantage to representing them the same way in the
> code.  It will help ensure consistency in behaviour, especially in
> failure handling.
> 
> Aaron

I agree. Though we should provide the checkout and update aliases for
convenience of users comming from centralized version control tools.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060127/d795d087/attachment.pgp