Rethinking last-revision

Martin Pool mbp at sourcefrog.net
Mon Apr 3 07:38:59 BST 2006


On  1 Apr 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

> | 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.
> 
> Right.  And the major impact of this is that the last-revision of a
> standalone branch's tree can't be out of sync with its branch.
> 
> Especially if you assume that branches have only a last-revision marker,
> not a revision-history, lightweight checkouts start to look like bound
> standalone branches that can't be unbound.

And we could even unify them a bit more, allowing for them to be
unbound, or rebound to something else.  I'm not sure there really should
be a difference, other than whether you want to have a local copy of the
history or not.

> | 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.
> 
> I'm certainly not claiming trees shouldn't make mention of revisions.
> You're right in a sense, but I think the simplicity of
> one-revno-per-location is worth it.

I can't find a case that really sums it up but it does seem like working
trees "have" a revision that they started from, and it goes deeper than
just being the end of the branch it's associated with.  If you're sure
they should be the same I guess it's OK with me.

-- 
Martin




More information about the bazaar mailing list