You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Florin Avram <fl...@sync.ro> on 2014/02/19 11:50:02 UTC
"svn revert" corrupts working copy
Hi,
I found a situation when using "svn revert" seems to corrupt the working
copy. In a working copy like this:
- wc_root_dir
-- directory
--- file
erase the directory from disk (not using SVN) and create a file with the
same name instead.
"svn status" will report:
~ directory
! directory/file
Now, see the following sequence:
svn revert directory/file
svn: E155009: Failed to run the WC DB work queue associated with
'/wc_root_dir/directory/file', work item 2 (file-install directory/file.
1 0 1 1)
svn: E720087: Can't move '/wc_root_dir/.svn/tmp/svn-3884C5DC' to
'/wc_root_dir/directory/file': The parameter is incorrect.
svn status
svn: E155037: Previous operation has not finished; run 'cleanup' if it
was interrupted
svn cleanup
Gives same message as "svn revert".
svn --version
svn, version 1.8.5 (r1542147)
compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
Regards,
Florin Avram
Re: "svn revert" corrupts working copy
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 19, 2014 at 05:09:11PM +0200, Florin Avram wrote:
> Should I create a new issue regarding the error messages for this situation,
> or someone else does this?!
If you have time to do so that would be great. Thanks!
Re: "svn revert" corrupts working copy
Posted by Florin Avram <fl...@sync.ro>.
I'm glad we found out a common point of view. A better error message,
that indicates the cause (at least, in the provided example, it should
be very clear what is triggering the error), would definitely help save
some time, since no other command works to obtain other information
about this working copy "blockage".
Indeed, I work on Windows.
Should I create a new issue regarding the error messages for this
situation, or someone else does this?!
On 19.02.2014 16:42, Stefan Sperling wrote:
> On Wed, Feb 19, 2014 at 02:52:48PM +0200, Florin Avram wrote:
>> 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
>> When the client states "The parameter is incorrect", this is useless
>> information for a common user (it could be some library internal error?!).
> I agree here. The error messages that result from this problem are
> definitely not user friendly.
>
> This is not a new problem. Subversion has always had problems with
> many of its error messages being far from understandable for users :(
> I actually gave a conference talk on this very subject once, slides at
> http://www.elegosoft.com/files/Downloads/Subversion_Day_2011/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf
>
> In your case, "The parameter is incorrect" is most likely coming from
> the Windows operating system. I'm seeing "is not a directory" instead.
>
>> 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.
> Sometimes, it's hard to do such checks upfront, because we often
> don't know what problems can happen until they actually occur.
> Some operations can have way too many side effects to consider upfront,
> and checking upfront could hurt performance a lot in many cases.
> And if we're not very careful, such checks might actually end up breaking
> legitimate use cases that were overlooked when the checks were implemented.
>
> I think a better approach would be to try to systematically improve all
> error messages raised by the work queue subsystem in the working copy
> library, adding hints to the likely cause of the problem. I'd fully
> support a new entry in our issue tracker for such a task. Most of these
> messages are beyond what a normal user should have to deal with.
>
Re: "svn revert" corrupts working copy
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 19, 2014 at 02:52:48PM +0200, Florin Avram wrote:
> 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
> When the client states "The parameter is incorrect", this is useless
> information for a common user (it could be some library internal error?!).
I agree here. The error messages that result from this problem are
definitely not user friendly.
This is not a new problem. Subversion has always had problems with
many of its error messages being far from understandable for users :(
I actually gave a conference talk on this very subject once, slides at
http://www.elegosoft.com/files/Downloads/Subversion_Day_2011/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf
In your case, "The parameter is incorrect" is most likely coming from
the Windows operating system. I'm seeing "is not a directory" instead.
> 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.
Sometimes, it's hard to do such checks upfront, because we often
don't know what problems can happen until they actually occur.
Some operations can have way too many side effects to consider upfront,
and checking upfront could hurt performance a lot in many cases.
And if we're not very careful, such checks might actually end up breaking
legitimate use cases that were overlooked when the checks were implemented.
I think a better approach would be to try to systematically improve all
error messages raised by the work queue subsystem in the working copy
library, adding hints to the likely cause of the problem. I'd fully
support a new entry in our issue tracker for such a task. Most of these
messages are beyond what a normal user should have to deal with.
Re: "svn revert" corrupts working copy
Posted by Florin Avram <fl...@sync.ro>.
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 <st...@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
>
Re: "svn revert" corrupts working copy
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 19, 2014 at 12:17:06PM +0000, Philip Martin wrote:
> Stefan Sperling <st...@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
Re: "svn revert" corrupts working copy
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@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.
I suppose Subversion could check for such obstructions before creating
the workqueue item and fail with some sort of "cannot revert" error.
Any check like that would have to happen after the outcome of earlier
reverts is known:
svn revert wc/dir wc/dir/file
if the revert of wc/dir is successful then any obstruction of wc/dir has
been removed by the time we attempt to revert wc/dir/file.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: "svn revert" corrupts working copy
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 19, 2014 at 01:07:49PM +0200, Florin Avram wrote:
> Well, this design corrupts the working copy and I cannot use it after. I
> doubt this is what you want...
> I ran into this issue by testing how "svn revert" behaves on different
> strange situations, but, at least theoretically, anybody can run into it.
The working copy is perfectly fine.
A corrupt working copy is one that has a problem a user cannot recover
from without getting a new checkout. But in your case, removing the
obstructing file is all that needs to be done to fix the problem.
The on-disk tree is broken because you moved a file where a directory
should be *without telling svn about it*. This violates Subversion's
usage model, which is very explicit about these things. Some other
systems work differently, but with Subversion you simply have to use svn
commands for all on-disk tree modifications. If you don't, well then
you end up with problems like this.
'svn revert' tries to fix up any discrepancies between the on-disk
state and the working copy's meta data. It tries to ensure that the
on-disk state matches what the working copy meta-data indicates.
In your case it cannot do so without overwriting an unversioned file.
Subversion never deletes unversioned data voluntarily, because it
cannot know if the data is important and if a backup copy exists.
Imagine 'svn revert' overwrote an important file, and you had no backup
of it. You'd probably and rightly complain about that!
We generally don't want Subversion to delete unversioned user data.
Which is why Subversion calls this an 'obstruction'. The status output:
~ directory
! directory/file
indicates exactly what Subversion thinks of this situation.
See 'svn help status':
'!' item is missing (removed by non-svn command) or incomplete
'~' versioned item obstructed by some item of a different kind
So, just move your file to a safe place, and run 'svn revert' again.
Re: "svn revert" corrupts working copy
Posted by Florin Avram <fl...@sync.ro>.
Well, this design corrupts the working copy and I cannot use it after. I
doubt this is what you want...
I ran into this issue by testing how "svn revert" behaves on different
strange situations, but, at least theoretically, anybody can run into it.
On 19.02.2014 13:02, Stefan Sperling wrote:
> On Wed, Feb 19, 2014 at 12:50:02PM +0200, Florin Avram wrote:
>> Hi,
>>
>> I found a situation when using "svn revert" seems to corrupt the working
>> copy. In a working copy like this:
>> - wc_root_dir
>> -- directory
>> --- file
>>
>> erase the directory from disk (not using SVN) and create a file with the
>> same name instead.
>>
>> "svn status" will report:
>> ~ directory
>> ! directory/file
>>
>> Now, see the following sequence:
>>
>> svn revert directory/file
>> svn: E155009: Failed to run the WC DB work queue associated with
>> '/wc_root_dir/directory/file', work item 2 (file-install directory/file. 1 0
>> 1 1)
>> svn: E720087: Can't move '/wc_root_dir/.svn/tmp/svn-3884C5DC' to
>> '/wc_root_dir/directory/file': The parameter is incorrect.
> Subversion is (correctly) trying to put a directory where you put a file.
> Until the obstructing file is removed you'll get this error.
> This is by design.
>
>> svn status
>> svn: E155037: Previous operation has not finished; run 'cleanup' if it was
>> interrupted
>>
>> svn cleanup
>> Gives same message as "svn revert".
>>
>> svn --version
>> svn, version 1.8.5 (r1542147)
>> compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
>>
>> Regards,
>> Florin Avram
Re: "svn revert" corrupts working copy
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 19, 2014 at 12:50:02PM +0200, Florin Avram wrote:
> Hi,
>
> I found a situation when using "svn revert" seems to corrupt the working
> copy. In a working copy like this:
> - wc_root_dir
> -- directory
> --- file
>
> erase the directory from disk (not using SVN) and create a file with the
> same name instead.
>
> "svn status" will report:
> ~ directory
> ! directory/file
>
> Now, see the following sequence:
>
> svn revert directory/file
> svn: E155009: Failed to run the WC DB work queue associated with
> '/wc_root_dir/directory/file', work item 2 (file-install directory/file. 1 0
> 1 1)
> svn: E720087: Can't move '/wc_root_dir/.svn/tmp/svn-3884C5DC' to
> '/wc_root_dir/directory/file': The parameter is incorrect.
Subversion is (correctly) trying to put a directory where you put a file.
Until the obstructing file is removed you'll get this error.
This is by design.
>
> svn status
> svn: E155037: Previous operation has not finished; run 'cleanup' if it was
> interrupted
>
> svn cleanup
> Gives same message as "svn revert".
>
> svn --version
> svn, version 1.8.5 (r1542147)
> compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
>
> Regards,
> Florin Avram