[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Remote move vs local edit conflict resolution options

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 30 Sep 2016 18:16:32 +0200

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.

Received on 2016-09-30 18:16:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.