subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: False conflict with interleaved merge commits
Date Sat, 08 Feb 2020 04:01:06 GMT
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

Mime
View raw message