On Fri, Aug 11, 2017 at 09:26:14PM +0000, Blaine Whittle wrote:
> I'm seeing different behavior with automatic conflict resolver when operating against a 1.10.0-alpha3 compared to a 1.7.10 server. I'm using a 1.10.0-alpha3 client.
>
> Test case
>
> * Create branch B from branch A.
> * Checkout branch B.
> * Modify file contents in branch B + commit.
> * Move / rename file in branch A + commit.
> * Merge branch B back to branch A.
>
> When testing against both servers, the client was correctly identified that the file was moved and the revision(s) of the move / rename. However, when testing against the 1.7.10 server the client did not automatically resolve the tree conflict and emitted the text "Subversion is not smart enough to resolve this tree conflict automatically!"
>
> The exact output from a 1.7.10 server was
> U .
> Summary of conflicts:
> Tree conflicts: 1
> Searching tree conflict details for 'testfile.txt' in repository:
> Checking r538794... done
> Tree conflict on 'testfile.txt':
> Changes destined for a file arrived via the following revisions during merge of
> '^/branches/merge-test-trunk/testfile.txt:538791-538800':
> r538798 by bwhittle
> No such file or directory was found in the merge target working copy.
> The item was moved away to '^/trunk/test/testfile2.txt' in r538794 by bwhittle.
>
> Subversion is not smart enough to resolve this tree conflict automatically!
> See 'svn help resolve' for more information.
>
> Select: (p) Postpone, (r) Mark as resolved, (h) Help, (q) Quit resolution:
>
> Whereas the 1.10.0 server produced
> U .
> Summary of conflicts:
> Tree conflicts: 1
> Searching tree conflict details for 'foo/bar4.txt' in repository:
> Checking r20... done
> Tree conflict on 'foo/bar4.txt':
> Changes destined for a file arrived via the following revisions during merge of
> '^/branches/branch3/foo/bar4.txt:19-22':
> r18 by user1, r19 by user1, r21 by user1
> No such file or directory was found in the merge target working copy.
> The item was moved away to '^/trunk/foo/bar.txt' in r20 by user1.
> And then moved away to '^/trunk/bar2.txt' by user1 in r22.
> Select: (p) Postpone, (r) Mark as resolved,
> (m) Apply to move destination, (h) Help, (q) Quit resolution: m
> G bar2.txt
> Tree conflict at 'foo/bar4.txt' marked as resolved.
> Summary of conflicts:
> Tree conflicts: 0 remaining (and 1 already resolved)
>
> The 1.10.0 server test shows two file renames whereas the 1.7.10 only had one. This is correct and expected behavior in both cases.
>
> The same client machine was used in both tests. It's possible I'm doing something wrong and the issue isn't related to the server version. However I've rerun slightly different versions of this test and got the same results.
>
Hi Blaine,
It looks like the 1.7 repository you were testing with already has a lot
of history as the revision numbers are quite large.
Whereas your 1.10 case shows much smaller revision numbers.
Can you reproduce the 1.10 behaviour if you create a fresh repository
on the 1.7 server?
Are you using any kind of scripting or automation when running these tests?
I found that manual testing has sometimes made it hard for me to reproduce
results I got earlier, when my memory was too hazy and there were a lot
of steps involved in my tests.
If you could write your tests as scripts (with some interactive input where
necessary), and share those scripts, it would be easier to discuss the
specific situations you are dealing with. This would also make it possible to
reinterpret your use cases as regression tests for Subversion's test suite.
Thanks for your help with testing, it is very much appreciated!
Stefan
Received on 2017-08-15 10:44:27 CEST