Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.8.x
-
None
Description
Using svn, version 1.8.5 (r1542147) compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
Given a working copy with the following structure:
- wc_root_dir -- child_dir --- file.txt
where:
svn status wc_root_dir ~ child_dir ! child_dir/file.txt
Assumming we are not aware of the previous states, run the following commands:
svn revert child_dir/file.txt svn: E155009: Failed to run the WC DB work queue associated with '/wc_root_dir/child_dir/file.txt', work item 2 (file- install child_dir/file.txt. 1 0 1 1) svn: E720087: Can't move '/wc_root_dir/.svn/tmp/svn-3884C5DC' to '/wc_root_dir/child_dir/file.txt': The parameter is incorrect.
svn status child_dir svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
svn cleanup
Same error message as for "svn revert"
As you can see, the first command seems to "block" the working copy. Trying svn status to see what are the states of the items involved (to know what is wrong; we assume that we don't know that the parent item is obstructed) does not work. svn cleanup does not help and any other command on the working copy items is not working also.
So, I see two issues:
- SVN does not provide useful information in this situation. It should tell what is the cause (parent item being obstructed, found a file instead of a directory etc.) to help the user understand the problem. Now, the error messages look like there is a bug in the SVN library (WC DB work queue, 1 0 1 1) or maybe the user did not provide proper command options/parameters (the parameter is incorrect).
- the working copy is "blocked", no other command works until you figure out which is the item causing this, to remove it from disk. At a point, I thought the working copy is corrupted and I need to check out again.
After exchanging some messages on the mailing list, the conclusion was that, at least, the error messages (#1) should be improved, to help the user solve the issue, and save time instead of searching through the working copy structure for items that might look "strange".
Original issue reported by florin_avram