I think I know enough about Subversion and work with it for more than 5
years, so I know very well what obstructed and missing means, and that
Subversion tries to not erase non-versioned data.I know only less about
new SVN 1.8.x behavior, which I'm testing currently, and which in some
situations is not to explicit and it does not help a common user (even
if comparing it with older versions, many commands became powerful,
especially with the new SVN 1.7 architecture). Not all users work with
an SVN client or with the command-line client directlyand/or often-
there are infinite use-cases and tools that work over a working copy
non-aware of SVN. The client should help, as much as possible, the users
to fix things when they switch from their development tool to SVN.And I
say this from my experience, after interacting with many users that
found themselves in the situation of not knowing what to do further at a
given point, so any information pointing to the correct cause in solving
any issue is essential.Users are error prone and may not have enough
experience with Subversion - help them.
I understand your point, but I have the feeling somewhere there is not a
correct decision and things can be improved.
What I'm trying to say is that what Subversion does in this case is not
too obvious. Think to the following situation:
- wc_root_dir
-- dir1/file.txt
-- dir2/file.txt
Now, dir2 is obstructed and a user wants to revert dir1/file.txt. By
mistake, he can type dir2/file.txt, so:
- svn gives error and points to "svn cleanup"
- the user tries "svn cleanup" and it does not work;
- then, it tries "svn status" to see what are the states of the items,
this way he can figure out if there is something wrong. It does not work
also.
The errors provided by Subversion do not point to the fact that there is
an obstructed item and the obstructing item must be removed.
What I reported previously was an information I already knew (the
directory being obstructed), but given current situation, the user
doesn't know that dir2 is obstructed (he wanted to work with dir1) and
he cannot find out this using any Subversion client (since SVN givesa
useless error).
When the client states "The parameter is incorrect", this is useless
information for a common user (it could be some library internal
error?!).I remember that, in SVN 1.6.x, for some similar situations,
there were some messages like"found a file instead of a versioned
directory" or so - this is something useful, that points to the correct
problem. But, as long as, in the given situation, the user cannot run
"cleanup" or "status" to know more about what is happening, the next
idea it has is that the working copy is corrupted and it needs to check
out again.
I agree with Philip Martin - before doing any changes to the working
copy (and block it, from my point of view, after the example situation)
it should do some checks and warn the user that the operation is not
possible. This allows to work with the working copy further (runt other
commands) and fix the issue.
Regards,
Florin
On 19.02.2014 14:36, Stefan Sperling wrote:
On Wed, Feb 19, 2014 at 12:17:06PM +0000, Philip Martin wrote:
Stefan Sperling <s...@elego.de> writes:
So, just move your file to a safe place, and run 'svn revert' again.
In this case it's 'svn cleanup' after removing the obstruction.
Then I misunderstood the original problem report.
Can you give me a reproduction recipe? Here's what I did:
$ ls epsilon
zeta
$ rm -rf epsilon
$ echo > epsilon
$ svn st
~ epsilon
! epsilon/zeta
$ svn revert epsilon/zeta
svn: E155009: Failed to run the WC DB work queue associated with
'/tmp/svn-sandbox/trunk/epsilon/zeta', work item 5 (file-install epsilon/zeta 1
0 1 1)
svn: E000020: Can't move '/tmp/svn-sandbox/trunk/.svn/tmp/svn-6SoBLy' to
'/tmp/svn-sandbox/trunk/epsilon/zeta': Not a directory
$ svn cleanup
svn: E155009: Failed to run the WC DB work queue associated with
'/tmp/svn-sandbox/trunk', work item 5 (file-install epsilon/zeta 1 0 1 1)
svn: E000020: Can't move '/tmp/svn-sandbox/trunk/.svn/tmp/svn-Sm3yxt' to
'/tmp/svn-sandbox/trunk/epsilon/zeta': Not a directory
$ mv epsilon outoftheway
$ svn cleanup
$ svn st
? outoftheway
$ svn --version
svn, version 1.8.5 (r1542147)
compiled Jan 30 2014, 02:45:04 on x86_64-unknown-openbsd5.5
