[RFC] make checkouts as much like bound branches as possible

Olaf Conradi oohlaf at gmail.com
Tue Mar 28 13:01:48 BST 2006


Hi,

On 19/03/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> True checkouts and bound branches are very similar in the UI, and we've
> tried to have them exhibit the same behavior wherever it makes sense.
>
> But since they are implemented quite differently, they exhibit different
> bugs and require different code paths to get the same behavior.
>
> I'd like to propose that checkouts have a special proxy branch, a
> CheckoutBranch, whose revision-history operations differ from the
> proxied branch.  CheckoutBranch.get_bound_location and
> CheckoutBranch.get_master_branch would both refer to the proxied branch.
> ~ CheckoutBranch.unbind and CheckoutBranch.bind would throw.
>
> Aside from this, all other operations would pass through to the proxied
> branch.
>
> This would mean
> - - fewer codepaths
> - - more behavioral consistency between bound branches and checkouts, more
> easily
> - - less confusion for developers about how bound branches/checkouts are
> supposed to behave.
> - - all code that expects revision-history to be the local tree's revision
> history (e.g. the revision spec code) will become correct
> - - James Blackwell can truthfully say 'A checkout is a branch'.

This would mean that a lightweight checkout can't be bound to another branch.

I thought there wouldn't be a sane use case for that, but thought of
this later on...

Suppose a developer is working on a mainline using bound branches as
described by LockStepDevelopment [1], but also wants to keep branches
from other developers on his machine.

So he creates a shared repository on his machine and creates a tree of
lightweight checkouts of mainline for his own stuff and experimental
checkouts of other developers.

He binds his own checkout to the remote mainline and develops on that
working tree for stable fixes and keeps the experimental branches in
the same local shared repository.

With lightweight checkouts as bound branches he can't use this
construct. If he wants to put everything in a local shared repository
he can't bind to the remote one and has to push everything.

Am not sure this is a convincing example, just reasoning here. This
double binding might be a cornercase and just setting up a shared repo
for just the experimental branches would allow for almost the same use
case, except for storage of revisions common to both mainline and
experimental.

Keeping the UI simple and reducing code paths is also a good thing.

Cheers
 -Olaf

[1] http://bazaar-vcs.org/LockStepDevelopment




More information about the bazaar mailing list