> 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
Received on Thu Jun 2 13:34:45 2005