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