On Thu, Jan 24, 2013 at 10:16:16PM +0000, Julian Foad wrote:
> Summary: I plan to make 'svn merge' act on --accept=theirs|mine|etc. per file, rather than (as it does now) postponing all conflicts until after the whole merge and then resolving them.
>
>
> I have been investigating the way "--accept=foo" resolves conflicts, for blocker issue #4238 "merge -cA,B with --accept option aborts if rA conflicts" [1]. Postponing all resolution until the end of the whole merge (as we do now) is not good enough in this scenario. A similar scenario can occur during an automatic merge when the merge code internally decides to do a multi-revision-range merge.
>
>
> We need to be able to resolve conflicts at least after each phase (revision range) of merge.
I filed the issue. I think I had in mind that we'd store multiple
conflicts, but I'm not quite sure.
I agree with your plans to deal with the non-interactive --accept case.
I have one concern about the interactive case where no --accept option
was passed, which we might want to consider addressing as well for 1.8.
Currently, 'svn merge' errors out as follows if one of the ranges merged
in a multi-range merge conflicts.
$ svn merge -c3,4 ^/trunk
--- Merging r3 into '.':
C alpha
--- Recording mergeinfo for merge of r3 into '.':
U .
Summary of conflicts:
Text conflicts: 1
Conflict discovered in file 'alpha'.
Select: (p) postpone, (df) diff-full, (e) edit, (m) merge,
(mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p
subversion/svn/util.c:553: (apr_err=155015)
subversion/libsvn_client/merge.c:10904: (apr_err=155015)
subversion/libsvn_client/merge.c:10868: (apr_err=155015)
subversion/libsvn_client/merge.c:9071: (apr_err=155015)
subversion/libsvn_client/merge.c:8763: (apr_err=155015)
subversion/libsvn_client/merge.c:4714: (apr_err=155015)
svn: E155015: One or more conflicts were produced while merging r2:3 into
'/tmp/svn-sandbox/branch' --
resolve all conflicts and rerun the merge to apply the remaining
unmerged revisions
That's fine and expected. It is the same as the --accept=postpone
behaviour you are proposing.
But it seems what's missing is to continue the merge in case no
conflicts are left after the resolver returns. Consider:
$ svn merge -c3,4 ^/trunk
--- Merging r3 into '.':
C alpha
--- Recording mergeinfo for merge of r3 into '.':
U .
Summary of conflicts:
Text conflicts: 1
Conflict discovered in file 'alpha'.
Select: (p) postpone, (df) diff-full, (e) edit, (m) merge,
(mc) mine-conflict, (tc) theirs-conflict, (s) show all options: m
Merging 'alpha'.
Conflicting section found during merge:
(1) their version (at line 1) |(2) your version (at line 1)
--------------------------------------+--------------------------------------
foo |moo
--------------------------------------+--------------------------------------
Select: (1) use their version, (2) use your version,
(e1) edit their version and use the result,
(e2) edit your version and use the result,
(eb) edit both versions and use the result,
(p) postpone this conflicting section leaving conflict markers,
(a) abort file merge and return to main menu: 2
Merge of 'alpha' completed.
Select: (p) postpone, (df) diff-full, (e) edit, (m) merge, (r) resolved,
(mc) mine-conflict, (tc) theirs-conflict, (s) show all options: r
Resolved conflicted state of 'alpha'
subversion/svn/util.c:553: (apr_err=155015)
subversion/libsvn_client/merge.c:10904: (apr_err=155015)
subversion/libsvn_client/merge.c:10868: (apr_err=155015)
subversion/libsvn_client/merge.c:9071: (apr_err=155015)
subversion/libsvn_client/merge.c:8763: (apr_err=155015)
subversion/libsvn_client/merge.c:4714: (apr_err=155015)
svn: E155015: One or more conflicts were produced while merging r2:3 into
'/tmp/svn-sandbox/branch' --
resolve all conflicts and rerun the merge to apply the remaining
unmerged revisions
So the conflict has been resolved, but 'svn merge' stops anyway.
I think it should continue merging further ranges instead.
I don't think we should continue the merge in case any conflicts are
left in the working copy, of course.
Received on 2013-01-25 02:54:16 CET