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_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.
>>
> 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.
>
Received on 2016-10-02 07:19:51 CEST