Changing the UI of checkout

[Stephen J. Turnbull]

Ian Clatworthy writes:
 > Stephen J. Turnbull wrote:
 > 
 > > 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.)
 > 
 > Bazaar is designed to be adaptive, supporting both central and distributed
 > version control models. checkouts (largely) fall into the central camp.

Sure, I know that.  But (based on the problem reports I've seen here
and the docs), Bazaar doesn't do them any better than Subversion does,
really, despite being loaded with tools that should make it easy to do
a great job.

For example, there is no good reason for bzr commit to ever fail in a
checkout, unless new commits in upstream are in genuine conflict with
the working tree.  To address the not up-to-date case, it should
automatically do an update before committing.[1]  To address the merge
conflict case, bzr commit should automatically shelve the uncommitted
changes before updating, then unshelve before pushing, and in the case
of merge conflicts should preserve the local changes in case later
analysis shows that the merge needs to be unwound, but the feature
you're checking in now should be preserved.

It should not be possible to commit or push into a checkout except
from its own working tree.

A clone of a checkout should not create a branch of the checkout, but
instead automatically bind/refer to its parent.[2]  I'm not sure what
should be done with unrecorded changes, probably they should be
ignored by the clone.

The order of commit for heavyweight branches is inconsistent in the
case where --local is used.  That is, if --local is not used, commits
always go to the remote first, while if --local is used, on the next
commit the saved-up local commits have to go to the remote before you
can commit the unrecorded changes to the remote.

BTW, it's not clear what the intent is if your push fails.  Abandon
the checkout and turn it into a branch?  Rebase its changes on top of
the remote?  Again IMHO the whole concept of checkout is incoherent in
the absence of write locks on the remote.


Footnotes: 
[1]  Maybe this should be optional, in the case where you have to do a
fix against a particular version.  But that seems incoherent; if you
want that behavior, you have to branch eventually on the remote, and
may as well do it locally to avoid confusion once the new remote
branch is available.

[2]  This could be optional for heavyweight branches, especially those
that are "temporarily" bound.