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.
Received on 2014-02-19 12:48:40 CET