[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: False conflict with interleaved merge commits

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 8 Feb 2020 04:01:06 +0000

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

This is an archived mail posted to the Subversion Users mailing list.