subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: r1438683 - issue #4306 'multiple editor drive file merges record wrong mergeinfo during conflicts'
Date Mon, 04 Feb 2013 22:08:56 GMT
Paul Burba wrote:

> Julian Foad wrote:
>> I (Julian Foad) wrote on 2013-01-31:
>>> Hi Paul.  Not sure about this...
>> 1441810 fixes this and extends the test.
> Thanks Julian.
> I added r1441810 to the issue #4306 group on 1.7.x, with the caveat
> that property conflicts are not handled properly in 1.7, rendering
> your latest version of the test problematic on that branch -- see

OK, but something's lost in the translation.  You say you "reworked the earlier version of
test to demonstrate the problem r1441810 fixes", but it fixes two problems (quoting from the
log msg):

(1) It didn't abort if there were conflicts on the last sub-range of a non-last
requested range.  (2) When aborting with conflicts it recorded mergeinfo
describing only the current sub-range, not the sub-ranges merged before the

Your test only specifies a single range ("all") to merge, so it can't test (1).

Something looks wrong in this hunk of your change, at least with the comment:

   # Previously this test failed because the merge failed after merging
-  # only r2 (as it should) but mergeinfo for r5-6 was recorded, preventing
+  # only r5 (as it should) but only mergeinfo for r5 was recorded, even
+  # though preventing
   # subsequent repeat merges from applying the operative r5.
     "Incorrect mergeinfo set during conflict aborted merge",
-    ['/iota:2-4\n'], [], 'pg', SVN_PROP_MERGEINFO, iota_copy_path)
+    ['/iota:2-6\n'], [], 'pg', SVN_PROP_MERGEINFO, iota_copy_path)

On trunk, there were two previous buggy behaviours: most recently, mergeinfo for only r5 would
have been recorded here, but before your initial fix (and, I guess, in 1.7.x) mergeinfo for
the whole requested range (including in this case r3, r5, r7) was recorded; the latter is
therefore what we want to mention here.

- Julian

View raw message