Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.6.x
Description
To reproduce:
Create a tree conflict upon update with an incoming replacement. The conflict is summarized as "local
X, incoming delete". Run 'svn status -u' within a subdirectory of the tree conflict victim. In some cases,
the status command fails with "Two top-level reports with no target".
To resolve the conflict, revert the victim. The victim is now unversioned, which is strange, because both
the local user and the repository are trying to add it.
Expected behavior:
The tree conflict should be displayed as "local X, incoming replace". Reverting the tree conflict victim
should remove local changes in favor of the incoming replacement.
Workaround:
Delete the unversioned items manually (to avoid unversioned-vs-add tree conflicts) and run update
again.
Affects:
1.6.x and pre-1.7 as of r1101762.
The unversioned-victims problem was reported by Andrew Buchanan on the users' list:
http://svn.haxx.se/users/archive-2011-04/0231.shtml
This issue may be related to issue #3569 "svn update --depth <DEPTH> allows making a working copy
incomplete".
In libsvn_wc/update_editor.c:
The delete half of the incoming replacement creates the tree conflict. To avoid clobbering the local
changes, the victim is "re-added in place" as if copied from history. See issue #3334 "Tree conflict
merry-go-round on update/switch" for
The add half of the replacement is handled poorly. The add_file() callback is written with a false
assumption:
/* [...]
Note that we can safely assume that no present base node exists,
because then we would not have received an add_file.
*/
Original issue reported by sbutler