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
