On Sun, Oct 02, 2016 at 12:16:27PM -0700, Alexey Neyman wrote:
> 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
OK. I realize we're not really talking about the same set of problems then :)
> 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'?
There are no such plans. Changing how 'svn merge' works is... not impossible,
but rather difficult, especially when it comes to moves and renames.
Julian Foad has done a lot of research into this:
http://wiki.apache.org/subversion/MoveDev/MoveDev
> 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?
No, that's not on the table for 1.10 AFAIK.
Back in 2011 I did some work on this problem together with Daniel Shahaf.
But it never went anywhere because we found that it didn't help the goal
we were pursuing at the time, which was better tree conflict resolution.
See the fs-successor-ids branch:
http://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/BRANCH-README
Of course, there may be other valid use cases, in which case this branch
could serve as a starting point. The design is done, and most of the
implementation is done, too. Both would need to be updated to account for
changes made since the (biggest relevant change being FSFS format 7).
I'm sorry to disappoint you. It seems your best path forward is to keep
scripting. Unless of course you'd like to try fixing these problems in
core SVN together with us, and drive development of the features you need.
Received on 2016-10-03 10:18:43 CEST