[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: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-06-02 22:14:30 CEST

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

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

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

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 2 22:16:34 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.