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