You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Robin Pellatt <pe...@mirocs.com> on 2005/06/01 10:49:32 UTC
Corrupt .svn directories
Hi Folks,
I have what I think might be a reasonably common problem, but so far
haven't found a good solution. So...
My situation is this:
----------------------------------------------
D:\Projects\XXX>svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
D:\Projects\XXX>svn cleanup
svn: Can't open directory '.svn/tmp': The system cannot find the path
specified.
----------------------------------------------
Now I know this is because some of my .svn directories have been
corrupted (my own fault).
However there doesn't seem to be a clean way to recover from this, and I
know I'm not the only one who has done this.
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. So maybe a command something like:
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.
With this, I would now have exactly what I had before, plus the
equivalent of having done 'svn up'. This sounds to me easy to
implement, and would, I think, be really useful, so what do you guys think?
Cheers,
Robin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Corrupt .svn directories
Posted by Robin Pellatt <pe...@mirocs.com>.
> I would say if you and your developers are routinely corrupting your
> .svn directories, then that is the problem that needs to be addressed.
I didn't say I did this 'routinely', of course not, however when
searching for a solution it was obvious that I'm not the first person to
do this, and surely not the last. There are any number of ways for a
file or directory to get blown away.
> If they are not remaining intact, then that is a
> problem outside of Subversion.
Well, you could say it is a problem that Subversion caused by leaving
it's crap all over the place in the first place (but let's not get into
that one again I'm sure its been discussed to death already)
> And it is a good thing that Subversion
> makes it moderately difficult to recover from this -- make a new working
> copy and manually redo your modifications -- because it encourages the
> developer not to get into this situation.
Why is it a good thing to make disaster recovery difficult? Nobody
tries to do this, yes we use good backup practices etc., but accidents
happen.
Anyway, I think this is actually not the case here, it's just something
that Subversion doesn't make easy.
This was really the point of my original post, it looks to me like it
would be an easy thing to implement, and would help quite a few people.
So why not?
Robin.
Ryan Schmidt wrote:
> On 01.06.2005, at 12:49, Robin Pellatt wrote:
>
>> I have what I think might be a reasonably common problem, but so far
>> haven't found a good solution. So...
>>
>> My situation is this:
>>
>> ----------------------------------------------
>> D:\Projects\XXX>svn up
>> svn: Working copy '.' locked
>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
>> details)
>>
>> D:\Projects\XXX>svn cleanup
>> svn: Can't open directory '.svn/tmp': The system cannot find the path
>> specified.
>> ----------------------------------------------
>>
>> Now I know this is because some of my .svn directories have been
>> corrupted (my own fault).
>>
>> However there doesn't seem to be a clean way to recover from this, and
>> I know I'm not the only one who has done this.
>>
>> 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.
>>
>> [snip]
>
>
> I would say if you and your developers are routinely corrupting your
> .svn directories, then that is the problem that needs to be addressed.
> It is perfectly reasonable for Subversion to assume that its directories
> will remain intact. If they are not remaining intact, then that is a
> problem outside of Subversion. And it is a good thing that Subversion
> makes it moderately difficult to recover from this -- make a new working
> copy and manually redo your modifications -- because it encourages the
> developer not to get into this situation.
>
> Or perhaps it would help us to understand if you listed the steps you
> routinely perform which result in the corrupted .svn directories.
>
>
> ---------------------------------------------------------------------
> 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
Re: Corrupt .svn directories
Posted by Robin Pellatt <pe...@mirocs.com>.
>> But there's also stored *which revision you checked out*.
Hmm, I see what you mean now, this may be the killer blow to my
proposal. In my particular case of corruption, I could guarantee that
there have been no checkins since then, so I know my corrupted working
copy is still at HEAD, but I can see this is not necessarily the case.
I've also recently discovered that with WinMerge, it's not only easy to
compare directories, but also to copy files from one to the other (just
right click on a file marked as different, and select 'copy...'), so I
guess my recovery recipe would now be:
1. Move the corrupted working copy somewhere safe
2. Do a clean checkout
3. Use a good directory compare/merge tool like WinMerge to repair the
changes, keeping in mind there may be new edits to the files you have
edited.
Oh look, that's what I said in my original post. Ahem...
> So I would say that the .svn directories really are quite important, and
> messing them up really is a bad idea.
Then scattering them all over my project files is also a bad idea!!
> It's also possible to have a field day in your operating system
> directories, deleting libraries and configuration files
But this is exactly why all that stuff is nicely tucked away in its own
directory, preferably on another partition. Windows doesn't scatter
registry information all over my daily work.
Yeah, I know, I said I wasn't going to go there, let's leave that one then.
Alright, thanks for the comments guys, at least it has increased my
understanding of how subversion works, and if it has done the same for
one or two other people then it's been worth having the discussion.
Cheers,
Robin.
Ryan Schmidt wrote:
> On 03.06.2005, at 09:41, Ph. Marek wrote:
>
>> On Friday 03 June 2005 08:58, Robin Pellatt wrote:
>>
>>> 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).
>>
>>
>> But there's also stored *which revision you checked out*.
>
>
> Yes, that's the issue I see. For the sake of an example:
>
> You have a working copy of your project's trunk at revision 10, and
> you've made local edits. Now you corrupt your .svn directories somehow,
> and decide to use this hypothetical "svn recover" command. What revision
> does it check out? If you don't supply a revision to the command,
> presumably it checks out HEAD, which, let's say, has by now been bumped
> up to 20 by other developers' commits. So now you have working copy
> files that are based on 10 but due to the newly-rewritten .svn
> directories, Subversion thinks they're based on 20! If you look at a
> diff at this point, you'll see that if you commit, not only will it make
> the edits you deliberately made, but it will also *undo* all the changes
> between 10 and 20. And I don't think we should give the user the
> opportunity to so easily shoot himself in the foot.
>
> So, you might say the solution is that when you run the command, you
> must specify the revision to which the working copy was last updated:
> "svn recover -r 10" perhaps. But how do we know that it was revision 10?
> The "svn info" command cannot be relied upon, since it requires intact
> .svn directories, which we've said we don't have. And the book mentions
> over and over how the revision number is unimportant, and that users
> needn't concern themselves with it, so I don't think the user will have
> it in his head. At the moment, I have 14 working copies of various
> projects. I'm sure I don't know what revision each is at.
>
> What about our perennial favorite, the mixed-revision working copy?
> Because of the way Subversion works it practically guarantees that a
> working copy has mixed revisions, even if that's not what the user
> intended. And in the face of that, an "svn recover" command can't
> possibly recreate it accurately, unless the user were to somehow specify
> the revision of every object in the working copy, and I'm practically
> positive the user doesn't remember that.
>
>
> So I would say that the .svn directories really are quite important, and
> messing them up really is a bad idea. Yes, it's possible for you to mess
> them up, but I'm not sure how Subversion would prevent you from doing
> so. It's also possible to have a field day in your operating system
> directories, deleting libraries and configuration files, but then you
> can't be surprised when the OS doesn't work anymore and you have to
> reinstall it. In the same way, I think you shouldn't be surprised that
> destroying a working copy's internals means you have to start over with
> a new working copy.
>
>
>
--
mirocs OHG
Development, Services and Trade
Am Krež
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Corrupt .svn directories
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 03.06.2005, at 09:41, Ph. Marek wrote:
> On Friday 03 June 2005 08:58, Robin Pellatt wrote:
>
>> 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).
>
> But there's also stored *which revision you checked out*.
Yes, that's the issue I see. For the sake of an example:
You have a working copy of your project's trunk at revision 10, and
you've made local edits. Now you corrupt your .svn directories somehow,
and decide to use this hypothetical "svn recover" command. What
revision does it check out? If you don't supply a revision to the
command, presumably it checks out HEAD, which, let's say, has by now
been bumped up to 20 by other developers' commits. So now you have
working copy files that are based on 10 but due to the newly-rewritten
.svn directories, Subversion thinks they're based on 20! If you look at
a diff at this point, you'll see that if you commit, not only will it
make the edits you deliberately made, but it will also *undo* all the
changes between 10 and 20. And I don't think we should give the user
the opportunity to so easily shoot himself in the foot.
So, you might say the solution is that when you run the command, you
must specify the revision to which the working copy was last updated:
"svn recover -r 10" perhaps. But how do we know that it was revision
10? The "svn info" command cannot be relied upon, since it requires
intact .svn directories, which we've said we don't have. And the book
mentions over and over how the revision number is unimportant, and that
users needn't concern themselves with it, so I don't think the user
will have it in his head. At the moment, I have 14 working copies of
various projects. I'm sure I don't know what revision each is at.
What about our perennial favorite, the mixed-revision working copy?
Because of the way Subversion works it practically guarantees that a
working copy has mixed revisions, even if that's not what the user
intended. And in the face of that, an "svn recover" command can't
possibly recreate it accurately, unless the user were to somehow
specify the revision of every object in the working copy, and I'm
practically positive the user doesn't remember that.
So I would say that the .svn directories really are quite important,
and messing them up really is a bad idea. Yes, it's possible for you to
mess them up, but I'm not sure how Subversion would prevent you from
doing so. It's also possible to have a field day in your operating
system directories, deleting libraries and configuration files, but
then you can't be surprised when the OS doesn't work anymore and you
have to reinstall it. In the same way, I think you shouldn't be
surprised that destroying a working copy's internals means you have to
start over with a new working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Corrupt .svn directories
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Friday 03 June 2005 08:58, Robin Pellatt wrote:
> > 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:
No, it doesn't.
> ...
> 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).
But there's also stored *which revision you checked out*.
This may be not necessary if you're the only developer - but as soon as two
people work together on one repository *you need to know to which revision*
your changes apply; else your changes can't be automatically merged.
It *may* be enough to do a new checkout and copy your old wc files *without
any .svn directories* over the new wc; but I'd be very cautious and use a lot
of "svn diff" to check that I won't overwrite changes done by somebody else.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Corrupt .svn directories
Posted by Robin Pellatt <pe...@mirocs.com>.
> 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 <su...@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
Re: Corrupt .svn directories
Posted by kf...@collab.net.
Ryan Schmidt <su...@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
Re: Corrupt .svn directories
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
Ryan Schmidt wrote:
> On 01.06.2005, at 12:49, Robin Pellatt wrote:
>
>> I have what I think might be a reasonably common problem, but so far
>> haven't found a good solution. So...
>>
>> My situation is this:
>>
>> ----------------------------------------------
>> D:\Projects\XXX>svn up
>> svn: Working copy '.' locked
>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
>> details)
>>
>> D:\Projects\XXX>svn cleanup
>> svn: Can't open directory '.svn/tmp': The system cannot find the path
>> specified.
>> ----------------------------------------------
>>
>> Now I know this is because some of my .svn directories have been
>> corrupted (my own fault).
Last monday we had a similar situation:
One developer created a tar file of his WC and made an 'svn up'
sometime later. After some more time he unpacked his tar file on
top af a freshly checked out WC and overwrote the .svn-directory
there.
Later, he added some files that were new according to 'svn status'.
Then he did 'svn commit' and was greeted with the error message:
"File already exist". At that point he asked me "Why?" and showed
me that 'svn status' believed that the file was not under version
control.
After several retries and some experimenting I realized that his
tar file also included the .svn directory and unpacking it was
hammering the WC into an "older" state.
We checked out the WC again, moved .svn to _.svn, unpacked the tar
file and moved _.svn to .svn. Then we got the right information
from 'svn status'.
(Meanwhile I discovered 'svn status -u'...)
>> [snip]
>
> I would say if you and your developers are routinely corrupting your
> .svn directories, then that is the problem that needs to be addressed.
> It is perfectly reasonable for Subversion to assume that its directories
> will remain intact. If they are not remaining intact, then that is a
> problem outside of Subversion. And it is a good thing that Subversion
> makes it moderately difficult to recover from this -- make a new working
> copy and manually redo your modifications -- because it encourages the
> developer not to get into this situation.
On one hand I fully agree. On the other hand - it would be nice if svn
could check if the .svn is in a proper and actual state. At least that.
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Corrupt .svn directories
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 01.06.2005, at 12:49, Robin Pellatt wrote:
> I have what I think might be a reasonably common problem, but so far
> haven't found a good solution. So...
>
> My situation is this:
>
> ----------------------------------------------
> D:\Projects\XXX>svn up
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
> D:\Projects\XXX>svn cleanup
> svn: Can't open directory '.svn/tmp': The system cannot find the path
> specified.
> ----------------------------------------------
>
> Now I know this is because some of my .svn directories have been
> corrupted (my own fault).
>
> However there doesn't seem to be a clean way to recover from this, and
> I know I'm not the only one who has done this.
>
> 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.
>
> [snip]
I would say if you and your developers are routinely corrupting your
.svn directories, then that is the problem that needs to be addressed.
It is perfectly reasonable for Subversion to assume that its
directories will remain intact. If they are not remaining intact, then
that is a problem outside of Subversion. And it is a good thing that
Subversion makes it moderately difficult to recover from this -- make a
new working copy and manually redo your modifications -- because it
encourages the developer not to get into this situation.
Or perhaps it would help us to understand if you listed the steps you
routinely perform which result in the corrupted .svn directories.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org