monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] renaming branches (was Re: Ideas and questions.)


From: Julio M. Merino Vidal
Subject: Re: [Monotone-devel] renaming branches (was Re: Ideas and questions.)
Date: Thu, 17 Feb 2005 10:25:46 +0100

On Thu, 2005-02-17 at 00:06 -0500, graydon hoare wrote:
[...]
>   - if you and a friend happen to make the same branch name X which you
>     *want* to reconcile, but accidentally generated two versions of it
>     in isolation with different IDs, put a chapter in the manual about
>     this. the suggested fix is "rename one as X.tmp, sync, then
>     merge X and X.tmp and delete X.tmp"

I think we'd use here the same approach I mentioned in another mail to
allow fixing of changelog and other certs.  I.e., first, we'd need to
replace the branch (key) names with random identifiers, as you mention.

But then, we'd keep a list of certs pairs which basically says 'cert X
has been overridden by cert Y'.  This could also be extended to the
branch names, just keeping the fact in the database that the new name Y
overrides the old name X.  This way, when two databases sync, they can
end up with both names in them but only the latest one (the leaf item in
the directed graph) will be visible.

All items "overriden" could be simply ignored - and possibly removed
from the database (or moved to a table of 'obsolete items' as somebody
suggested, which could allow their resurrection).

The "problem" I see with this is that two people may decide to rename a
given branch in their local databases.  When they sync, they'd end up
with two names for a branch.  But it's easily solvable; it's just the
same that happens now when a branch has two (or more) heads.

Can you see any serious flaws in this approach?  If so, I'll simply
forget about it ;)

> perhaps we should put it to a vote. the reason we're delaying 0.17 at 
> the moment is that we're working on epochs. this scheme would replace 
> epochs. so it produces 3 possible futures. which would y'all perfer?

Doesn't 0.17 include some fixes that may be worth having?  I haven't
tried with a fresh database, but as was posted some days ago, a pull
from off.net with a somewhat old 0.16 version triggers an invariant.

Cheers,

-- 
Julio M. Merino Vidal <address@hidden>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]