[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflict fix in 1.6.x STATUS

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 18 Aug 2009 20:45:34 +0100

> * 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.