> * r38000, r38006, r38099, r38100, r38181
> Don't break the working copy when a tree-conflict features an incoming
> replace.
> Justification:
> My colleagues and some clients are really annoyed by this problem.
> Although it's been fixed, it is not in 1.6.x yet, which is met with
> little understanding. Releasing 1.6.5 without this patch would
> probably be some bad publicity...
> Notes:
> If a merge has a delete followed by an add on the same node, and
> also that node is modified locally, svn tried to create two tree-
> conflicts on the same node. That hit an assertion and bailed out,
> breaking the working copy.
> The cmdline test for this issue is merge_replace_causes_tree_conflict
> in merge_tests.py, should become nr. 133.
> (My `make check' with these revisions merged to 1.6.x is clean)
> Votes:
> +1: neels, stsp
In my testing, the output of "svn status" during the test run shows
incorrect tree conflict information:
[[[
M C 3 1 jrandom svn-test-work/working_copies/merge_tests-133/A/B/E
> local add, incoming add upon merge
M C 3 1 jrandom svn-test-work/working_copies/merge_tests-133/A/mu
> local obstruction, incoming add upon merge
M C 3 1 jrandom svn-test-work/working_copies/merge_tests-133/A/D/G/pi
> local obstruction, incoming add upon merge
M C 3 1 jrandom svn-test-work/working_copies/merge_tests-133/A/D/H
> local obstruction, incoming delete upon merge
]]]
These should all say "local modification" and "incoming delete" (or,
ideally, "incoming replacement").
The reason seems partly to be that the test tries the wrong merge
command:
[[[
svn merge file:///[...]/branch file:///[...]/A [...]/A
--- Merging differences between repository URLs into 'svn-test-work/working_copies/merge_tests-133/A':
C svn-test-work/working_copies/merge_tests-133/A/B/E
C svn-test-work/working_copies/merge_tests-133/A/mu
C svn-test-work/working_copies/merge_tests-133/A/D/G/pi
C svn-test-work/working_copies/merge_tests-133/A/D/H
Summary of conflicts:
Tree conflicts: 4
]]]
which, although its output looks like what we expect, is actually a
nonsensical two-URL merge. The correct merge command would be:
svn merge $URL/branch A
When I try this, the output is:
[[[
--- Merging r2 through r4 into 'svn-test-work/working_copies/merge_tests-133/A':
C svn-test-work/working_copies/merge_tests-133/A/B/E
C svn-test-work/working_copies/merge_tests-133/A/mu
/home/julianfoad/src/subversion-1.6.x/subversion/libsvn_client/merge.c:525: (apr_err=155016)
svn: Attempt to add tree conflict that already exists
]]]
This indicates that the problem is not fixed for node-kind-changing
replacements. However, if the file-replaces-file and dir-replaces-dir
cases are fixed, that is still a major improvement.
If I disable the kind-changing replacement tests, the status after the
merge is:
[[[
C C 3 1 jrandom svn-test-work/working_copies/merge_tests-133/A/B/E
> local add, incoming add upon merge
M C 3 1 jrandom svn-test-work/working_copies/merge_tests-133/A/mu
> local obstruction, incoming add upon merge
]]]
This still doesn't look right: the property status shouldn't show as 'C'
when there's a tree conflict, and I think the tree conflict type should
be "local modification" in both cases.
Perhaps as an intermediate step we can fix the code for same-kind
replacements and shunt the kind-changing replacement tests to a separate
Xfailing test.
Unfortunately I can't do any of this by tomorrow.
It's tempting to say that any improvement is better than none and this
changes a crash into an tree conflict report which, though incorrect, is
better. However, I can't recommend this for back-port in its current
state.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2384930
Received on 2009-08-18 21:46:04 CEST