I (Julian Foad) wrote on 2013-01-31:
> Hi Paul. Not sure about this...
1441810 fixes this and extends the test.
- Julian
>> URL: http://svn.apache.org/viewvc?rev=1438683&view=rev
>
>> Log:
>> Fix issue #4306 'multiple editor drive file merges record wrong
>> mergeinfo during conflicts'.
>> @@ -6923,7 +6923,10 @@ do_file_merge(svn_mergeinfo_catalog_t re
>> &filtered_rangelist,
>> mergeinfo_path,
>> merge_target->implicit_mergeinfo,
>> - &range, iterpool));
>> + /* Only record partial mergeinfo if only a partial merge was
>> + performed before a conflict was encountered. */
>> + conflicted_range ? conflicted_range : &range,
>> + iterpool));
>
> Shouldn't that be "the range starting at 'range.start' and
> ending at 'conflicted_range.end'?
>
> It looks to me like it will only record mergeinfo for the sub-range that raised
> the conflict, and not for the earlier sub-ranges that completed successfully.
>
> I'm currently writing an extended test that will cover when a conflict is
> raised in:
>
> { first sub-range of first specified range;
> last sub-range of first specified range;
> first sub-range of last specified range;
> last sub-range of last specified range }
> x
> { single-file merge;
> dir merge }
>
> That should be able to confirm my suspicion about the above code.
>
> I'm doing this because I'm working on refactoring so that the three main
> merge subroutines called from do_merge() (that is the cases: single-file,
> dir-with-mergeinfo, dir-no-mergeinfo), each return info about where they stopped
> if they stopped because of a conflict, instead of throwing an error containing
> that info in human-readable form.
>
> Then I will be able to put the merge in a "do { merge; resolve any
> conflicts } while (merge is not complete)" loop at the 'svn'
> level. And thereby fix interactive conflict resolution which currently aborts
> at this point even if you resolved the conflicts.
>
> - Julian
Received on 2013-02-02 23:36:29 CET