Changing the UI of checkout

[Martin Pool]

2009/4/17 Ian Clatworthy <ian.clatworthy at canonical.com>:
> Ian Clatworthy wrote:
>> John Arbash Meinel wrote:
>>
>>> I would agree that a "better" lightweight checkout is a "stacked"
>>> checkout, where we've put a little bit of history in the repo.
>
>> Nice. I strongly agree that diff performance needs to not suck and
>> that stacking by default is the RTDT for a checkout of a remote
>> branch.
>
>> So the minimum UI change approach would suggest:
>>
>> 1. we stack by default (instead of caching full history)
>> 2. we add --heavyweight (which caches full history)
>> 3. we leave --lightweight there (for the local case)

I really don't think we should stack by default.  John pointed out
that Arch's slant towards not replicating history tends to very easily
get people into cases where they can no longer find the revisions they
want, and I'd add that it also gives the program a bit of a hard time
because it will be more commonly dealing with ghost-type cases.

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

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

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.

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.

-- 
Martin <http://launchpad.net/~mbp/>