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?
Regards,
Alexey.
Received on 2016-10-02 21:19:31 CEST