monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] resolving name conflicts; file suturing vs drop


From: William Uther
Subject: Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Date: Tue, 6 May 2008 10:31:54 +1000


On 05/05/2008, at 7:49 PM, Stephen Leake wrote:

Have you considered what happens, if two developers both decide on
merging the files, but a different node-id is choosen? As node ids
are local only, I think you cannot prevent that easily (i.e. by
choosing the lower node id - those might be different - you'd have
to compare birth date of the files. And even then, it might be
possible they were born on exactly the same date...).

Any time two developers try to resolve the conflict in parallel, there
will probably be problems. The only solution is to revert one of those
resolutions.

I think this is a deep issue.

I cannot see how you can suture without dropping one of the two
node-ids.  You start with two, you end up with one.  It doesn't
really matter what happens in the middle, at least one node-id
disappears.

At present, my understanding is that Monotone doesn't have an explicit
graveyard, it just uses the absence of a node-id as an indication
it has been dropped.  There is, currently, no place to mark 'why'
a node-id disappeared, or that it has changed to something else.

If there are further revisions added which use a missing node-id
then monotone will at least warn when they're merged, but that
is a safety net, not a solution.

As has been noted by others, when two people try this in parallel
and each choose a different side to die then DieDieDie merge will kick in
and cause both sides to die.  Ack.

All the solutions I can think of involve either a) getting rid of node- ids,
which is a very brave option and I haven't given it much thought, or b)
implementing a graveyard that would either i) remove DieDieDie issues, or
ii) allow a new type of node-id "removal by replacement".

If we are truly "merging" via suturing, nothing is dropped, and
everything is fine. If we are approximating suturing by dropping, then
this is an issue.

Do you know a way to suture without dropping a node-id?  Or were you
thinking of implementing a graveyard?

Cheers,

Will          :-}





reply via email to

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