Checkouts? Or just light bound branches?

[Aaron Bentley]

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

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.

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

> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD2jUv0F+nu1YWqI0RAn+IAJ9clnl0XePqIaos7jWoqj0rAZ+gQQCffXsk
xB9RToeZpsWJPgu6FpwF0Ck=
=mXOR
-----END PGP SIGNATURE-----