[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Corrupt .svn directories

From: Robin Pellatt <pellatt_at_mirocs.com>
Date: 2005-06-03 08:58:00 CEST

> Subversion can't have all the information it needs to recover from
> this -- or at least, sometimes it won't have all the information.

Yes it does, have a look at my proposal again:
------------------------------------------------
svn recover

or

svn checkout --recover

This would be similar to a checkout, except for two differences:
1. It would completely ignore any .svn directory already existing, and
simply overwrite these with new ones.
2. It would not check out any file that already exists, but merely make
the relevant entry regarding it in the .svn directory in the usual way.
Files that don't exist will get checked out.
------------------------------------------------
Basically I want the ability to checkout on top of an existing working
copy, without blatting any files I already have there. Subversion could
certainly do this.

> That's because all the information Subversion has about a working copy
> resides in the .svn/ areas. If those are corrupt, then by definition
> Subversion can't trust them, so it can't use that information.

That's the whole point, I just need to recreate these .svn directories.
Correct me if I'm wrong, but as far as I'm aware the .svn directory
contains no information about my edits, only a pristine copy of each
file that was checked out, and information related to that, therefore
all the information needed to do recreate these directories is in the
repository (On further perusal of the docs, there may be other info such
as when I've schedule a new file for addition, but I can live with
losing that).

Robin.

kfogel@collab.net wrote:
> Ryan Schmidt <subversion-2005@ryandesign.com> writes:
>
>>>I've looked through the book, the FAQ, the mailing lists, and
>>>Googled, and the recommended solution seems to be just to move the
>>>whole working copy somewhere, check out a clean copy, and copy
>>>across any changes. OK, fine, I could do this, I've got maybe 20
>>>files changed across a few directories, it wouldn't take *that* long.
>>>
>>>But it seems to me that Subversion actually has all the information
>>>it needs to recover from this situation. All I actually want to do
>>>is force it to recreate all my .svn directories, without messing
>>>with my changed files.
>
>
> Subversion can't have all the information it needs to recover from
> this -- or at least, sometimes it won't have all the information.
> That's because all the information Subversion has about a working copy
> resides in the .svn/ areas. If those are corrupt, then by definition
> Subversion can't trust them, so it can't use that information. All it
> can do is be very sensitive about detecting corruption, so that it
> never mistakenly uses bad information.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 09:00:04 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.