Rethinking last-revision

[Aaron Bentley]

I tried to implement my proxy branch for checkouts yesterday, and I ran
into a snag:  my CheckoutBranch was creating a WorkingTree, and my
WorkingTree was creating a CheckoutBranch, ad infinitum.

This sort of thing can be fixed, but not without pain, because it would
mean altering, say, the Branch.open API.  The real problem is that the
WorkingTree and CheckoutBranch both want to own the last-revision marker.

A related problem is that our format permits a BranchReference to have
no last-revision marker, so only the vast majority of BranchReferences
can be represented as CheckoutBranches.

I think it's a mistake to have two last-revision indicators per
location.  It breaks our API, it breaks our UI, and it breaks our brains.

As an alternative, I have previously suggested having lightweight
branches that use a repository at an arbitrary location.  I gave up on
that idea because it made it impossible to know which revisions in a
repository were used by checkouts.  But it always seemed wrong to have
two last-revision markers.

There are a few cases where it's desirable to update a branch without
updating the associated tree, but they are rare, and I don't believe
they are worth the cost to everyone else.  I think most people would
rather update BOTH the branch and the working tree, if they want a
working tree at all (and yes, we can die if there are uncommitted
changes, or clobber, or merge).

For those few cases where it's desired to separate the branch and
working tree's last-revision, we can simply put the tree inside the
branch, or the branch inside the tree.  This simplifies the UI for those
cases.

Say "dir/foo" is a tree and "dir/foo/branch" is its branch.  "bzr revno
dir/foo" will obviously produce the revno of the tree, and "bzr revno
dir/foo/branch" will obviously produce the revno of the branch.  No new
syntax is required to distinguish between branch-last-revision and
checkout-last-revision.

So I propose that "Bazaar-NG Branch Reference Format 2" shall have a
last-revision file.  "Bazaar-NG Working Tree format 4" shall not have
one.  These types shall only be permitted in "Bazaar-NG meta directory,
format 2", and the earlier tree/branch reference formats shall not be
permitted there.  All full branch types supported by metadir 1 shall be
supported by metadir 2.

I realize that it's undesirable to delay 0.8 by doing this, but I think
I can get this done quickly enough to avoid that.  I would provide an
upgrade path.  Since we want to support 0.8's default format for a long
time, I think we should not release with metadir format 1 as the default.

Aaron