Changing the UI of checkout

[John Arbash Meinel]

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


...

>> Let me change my mind about this.
>>
>> On reflection, I think checkouts ought to be lightweight. Period.
>>
>> I recall debating with Aaron ages ago about lightweight vs
>> heavyweight semantics. IMO, the bottom line is that they smell
>> the same but they're really quite different beasts. In particular:
>>
>> * lightweight checkout = tree & a *reference* to a branch
>> * heavyweight checkout = tree+branch & a *bind* to a second branch.
>>
>> If you think a lightweight checkout is a heavyweight checkout
>> with zero history cached (like I initially expected), you're
>> missing the key semantic difference explained above. And that's
>> simply too much magic/complexity for 95% of new users IMO.
>>
>> And we simply don't *need* heavyweight checkouts when we have
>> bound branches as well. They're redundant to all intents and
>> purposes.
> 
> Is there actually a technical difference between heavyweight checkouts
> and bound branches, or is it just reaching the same configuration
> through two different UIs?
> 

I think technically a heavyweight checkout has to have a working tree,
or it would just be a bound branch.

I think the discrepancy arose because I wrote the code in terms of bound
branches, but Robert believed that a UI of "checkout" would be easier
for people to understand.

So you end up with stuff like bind/unbind which don't have a real place
in a 'checkout' model, but were useful and we didn't work out an
alternate way of doing those. (IIRC, at one point Robert favored
removing them entirely, and having people that want to 'unbind' delete &
branch, though now you could argue it is a 'reconfigure --XXX' command.)


>> So, my vote if for:
>>
>> * checkouts being lightweight and lightweight only
>> * if you want to use the lockstep development workflow with local history
>>  and/or make local commits, use a bound branch
>> * removing --local from commit
>>
>> We might need to tweak something to make diff against the basis tree
>> fast, but the answer to that is a better lightweight checkout
>> implementation (when time permits), not a stacked checkout.
> 
> commit --local creates a situation where you can have four trees in
> play: the wt basis, the current wt, the local branch tip and the
> master branch tip.  This is pretty complicated for the user and pretty
> complicated for us.  I am skeptical that it's really worthwhile,
> because we already have a good mechanism for doing offline
> development: make a new branch, commit there, then merge back.
> 
> I think bound branches that can diverge were a good experiment but (as
> I've said before in a thread with Mary) I question whether it's worth
> retaining them.

I agree.

> 
> Just removing the --local option to commit would make it harder for
> users to reach this situation but the variables are all still there
> and it can still occur.
>

Well, someone can push --overwrite the master branch. But if we made
"bind" conform to the original implementation (sync both ways, fail if
diverged), you would eliminate the bind && unbind route.

I think getting rid of --local, and making 'bind' do the synchronization
would eliminate 99% of the cases where people end up with 4-trees in
play. (Maybe I'm optimistic.)


> On checkouts, I do think people reasonably expect them to be
> lightweight by default, that they create a new working tree and no
> more.  I think the most appropriate place to use checkouts is when you
> have fast reliable access to their repository, at least while using
> them.  If not, again, we do have a good mechanism for making history
> available or mutable offline and you should probably use it.  At least
> allowing diff to work without going back to the repository (like in
> svn) might be good, but as you say that's probably an enhancement
> request rather than a reason to copy all the history when making a
> checkout.
> 

I think a stacked branch (that saves the data it has read) gives better
immediate results than "'bzr checkout' is always lightweight".

That said, I honestly wonder if we want to make the Repo + Branch(es) +
WT(s) model *more* a part of the UI, rather than less. The flexibility
is really nice (any WT can point at any Branch, and they are all stored
in the same repo...)

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

iEYEARECAAYFAknrHWAACgkQJdeBCYSNAAOckwCfaYLtOraaTb4BJ6K7di1OhCMg
4hUAoJhUZSLar2uj6V5fonHdpYMpvri3
=hVW8
-----END PGP SIGNATURE-----