[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: |
Mon, 05 May 2008 14:13:44 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080227) |
Hi,
Stephen Leake wrote:
one file, or the files should be renamed to different files.
Currently, "suturing" is not supported, so we approximate it by
dropping one file, and manually merging its content with the other
file.
Hm.. isn't approximation by renaming simpler? That way, you'd just
have to rename in any case and let the user solve the ncc later on.
I don't see how renaming is an approximation to suturing. The point of
suturing is to start with two files and end with one. I can rename
either or both of the newly added files; I still end up with two
files.
Ah, sorry, I misread and thought of resurrection only. "Suturing" is a
pretty new term for me ;-)
Of course, you are right then: suturing can be approximated by dropping
one file, yes. However, given die die die, it's a pretty bad approximation.
However, that appears to be quite a bit of detailed work. At a
minimum, it requires preparing at least one more roster to allow
commiting the drop before proceeding with the merge. So perhaps
it would be better to implement file suturing now.
Yes, absolutely.
I searched the mailing list archives for suturing. Nathaniel outlines
the basic objection to it here:
http://lists.gnu.org/archive/html/monotone-devel/2005-05/msg00326.html
The problem use case is:
A B
/ \ /|
| X |
| / \|
| C D
|/
E
Suppose A has "add foo", B has "add foo", D is a simple merge,
so
D contains a single sutured file name "foo". Suppose also that C
has "rename foo bar", and E is a simple merge, so E has two files
"foo" and "bar".
In pratice, what this means is one developer has decided to resolve
the conflict via renames (deciding the files should be separate),
while another developer has decided to suture the files (deciding they
should be the same). Clearly one of these approaches is simply wrong,
and should be reverted.
That problem would easily disappear if you rename in all cases.
I don't follow. If I add a renames step to this use case, I get:
Yeah, sorry due to my misunderstanding, I've interpreted the whole graph
wrongly.
The "problem" is that two different developers chose to resolve the
conflict in different ways.
Yes, namely between: merging the files into one or dropping one of the
offending files.
Now, my point probably was, that we could rename first, to let the merge
succeed. And then add a helper revision which either drops one of the
files or sutures the two together. However the developers doing the
merge decide, they would get the same merged revision first, with
different helper revisions. Having three possible outcomes: dropped
left, dropped right or sutured.
Then we only need to find merge semantics for suturing.
If you absolutely want to offer the developer a choice in such
situations, it might be better to rename first, then drop.
But we want to avoid 'drop', since that loses history. Instead, we
want to suture, preserving history.
Correct, my misunderstanding.
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.
Agreed. Two or more devs...
So, whatever the 'suturing' operation looks like, it has to be symmetric
(i.e. suturing 7 and 8 has to be the same as suturing 8 and 7) and it
has to conflict with 'drop' (i.e. introducing yet another non-content
conflict).
Dev 1 merges the files and decides to keep "foo" from rev A. Dev 2
also decides to merge, but decides to keep "foo" from rev B.
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.
Agreed. A good point for not approximating suturing by dropping.
This is an excellent example of why we need suturing instead of
dropping. Alternately, an excellent example of why parallel resolution
of conflicts is a bad thing.
Yeah, the 'symmetric' requirement for suturing.
However, I don't think of it as a bad thing, I rather take it as *the*
challenge for monotone to deal with all kinds of operations users might
want to do in parallel. Including parallel conflict resolution. :-)
Regards
Markus
- [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/04
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Ludovic Brenta, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Ludovic Brenta, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Ludovic Brenta, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Patrick Georgi, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/06