On Sat, Feb 08, 2020 at 04:01:06AM +0000, Daniel Shahaf wrote:
> That's the desired result, isn't it? If so, is there an underlying rule
> here that we could teach Subversion to follow automatically?
The underlying issue is a decision made by the "automatic merge" heuristic.
Note the output of the "problematic" merge performed by the script:
--- Merging differences between repository URLs into 'wcb':
C wcb/A/mu
"Merging differences between repository URls" means that the automatic
merge heuristic has decided to run a "reintegrate merge", rather than a
"sync merge". This decision is consistent with the state of mergeinfo in
the repository at the time the merge command is executed.
Changing the last line in the script as follows to force a sync merge
has the same result as your manual cherry-picking merges:
--- Merging r5 through r7 into 'wcb':
U wcb/A/mu
So, indeed, if there was a way to extend the heuristic to detect this case
the problem could be avoided. I suspect the heuristic only ever looks at
server-side mergeinfo and does not take mergeinfo in the local working copy
into account? See client_find_automatic_merge() in libsvn_client/merge.c.
--- merge-interleave-3.sh.orig Sat Feb 8 09:47:55 2020
+++ merge-interleave-3.sh Sat Feb 8 09:46:37 2020
@@ -118,7 +118,7 @@
# Step 9, the bug.
# The following trunk->branch1 merge should complete successfully, as A/mu has only been edited on trunk and the first edit has already been merged to branch1, but instead it shows a conflict on A/mu as if the first merge never took place and as if A/mu was edited directly in branch1.
${SVN} up wc wcb
-${SVN} merge ${URL}/trunk wcb
+${SVN} merge -r0:HEAD ${URL}/trunk wcb
# Put kill command in a file, in case need to run it manually.
# echo "kill -9 `cat svnserve-pid`" > k
Received on 2020-02-08 09:58:09 CET