On 09/28/2016 09:49 AM, Stefan Sperling wrote:
On Tue, Sep 27, 2016 at 10:12:28AM -0700, Alexey Neyman wrote:
On 09/27/2016 01:46 AM, Daniel Shahaf wrote:
Johan Corveleyn wrote on Mon, Sep 26, 2016 at 13:04:04 +0200:
Maybe I'm missing something, but I don't understand why 'svn diff
--old=TRUNK --new=BRANCH' would show you things that you previously
merged from TRUNK to BRANCH. It should show exactly the content-wise
difference between TRUNK and BRANCH, so if some content was merged
from TRUNK to BRANCH, both should be identical on that point, and it
shouldn't show up in 'diff'.
That command would also show changes made on trunk that have not yet been
merged to the branch. (E.g., if you ran it in on subversion's trunk and
1.9.x branch, it would show -SVN_VER_MINOR 10\n +SVN_VER_MINOR 9\n.)
The OP asked for the changes merge would do, which is approximately
--old=TRUNK@REV --new=BRANCH
where REV is the youngest revision of trunk merged to the branch.
("Approximately" because this is inaccurate when cherry-picks or subtree
merges hapepned.)
There's one more issue with these approaches. ReviewBoard can be smart about
displaying the moved/copied files. However:
- If one does 'svn merge --reintegrate', Subversion will copy new files from
the branch unchanged, and 'svn diff' will not show them (and hence, RB won't
either) - or, with --show-copies-as-adds, it will show them as being added
anew. For the review purposes, it would be better if instead of copying the
file from the branch unchanged, Subversion would perform the same move on
the trunk and apply the textual changes.
- If you do 'svn diff --old=... --new=...', I believe the copy-from
information is lost from the diff completely - and ReviewBoard will show all
the moved files as adds/deletes, not showing diffs either.
For now, I am using the attached script to perform this task. The workflow
is:
1. Perform a merge to trunk.
2. Run the script (which attempts to find the original location in trunk for
every copied file and replay the move on trunk).
3. 'rbt post'.
The script is not perfect; it only operates at file level - so if there are
renamed directories, the files inside them end up in 'R +' status (replaced
with history) and ReviewBoard shows a spurious deletion for this file, in
addition to a move/copy with changes.
Regards,
Alexey.
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.
