On Fri, Sep 30, 2016 at 07:09:15PM +0300, Evgeny Kotkov wrote:
> Hi,
>
> I was thinking about which options should be offered by the tree conflict
> resolver in a common case with a catch-up merge when a file is moved
> away in trunk and edited on the branch. (Limiting the scope to a case
> when we can detect the move.)
>
> Currently, the resolver offers the "move local file and merge" option, but
> also offers to ignore or accept the incoming deletion:
> [[[
>
> File merged from
> '^/serf/trunk/serf.h_at_33'
> to
> '^/serf/trunk/serf.h_at_36'
> was moved to '^/serf/trunk/serf_deprecated.h' by evgeny.kotkov in r35.
> A file which differs from the corresponding file on the merge source branch
> was found in the working copy.
>
> (p) - skip this conflict and leave it unresolved [postpone]
> (r) - accept current working copy state [working]
> (i) - ignore the deletion of '^/serf/trunk/serf.h_at_36'
> (a) - accept the deletion of 'serf.h'
> (m) - move 'serf.h' to 'serf_deprecated.h' and merge
> (h) - show this help (also '?')
> (q) - postpone all remaining conflicts
>
> Select: (p) postpone, (r) accept current working copy state,
> (i) ignore incoming deletion, (a) accept incoming deletion,
> (m) move 'serf.h' to 'serf_deprecated.h' and merge,
> (h) help, (q) quit resolution:
>
> ]]]
>
> The resolver says that it has detected a move, so options "(i) ignore
> incoming deletion" and "(a) accept incoming deletion" can confuse the
> users (what's deleted?). And, if we know that it's actually a move, I
> cannot think of a case where ignoring or accepting the deletion would
> prove useful.
>
> Perhaps, for cases when we know that a move happened, it would be better
> to just say:
>
> Select: (p) postpone, (r) accept current working copy state,
> (m) move 'serf.h' to 'serf_deprecated.h' and merge,
> (h) help, (q) quit resolution:
>
> I could implement this behavior. How does it sound?
>
>
> Regards,
> Evgeny Kotkov
I'd say yes, let's try that.
The delete options are there now because I added them before adding
a move+merge option became possible.
One concern is that perhaps the move heuristic gets it wrong,
and there was in fact a deletion. But if that happens we should
fix the problem where it really is: in the move detection algorithm.
Thanks!
Received on 2016-09-30 18:16:42 CEST