[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
From: |
Markus Schiltknecht |
Subject: |
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: |
Wed, 07 May 2008 10:10:04 +0200 |
User-agent: |
Mozilla-Thunderbird 2.0.0.12 (X11/20080420) |
Hi,
Stephen Leake wrote:
This is the same duplicate name conflict that was noticed when merging
a and b to get d. So merging g and h fails with a duplicate name
conflict, and 'merge --resolve_conflicts' lets the user resolve it,
by another suture.
Huh? Out of c, d and e, which we are merging, only d contains a suture
(i.e. sort of renaming). d and e are edits of the file. So there's
certainly no duplicate naming conflict - that was solved by d. The
question here is how to merge things later on.
ii) Pick one side and drop that side. This still requires a
"merge through suture" function, but that function can be more like
pluck' in that you just move the patch from the dead node-id and
re-apply to the live node-id. Eventually all instances of the dead
node-id would disappear.
Huh? I think that makes no real difference. Whether you 'reuse' one of
the node ids and special case merges from the other one or just
special case everything... you still have to solve the above problem
somehow (maybe with some sort of pluck). And the required amount of
code is probably the same.
The current recommended resolution (in monotone.info) for duplicate
name conflicts where there should be only one file is to drop one
side.
Yeah, that's because we don't have suturing, yet. However, with that, we
would certainly recommend renaming or suturing. (As you've pointed out
when saying that dropping is a bad approximation for suturing).
If we use that approach in this example, we get:
o
/ \
a b
/ \ / \
c d e
\ / \ /
g h
\ /
f
o is our original revision.
In a and b, two people independently introduced new files with the
same name and purpose.
In d, the file in a is dropped; content of the file in a and b is merged.
In c and e, the files introduced in a and b were each independently edited.
In g, the file disappears due to DieDieDie.
In h, the files in d and e are merged correctly.
In f, the file disappears due to DieDieDie.
Well, that doesn't include suturing, so what's the point here?
I think this is a realistic use case; in c and e Abe and Beth are
improving checkout.sh, while in d some supervisor has noticed the
duplicated work and sutures them. Then g, h, and f are just Abe and
Beth catching up.
Uh.. to avoid confusion, I wouldn't call that suturing now. It's the
approximation using a drop and merging contents into the other file.
Monotone cannot currently tell that approximation of suturing apart from
a real drop and any other kind of editing of the other file.
So we do need to do something to record the suture so that DieDieDie
doesn't kill the file later. As people have been saying; I'm just
taking a while to catch up :).
The problem here is not only DieDieDie, but also history. If you drop
one file, previous (in the DAG) edits to that file will never get merged
back to the other file.
However, I'm not saying we need to get rid of DieDieDie entirely; just
override it when there is a suture in the history.
We certainly need to get rid of DieDieDie, but that's quite a different
feature, IMO.
Suturing certainly shouldn't 'override' a drop. That would mean monotone
preferring one user decision over another. See my mail answering Thomas
Moschny.
Assuming we do that by adding information somewhere, and adopt the
definition "suture = drop two, add one", this example becomes:
Okay.
o is our original revision.
In a and b, two people independently introduced new files with the
same name and purpose.
In d, the files in a and b are dropped, a new merged file is added,
and the suture is recorded to defeat later DieDieDie.
In c and e, the files introduced in a and b were each independently edited.
In g, the files in c and d are merged correctly.
In h, the files in d and e are merged correctly.
In f, the files in g and h are merged correctly.
There is no need for 'pluck' that I can see.
Yes, I'd agree to that.
But maybe I'm missing
something; maybe the code for "c and d are merged correctly" ends up
looking like the code for 'pluck'?
No, the user needs to merge together c and d.
I need to read the code to see exactly to which type this extra info
could be added. I've started adding the rename resolution to merge
(not checked in yet); that will help me understand the code better.
Very cool! So you are a step ahead, in a way. I'd say you urgently need
the suturing feature ;-)
Markus
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, (continued)
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Matthew Nicholson, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Matthew Nicholson, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop,
Markus Schiltknecht <=
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/08