Quoting Stephen Butler <sbutler_at_elego.de>:
> The status of 1.6-blocker #3209 (see r35877):
The good news: this isn't really a blocker. The current inconsistency
in tree conflict detection is a bug, but the working copy is left in
a usable state.
The bad news: the bug might not be fixable in the current design of
Background: the merge code runs in a second set of callbacks (in
libsvn_wc/repos_diff.c) on top of the usual delta editor callbacks.
The current state: within a repos_diff callback, we can't tell
whether a nonexistent dir is really nonexistent, or just missing.
The former is a tree conflict, the latter should not be a TC.
The repos_diff callbacks do a great job of filtering out the info
we really need for tree conflict detection! :-\ But that's been
discussed at length last year. In r33989, Neels & co. added a
tree_conflicted boolean arg to all the relevant callbacks, so that
all of the tree conflict detection can be done in
libsvn_client/merge.c, where it's easy to follow. This lets us
avoid raising a tree conflict inside a TC victim tree, but it's
not enough to tell whether an item is really nonexistent or is
> Tackle the last holdout from issue #3209: merge encounters missing
> files and dirs. Create tests that try to merge changes into missing
> trees. Make them pass, given the current behavior.
> The current behavior is inconsistent. A missing file is not treated
> as a merge tree conflict. A missing dir, that the merge wants to
> delete, is also not treated as a tree conflict.
> The next steps are to determine the desired behavior, adjust the test
> expectations, and set the tests to XFAIL. Then fix it!
> * subversion/tests/cmdline/svntest/actions.py
> (deep_trees_rmtree): New helper function.
> * subversion/tests/cmdline/merge_tests.py
> tree_conflicts_merge_del_onto_missing): New tests.
> (test_list): Add new tests.
> It's been suggested that we shouldn't raise any tree conflicts on
> missing items.
> I went ahead and implemented this behavior (still testing before
I won't commit my new hack, because it causes us to miss a lot of
tree conflicts in use case 4, "local (committed) delete, incoming
edit upon merge".
> The tree conflicts due to local deletions are still
Oops, my quick hack raises them only for uncommitted deletions.
> The current change affects only missing items.
Not true, see above. It prevents the detection of nonexistent
> IMHO, it's OK to have no tree conflict here. The user gets a
> summary at the end of the merge output, which is hard to miss.
> Summary of conflicts:
> Skipped paths: 1
> And of course the user can't commit without updating to restore
> the missing items.
> It's a little weird that a missing file is given empty mergeinfo,
> but a missing dir is not. Is that the way it's supposed to be?
Still an open question.
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2009-02-16 17:05:43 CET