[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: |
Mon, 04 Jun 2012 20:02:33 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) |
Markus Wanner <address@hidden> writes:
> Hi,
>
> On 06/03/2012 05:57 PM, Stephen Leake wrote:
>>> fixed in branch nvm.issue-209; dropped/modified conflicts are fully
>>> supported.
>>
>> I think this needs some review before I merge it to main.
>
> I'm surprised issue 209 doesn't mention die-die-die merge. I consider
> this a work-around to that problem.
Yes, it is. But I was more focussed on the immediate use case. I kept
seeing the warning about "changes will be lost" fly by, and thinking
"that should be handled by the conflict resolution process". So now it
is.
I moved the discussion of the 'dropped/modified' conflict to right after
the missing root conflict (which is where 'die-die-die' is introduced in
the manual), and it now mentions 'die-die-die'.
> As such, it doesn't help in the rare case of a "missing root
> conflict", for example. More importantly, it's troublesome in cases
> involving multiple edits conflicting with one delete. With "parallel"
> modifications:
>
> 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
P is just a normal merge, while Q re-adds foo. Now it is a duplicate
name conflict, with the resolution of keep one (with merged
contents), delete the other.
> 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.
Nothing replaces good management and solid naming conventions in the
first place :).
But I don't see any show stoppers here, just complicated situations.
It might be worth writing up these cases in tests to prove that, but
then it's hard to tell when to stop.
I think the second one would be sufficient in the tests.
>> In particular, the resolution process allows keeping the modified file.
>> This is implemented as a drop and add, which is what the user would do.
>> But it is done during a merge, so merge can now create new nodes.
>
> That's why I'd argue that "fully supported" is an exaggeration, as the
> "resurrected" file is disconnected from its previous versions, as you
> pointed out yourself.
Ok. Perhaps you could review what it says in monotone.texi, and possibly
reword.
> Ways of re-connecting it have been discussed before, but yeah, it's been
> awhile since the last die-die-die discussion...
Right; I started trying to do that in the 'file sutures stuff'. Way too
hard, for very little gain :).
Thanks for your input.
--
-- 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 <=
- 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, 2012/06/11