[RFC] branch --bind

[John Arbash Meinel]

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

A. S. Budden wrote:
> 2010/1/5 Martin Pool <mbp at canonical.com>:
>> 2010/1/5 A. S. Budden <abudden at gmail.com>:
>>> From my point of view, there are two ways to group the three working
>>> copy types (lightweight checkout, heavyweight checkout and branch):
>> That's a pretty good way to slice it but the definitions perhaps are
>> not so clear (eg the word 'local' is ambiguous about whether you mean
>> across directories or across machines.)
> 
> Good point: I meant across machines.
> 
>> I think your categories can be rephrased as
>>
>>  * is a copy of history stored locally?
>>   * false for lightweight checkouts, true for branches and bound
>> branches, not properly answered(?) by heavyweight checkouts
>>   * implies can you run diff/log when disconnected
>>  * can you commit and not have it go into the master?
>>   * false for all checkouts, true for real branches, complicated for
>> bound branches
>>   * equivalent to, can you commit when disconnected
>>   * at the moment this is handled by 'commit --local' and I suggest
>> that's an unnecessary complication
> 
> That's an interesting point.  I am surprised at the distinction
> between a heavyweight checkout and a bound branch (particularly in the
> line starting "false for...").  Is there actually a difference?  If I
> do "bzr checkout" to create a heavyweight checkout and open it in
> Bazaar Explorer, it calls it a bound branch.  Is this wrong?  I've
> been working on the assumption that they're the same thing, just
> different names.
> 

I think Martin was specifically discussing the high-level concepts, and
what we might want to call a 'bound branch' and its behaviors versus
what we would call a 'heavyweight checkout' and its behaviors.

*Today* the only difference is whether you have a working tree locally.
(You can bind branches without any checkouts.) A checkout sharing the
directory of a bound branch is a heavyweight checkout.

I think his point is specific to the question "is a copy of history
stored locally?". For something called "heavyweight checkout" it
probably stores some info locally, but is it able to rely solely on
that, or does it have to connect to the remote location anyway to
validate its information.

We've run into this a few times for stuff like "bzr nick". If we want a
heavyweight checkout to act exactly like a lightweight checkout, except
it gets some data locally, then stuff like "bzr nick" should look in the
master branch, and not the local branch (technically ever, though right
now we stop locally if we find a nick there first).


> At the moment (as I've probably said a few times by now!), I use
> heavyweight checkouts exclusively.  There is a tree-less "feature
> branch" layout on a network drive and a local (i.e. not on the shared
> drive) heavyweight checkout, created using a patched [1] Bazaar
> Explorer.  Most of the time, I use it as if it were a lightweight
> checkout.  When I'm working off-site or the network is being
> temperamental, I use "commit --local" (the main benefit to me of the
> heavyweight checkout) and send the changes upstream when I'm
> reconnected.  Obviously, the heavyweight checkout also gives me access
> to the diffs and logs.
> 
> Just out of curiosity, if the heavyweight checkout gets renamed as a
> "bound branch", what will Bazaar Explorer's "switch checkout" be
> renamed to?  This is a command I use rather a lot to enable working
> with network-drive feature branches and it's name makes sense for
> lightweight and heavyweight checkouts, but doesn't really fit with
> "bound branch".
> 
> Al
> 
> [1] https://code.launchpad.net/~abudden/bzr-explorer/remote-feature-branches/+merge/15487
> 

So *IMO* an optimal setup would be to get rid of heavyweight checkout as
a concept. And stick with

Repository
Branch
Checkout

And then if you want the "heavyweight" behavior, you use a local
checkout of a local branch which is bound to a "remote" branch. If you
want to commit locally, then you create a new local branch (no new
tree), point your local checkout into it and commit. (no commit --local.)

That makes it quite a bit clearer what state your bound branch is
supposed to be in. When you get back online, you can point your checkout
back and the bound branch and "bzr pull" the local branch's changes back
into your bound branch, which will also update the network branch. (or
you could push the local changes into the network branch, switch and
then update, etc.).

commit --local (IMO) is a misfeature, as it lets you take something that
claims to be in-sync and explicitly get it out-of-sync-for-right-now. It
should be cheap to just create a 'this-one-is-not-in-sync' branch
instead. And possibly 'unbind' would also allow you to do that without a
physically separate branch.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktE/N0ACgkQJdeBCYSNAAPtkwCdFgBcnjCBEmEZ5ysTU5X0gtdt
DP0An3hhBlLRNz/lB5J1H8F9LLyQHiJr
=r06O
-----END PGP SIGNATURE-----