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@33'
to
'^/serf/trunk/serf.h@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@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
