Stefan Sperling wrote on Fri, 07 Feb 2020 08:44 +0100:
> Which is why I see no way to fix this in SVN itself.
> If we made SVN record r5 during the original merge (before r5 existed),
> that would be wrong.
> And if we made SVN skip A/mu edits from r5 during the conflicting merge,
> that would be wrong, too.
>
> So to me it looks like this needs to be handled by synchronizing
> your developers. Sorry :-/
Quick question. I commented out the last merge in Daniel's script (line 121),
ran the script, then ran the following by hand:
[[[
% cd wcb
% svn mergeinfo --show-revs=eligible ../wc
r5
r7
% svn merge -c 5 ../wc
--- Recording mergeinfo for merge of r5 into '.':
U .
% svn merge -c 7 ../wc
--- Merging r7 into '.':
U A/mu
--- Recording mergeinfo for merge of r7 into '.':
G .
% svn di
Index: A/mu
===================================================================
--- A/mu (revision 7)
+++ A/mu (working copy)
@@ -1 +1 @@
-Edit 1 of A/mu in trunk
+Edit 2 of A/mu in trunk
Index: .
===================================================================
--- . (revision 7)
+++ . (working copy)
Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
## -0,0 +0,1 ##
Merged /trunk:r5,7
%
]]]
That's the desired result, isn't it? If so, is there an underlying rule
here that we could teach Subversion to follow automatically?
Cheers,
Daniel
Received on 2020-02-08 05:01:20 CET