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_at_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.
Received on 2016-09-27 19:12:47 CEST