Rethinking last-revision

[Martin Pool]

Should a standalone bzrdir (local branch & working tree) have separate
last-revision pointers for the working tree and the branch?  In the past
there was just one pointer.  I think this was a mistake and as robert
said it causes some misbehaviour with regard to out-of-date working
directories.  Now at the moment we have two.  If the answer to that
question is yes, then presumably we will also want them for more complex
cases.

It only makes sense to have two pointers if there are cases where they
should have different values.

If they differ, the user can update the working tree to the branch's
revision with 'bzr update'.  

I do think in general we should try to keep the working tree based from
tip of the branch without making people take any special action.

Revert unconditionally overwrites the files, whereas update can do a
merge from the previous working tree basis version to the new one.  If
there are, for some reason, useful changes made from the wrong base then
this will preserve them.  The other is an of intent: 

The particular case that bites at the moment is sftp push leaving the
working tree out-of-date, but not *known* to bzr to be out of date.
It would be better to either update the tree or not have it there, but 
it's rather nice that this case can be handled even if we want to avoid
it.

Having a separate working tree last-revision may help in cases where
updates to the working tree are updated.  If we pull from somewhere else
we can then represent the state of "the branch has moved forwards, but
the working tree is not updated yet."  If the updates to the working
directory are resumed later it would be nice to do them using a
merge-based update, rather than making the user just revert.  (This
doesn't solve all the issues in handling interrupted working tree
transforms, but probably helps.)

If we have two last-revisions, then people can intentionally base their
working tree off an old revision.  This is a bit of an advanced use, but
some people like it in svn and cvs.  For example you can rewind to a
previous revision to see if a bug can be reproduced there, or to apply a
patch to an old version and then bring it through to the current
revision.  Commit should of course fail until the working directory is
out of date with the branch.

These can also be achieved by making a separate branch, and for
simplicity that's what we should recommend.  But I think having a model
that can accomodate this way of working is good, if there's not too high
a cost to the code.

-- 
Martin