Details
-
Improvement
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
trunk
Description
This issue represents the "tree conflicts" portion of improving conflict resolution and/or the behavior of 'merge'. See issue #2830 for the single-file portion of this issue, and an overview of a possible desired behavior (interesting bits here): * If a conflict is encountered, invoke a conflict resolution callback to give a Subversion client a chance to intervene. If resolution is successful, convert the notification from a 'C' to something else (e.g. 'M'). http://subversion.tigris.org/merge-tracking/func-spec.html#conflict-resolution (Ben has implemented this, currently in a manner which works best for files with a common ancestor.) * Otherwise, stop applying merge ranges as soon as a second conflict is encountered in a WC item (as it might generate overlapping conflict makers, or apply a merge inside a conflict marker!), being sure to record partial application of merge ranges. Update (2007/04/23): Discussion with some Subversion dev Googlers indicate that they'd prefer a more comprehensive solution which allows interactivity to be deferred until all possible merging has occurred. (They are not alone in a desire to see this use case handled.) (This has been implemented as part of issue #2830, but in a manner which stops the merge as soon as application of any revision ranges result in a conflict).
http://subversion.tigris.org/merge-tracking/func-spec.html#conflict-resolution