[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: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone) |
Date: |
Tue, 05 Jun 2012 20:33:11 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) |
Markus Wanner <address@hidden> writes:
> Stephen,
>
> On 06/05/2012 03:47 PM, Stephen Leake wrote:
>>>
>>> A - file 'foo' exists
>>> / | \
>>> M1 M2 D - M1, M2: independent modifications to 'foo'
>>> \ /\ / - D: deletion of 'foo'
>>> P Q - P, Q: merges, adding 'foo' under a new node-id
>>
>> Actually, it's not a duplicate name conflict, it's a special case of
>> drop/modified; the same as the existing test that's currently failing in
>> nvm.issue-209:
>
> Sure? In that case, I don't understand your approach. A drop/modified
> conflict between two different node-ids should be impossible. And I'd
> expect Q to introduce a new node id, given your description.
Yes, but it's the same node that the drop-modify 'keep' resolution would
add.
In the M2/D merge, the conflict is between the modified foo node in M2 and the
dropped foo node in D; the resolution created Q.
In the P/Q merge, the same conflict occurs; the original foo node in Q
is dropped. But the resolution would attempt to create the new foo node
in Q, so instead it reuses it.
>> Right. It's similar to another use case I have, with a vendor branch and
>> a local branch. If the user adds a feature (in a new file) on the local
>> branch, which the vendor then adopts, that's a duplicate name conflict.
>> But resolving it once the wrong way leads to confusion:
>>
>> V L
>> | |
>> V1 L1 new local feature, vendor bug fixes
>> | \ |
>> | L2
>> V2 | vendor adopts local feature
>> | \ |
>> | L3 duplicate name conflict; local drops vendor file (oops)
>> V3 | vendor bug fixes
>> | \ |
>> | L4 duplicate name conflict again; this time, drop local file
>> V4 |
>> \ |
>> L5 no conflicts
>>
>> I was thinking this would lead to a dropped/modified conflict, but I
>> guess it won't. But the confusion about nodes and names is similar.
>
> I don't see the similarity, because it's not about a drop/modify conflict.
>
> Moreover, in L4, you currently won't get no conflict, and correctly so.
> The user has expressed that he wanted to delete the vendor's variant of
> the file and instead use its own. That may well be exactly what she
> wanted in the first place.
I'll write up this test case as well; I now think it will be the same as
the above. This stuff is tricky!
>>> The immediate merge with the user explicitly dropping one file is what
>>> he then can do to work around the short-comings of this approach, yes.
>>> In that case, you've brought two conflicts to the users attention,
>>> instead of none, as monotone currently would.
>>
>> I'm inferring that you agree that's a good thing.
>
> I fear I'm not, sorry. I think it's obfuscating things, instead of a
> clearer failure mode (die-die-die, which is equally wrong, but at least
> simple and clear).
Since the current behavior is not what I want, I think it should be a
conflict, so the user can choose the current behavior (the 'drop'
resolution to the conflict), or something else (the 'keep' or 'user'
resolution to the conflict).
The reason I don't like the current behavior is that sometimes the drop
was a mistake, and it needs to be corrected; the easiest way to bring
that to the user's attention is via a merge conflict.
I'm assuming I'm not the only user with this issue.
>> That's true. I agree that general support for suture would help here; I
>> just think it's not worth the effort of doing that, since this should
>> not happen in a well-managed project, or at least be very rare.
>
> IMO die-die-die works better for "well-managed" projects. The policy is
> simple: never delete something you might want to revert someday.
Well, yes. But I'd call that "perfectly managed" :). And it requires
perfect foresight. People are not perfect, so we need some recovery.
>>>>> In case of M1 and M2 being sequential edits, the user would have to
>>>>> "undelete" the same file several times, consider this:
>>>>>
>>>>> A
>>>>> / \
>>>>> M1 D
>>>>> | \ |
>>>>> M2 P
>>>>> \ /
>>>>> Q
>>>>>
>>>>> If the user chooses to keep the file in both, P and Q, he'd end up with
>>>>> two 'foo' files.
>>>>
>>>> merge to P is the only undelete; merge to Q has a duplicate name conflict.
>>>
>>> Yeah, same issue: modify/delete conflict resolved by keeping (AKA
>>> asymmetrically copying) the file turns into a name conflict.
>>
>> As above, this is not a duplicate name conflict, but a special case of
>> drop/modififed. I will implement this test case to make sure I'm not
>> still missing something.
>
> AFAIUI turning this into a drop/modified conflict would require the
> newly introduced node-id in P to somehow be related to the old node-id
> of the file in A (and later M1, M2).
Yes, by the file name, which is why it looks like a duplicate name conflict.
It will be a problem if the file is renamed between P and the merge.
> Arguably, from a users perspective, it shouldn't be a drop/modify
> conflict, either. She already expressed her wish to keep the file in P.
> Why should she do that again for Q?
I agree she should not have to, but it doesn't work that way because
monotone doesn't have sutures; it forgets about the previous conflict
resolution. This is the core of the complication with sutures; the
mark/merge structures have to store information about all previous
sutures, not just the most recent one.
This will be clearer when I get it implemented (not sutures, just the
special case of dropped/modified :).
--
-- Stephe
- [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), code, 2012/06/03
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/03
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/03
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Markus Wanner, 2012/06/04
- 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 <=
- 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, 2012/06/11
- 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