Rethinking last-revision

[Martin Pool]

On 30 Mar 2006, Aaron Bentley <abentley at panoramicfeedback.com> wrote:
> 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.

So by "location" do you mean per bzrdir?

> 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.

If I understand your proposal properly, we can still have two
last-revision markers in play, one in the branch reference and one in
the referred-to branch.  The question is just whether the one in the
checkout's bzrdir is seen as part of the working tree or as part of the
reference to the other branch.

In some ways it would be nice to have the working tree avoid knowing
anything about revisions.  However it does need to know about
pending-merges - and if we tracked partial merges then possibly in a
slightly complex way.  The basis revision is quite similar which
suggests perhaps it should be in there.

-- 
Martin