[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: |
Wed, 06 Jun 2012 14:10:27 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 |
Hi,
On 06/06/2012 02:33 AM, Stephen Leake wrote:
> Yes, but it's the same node that the drop-modify 'keep' resolution would
> add.
Yeah, I'm assuming Q to be the result of the drop-modify 'keep'
resolution as well.
> 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.
Ah, right, each modification conflicts with the delete over and over
again. I didn't think of that part. So the file isn't even properly
resurrected, but every modification on the parent branch leads to a new
drop/modify conflict, for which the user needs to re-iterate his
decision. Awkward.
> 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).
AFAIU your proposed approach makes the 'drop' choice non-permanent. In
that aspect, the user cannot choose the current behavior anymore, no.
Working around the drop/modify conflict by manually re-adding the file
is a once-per-erroneous delete operation. How can the user work around
the "cannot-drop-persistently" issue that your approach would introduce?
Admittedly, with the current approach, you'll also see the drop/modified
warning once-per-modification on an intentionally deleted file. But it's
just a warning, no user action is required, the file remains deleted, as
the user asked for.
Overall, this doesn't look like a win to me.
> 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.
Sure. The same can be said for intentional deletes: Sometimes the drop
is intended, and it needs to persist; the easiest way to achieve that is
die-die-die merge. Neither of these two options is a reason to always
prefer one over the other.
The current approach (die-die-die together with the warning) being
easier to handle (and work around, if necessary) *is* a reason for that
option, though.
> 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.
Yeah, the 'keep' resolution might not be able to *add* the file again
under the same name, because such a file already exists. It's not a
duplicate name conflict because of the merge, but one that arises by
resolving the drop/modify conflict that way.
Ever thought of what happens with modifications on both node-ids after a
'keep' resolution, but before merging?
Regards
Markus Wanner
- [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, 2012/06/05
- 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/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
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone), Stephen Leake, 2012/06/21