subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Neyman <>
Subject Re: svn merge --reintegrate like diff
Date Sun, 02 Oct 2016 19:16:27 GMT
On 10/01/2016 10:59 PM, Stefan Sperling wrote:
> On Sat, Oct 01, 2016 at 10:19:34PM -0700, Alexey Neyman wrote:
>> On 09/28/2016 09:49 AM, Stefan Sperling wrote:
>>> Hi Alexey,
>>> Could you compile an SVN client from trunk and try some merges with it,
>>> and let me know how the merging of moves with the new conflict resolver
>>> (which is still work-in-progress) is working out for you?
>>> My goal is to make scripts like yours unnecessary.
>>> The current implementation does not yet detect moves which happened
>>> inside copies, but I hope to get that fixed before release.
>>> Thanks,
>>> Stefan
>> I gave it a try (r1763039) and it is not different from what I see with
>> 1.9.x: the files that were renamed on the branch are still copied from the
>> branch, not renamed on the trunk.
>> I.e.,
>> svn cp $SVNREPO/trunk $SVNREPO/branch/x
>> svn co $SVNREPO/branch/x
>> cd x
>> svn mv foo.c bar.c
>> vi bar.c
>> svn ci
>> cd ..
>> rm -rf x
>> svn co $SVNREPO/trunk
>> cd trunk
>> svn merge ^/branch/x
>> svn info bar.c
>> The last command shows bar.c as being copied, without any changes, from
>> ^/branch/x/bar.c - rather than being copied from ^/trunk/bar.c and modified.
>> And, since there are no changes in the diff, ReviewBoard shows nothing in
>> the diff for bar.c.
> You'll have to produce some kind of tree conflict involving the renamed file.
> The run 'svn resolve' (or use the conflict prompt 'svn merge' opens for you).
> To be clear, 1.10.x will *not* change 'svn merge'.
> It changes post-merge behaviour during tree conflict resolution only.
> I'm afraid this won't fix your problem with ReviewBoard.
Well, tree conflicts during merge is a separate pain point with SVN, but 
here I was referring specifically to the reviewability of the merges - 
so 1.10 will not make this script obsolete, unfortunately. Perhaps, the 
change in merge behavior can be made conditional on some command line 
option, e.g. 'svn merge --replay-merged-renames'?

Also, I was just made aware that the script I posted has a shortcoming 
if the branch being merged has been previously merged into trunk, and 
then had seen more development on the branch (i.e., it is a branch for 
ongoing development, not "merge-and-delete" branch). Thing is, it is not 
very straightforward with Subversion to discover *where this file has 
been copied to*. For example, "I have a file foo.c in revision 111; 
under which name(s) is this file appearing in HEAD?" I think adding an 
ability to obtain this kind of information has been discussed in the 
past - is it on the table for 1.10?


View raw message