Changing the UI of checkout

[Ian Clatworthy]

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.
> 
> Specifically, you can download the minimum to get your working tree
> (which by my tests with --dev6 is *very* close to a tarball size), push
> that data into the local repository, stack on the old one, and generate
> the working tree.

> At that point, you have enough data for diff, and technically even
> enough data for offline commit.

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.

But we're back to one of my themes: the right thing to do *locally*
is arguably different. In the local case, the goal is to share a
working tree across multiple branches so the stacked revisions aren't
useful but harmful.

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)

Alternatively, we drop the lightweight/heavyweight terms and go with
something like --cache-new, --cache-all, --no-cache (where --cache-new
implies a stacked checkout and is the default). Or something
along those lines that accommodates easy expansion to support
history horizons later.

I suspect the first is best for existing users? What do you think is
best for new users and, if the latter, is the improvement enough to
inconvenience existing users?

> Though with something like this, I would
> tend to *not* allow you to unbind/commit --local. (Personally, I feel
> that commit --local adds more to confusion than benefit, perhaps because
> of how it interacts with 'update', and no short-form for pushing the
> local commits to remote.)

I think fixing the interaction with update is a separate problem.
I'm not against removing commit --local and forcing users to
unbind before committing. But I see it as secondary issue and not
something important enough to change for 2.0.

Ian C.