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.
>
> Regards,
> Alexey.
> >
>
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.
Received on 2016-10-02 08:00:12 CEST