[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict
From: |
Markus Wanner |
Subject: |
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone) |
Date: |
Mon, 11 Jun 2012 20:25:32 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 |
Hi,
On 06/09/2012 03:19 PM, Stephen Leake wrote:
> Markus Wanner <address@hidden> writes:
>> Sorry, that was too brief. I'll give an example:
>>
>> A
>> / \
>> M1 D
>> | \ |
>> | P -- P is the "keep" resolution, effectively resurrecting
>> | | -- the file and giving it a new node id.
>> | |
>> M2 | -- M2 and M3 are both modifications on the same file (but
>> | M3 -- now known under different node ids).
>> \ /
>> Q -- Q merges. How?
>>
>> The issue you are facing in Q is that monotone thinks the two node ids
>> are distinct files. Even if you manage to teach it to "suture" because
>> the two files conflict by their path, figuring out what ancestor to use
>> is non-trivial. And certainly involves remembering the relation of the
>> file added in P to the one deleted in D (or modified in M1, same thing,
>> same node id).
>
> Another good test case. But I think my current solution addresses it;
> the conflict data in _MTN/conflicts has the file_id of the file in M2
> and M3, so the user (or a front-end) can retrieve them, diff them, and
> use the 'user' resolution to provide the content for Q.
Conflict data in _MTN/conflicts? Hm.. I didn't ever see or use that.
So, you are effectively saying, monotone doesn't need to properly keep
track, but the user can resolve it. Sorry, I just don't consider that to
be a "solution".
>> Let's adding a simple rename:
>>
>> A
>> / \
>> M1 D
>> | \ |
>> | P -- P is the "keep" resolution, effectively resurrecting
>> | | -- the file and giving it a new node id.
>> | |
>> M2 | -- M2 and M3 are both modifications on the same file (but
>> | M3 -- now known under different node ids).
>> | |
>> R | -- R additionally renames the file on the left
>> \ /
>> Q -- Q merges. How?
>
> In this case, the current conflict code will identify M3 as the node to
> merge with R, which is the right thing to do. The reverse case is
> different:
Huh? How can it do that? The two files have different node ids,
different names (and different modifications applied to them).
Say A has the original file "foo", node id 2. Merge P "keeps" that file
"foo", by adding it under node id 3. Following a modification on each
side. After the rename in R, node id 2 is now known under the file name
"bar".
So the merger that needs to create Q sees a file "bar" with node id 2 on
the left and a file "foo" with id 3 on the right. How do these conflict?
(And what "current conflict code" are you referring to? The issue-209
branch?)
> A
> / \
> M1 D
> | \ |
> | P -- P is the "keep" resolution, effectively resurrecting
> | | -- the file and giving it a new node id.
> | |
> M2 | -- M2 and M3 are both modifications on the same file (but
> | M3 -- now known under different node ids).
> | |
> | R -- R additionally renames the file on the right
> \ /
> Q -- Q merges. How?
>
> Now there's no way to associate R with M2
Yeah, the two files in R and M2 have no association. Neither file names
nor the node ids match. If you ask me, that's pretty much the same case
as in the example above.
> so the drop/modified conflict is repeated,
What drop conflicts with what modification? P "resolved" the one
conflict that I see. After that, monotone considers the file that P
(re)created to be a different one than what D deleted.
Oh, you mean M2 conflicts *again* with the delete? But a user already
decided he wants to keep the file (and apply M1). That should merge
cleanly with yet another modification.
> and the user is not presented with all the information they
> need (they should merge M2 with R). This is bad, and sutures is the
> right fix.
It's not just that the user is not presented with *all* the information.
He gets misleading information - instead of the clear warning that
monotone-1.0 provides.
> But none of this is new; all of these cases exist in mtn 1.0, with all
> of the same solutions, workarounds, and problems. I'm just making a
> couple of the more common cases easier to deal with. And, unfortunately,
> your favorite use case harder to deal with. So we need to address that.
I disagree here. It's not just my favorite use case that gets harder.
It's the die-die-die behavior (and thus the "keep" resolution to the
drop/modified conflict) that gets obscured. I'm not in favor of such a
thing.
Regards
Markus Wanner
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), (continued)
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/04
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/05
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/05
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/05
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/05
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/06
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/07
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/08
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/09
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/09
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone),
Markus Wanner <=
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/13
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/19
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/19
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/20
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/21
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Hendrik Boom, 2012/06/11
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/12
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), code, 2012/06/19
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), code, 2012/06/21