On Jun 20, 2007, at 02:42, Clemens wrote:
> it seems, that 'svn revert' does not totally get rid of information
> of a
> former deletion schedule of a directory. Please see the following
> (output of svn command indented):
>
> # First create a repos to play with
> svnadmin create bug_deldir.repos
>
> # Now create the structure necessary to demonstrate the problem
> svn mkdir file:///$(pwd)/bug_deldir.repos/test
>
> Committed revision 1.
> svn mkdir file:///$(pwd)/bug_deldir.repos/test/dir -m ""
>
> Committed revision 2.
>
> # Get a fresh working copy of the above
> svn co file:///$(pwd)/bug_deldir.repos/test
> A test/dir
> Checked out revision 2.
>
> # Now the game begin
> cd test
>
> # Remove (accidentally) a directory under svn's control
> rm -rf dir
>
> # Ask 'svn' and get the information, that you messed with the
> contents
>
> svn st
> ! dir
>
> # Okay back-up and check if all is like before ...
>
> svn revert .
> svn st
> ! dir
>
> # 'svn revert' didn't work as was to be expected by documentation!
What documentation are you reading? It should not suggest that "svn
revert" will undo "rm -rf dir" because, as you've seen, it won't.
You're not supposed to do "rm -rf dir", and if you do inadvertently,
then the way to recover the directory is "svn up" as you also
discovered. "svn revert dir" is supposed to undo "svn rm dir" and
that's how I believe it's documented. If you have suggestions for
improving the documentation in this regard, by all means make them.
But note that suggestions about the book found at http://svnbook.org
should be made to their mailing list, not this one.
> # So take 'svn update' now and check again:
>
> svn update .
> A dir
> Updated to revision 2.
> svn st
>
> # Yay! All okay, as I never did anything wrong ... :-)
> # Now I think, I will schedule 'dir' to be removed from svn's
> control
> # Do not forget to check the outcome ...
>
> svn delete dir
> D dir
> svn st
> D dir
>
> # Nice! All as I have expected. But now I change my mind and
> 'revert'
> # the scheduled deletion. Do not forget to check what svn things
> about
>
> svn revert dir
> Reverted 'dir'
> svn st
>
> # Okay 'svn st' did not find any modification. All as it was before.
> # Now do the same mistake done before. Remove 'dir' without
> scheduling
> # any deletion that time. Do not miss to check, what svn things
> about
>
> rm -rf dir
> svn st
> D dir
>
> # NAAAHHHH!!! What's that? Auto-scheduled deletion. Nay nay nay :-(
> # Worser then, if I do 'svn ci' the deletion will really get
> committed
>
> In summary, if I remove a directory that is under Subversion's control
> without scheduleing a deletion before, Subversion will report it and
> deny to commit the mess I did!
>
> But only as long as I *never* did schedule said directory to be
> deleted
> any time in the past of my working copy. If I did (and reverted that
> deletion before commit), any subsequent physical remove of the
> directory
> will result into a auto-scheduled deletion that will be committed
> too if
> I did not pay attention to the output!
>
> I think, that is a bug, as it is different for deleted-and-then-
> reverted
> files that behave as I would expect.
>
> What do you think?
I think you didn't tell us what platform you're on or what version of
Subversion you're using. But, I was also able to reproduce this bug
with Subversion 1.4.4 on Mac OS X 10.4.9 with Intel Core 2 Duo using
your reproduction recipe, and it does sound like a bug to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 20 10:52:40 2007