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
