Changing the UI of checkout

[Stephen J. Turnbull]

Eugene Wee writes:

 > It seems to me that if checkouts are lightweight, they would then fall
 > into your party line: using them to get source trees for beta testing
 > and release distribution makes sense and the user would not be
 > checking history so a history cache would not be useful.

I agree with both points.  Of course, whether or not the history cache
is "useful" depends on how urgently the user wants to check history,
do diffs, and the like.

 > Using them to reference and commit to local branches as in the

What do you mean by "them"?  If you mean "heavyweight checkouts",
there is still the problem that bazaar uses the "wrong" order; in case
of divergence you must do an extra commit --local or accept damage to
the workspace.

Neil at least doesn't want to use commit --local, so there's some
support for bazaar's way of doing things, but really it's due to the
artificial restraint against having multiple heads in a checkout.

Mercurial and git handle this by creating a new head (really, that's
all the infamous "git index" is: an implicit head not committed to the
object store).  The user never ever has to bother about whether her
data might run into a divergence before it gets committed somewhere.
She just commits it, then resolves the divergence using VCS tools
rather than her programmer's editor.

Then resolution can occur in several ways; Mercurial strongly favors
an explicit merge that will appear in the logs (Neil wouldn't like
this because the history of the local branch cannot be an exact
mirror), git tends to favor rebasing (Neil's approach implicitly
involves a rebase).  Bazaar does implicitly have a concept of multiple
heads in a workspace (that's necessary to a merge), but it's not
available to users of checkouts who use pull and update.

 > "shared-tree-across-branches workspace model" would not raise your
 > objection since a reasonable user would not be committing to the
 > local branch from another checkout anyway (and presumably no one
 > else can do so since it is all local).

But what about unreasonable users?  Specifically, newbies?  There is
this meme out there that dVCS means you can commit anything anywhere.
(Usually not quite that blatant, but there are many variants that
contain that as a component.)

Maybe there's nothing that has reasonable performance characteristics
and behavior for the intended use-case that can be done, but I think
it's worth thinking about (for 3.0, at least).