Hi,
I've had the same problem. When doing an SVN update (not via tortoise,
but via command
line, in cygwin) subversion failed to lock a file for writing, and hence
the update operation
failed. Trying to clean up also fails since SVN was able to move some
files from the
temporary update directory to the local check out directory before the
write error occured.
The work-around I performed was to move all files that svn says are
missing from the
local checkout directory to the temporary directory and re-do the
cleanup. This was a
messy job since there were many files, and svn only complained about the
first file it noticed as missing...
My guess is that there is a bug in subversion, since the failed update
leaves the subversion directory
in a broken state. A failed operation should leave the directory as it
was before the operation, not
in a semi-completed state from which there is no way (other than to hack
it yourself) to recover.
/Anton
Peter Yamamoto wrote:
>We continue to have problems on multiple machines despite trying to
>avoid all file monitoring type software.
>
>I can't find the message right now, but somebody mentioned an issue with
>repositories rooted in C:\. Unfortunately we inherited a project that
>has to live in C:\ (I can't believe it either) but this is a huge
>project and fixing all the dependencies is out of the question at this
>point.
>
>So is there some bug/issue with C:\.svn?
>
>Oh, something I did determine once you do get into this cycle of errors
>is that if you browse to the/a problem directory (or for example one
>with a lock on it), then try and restart, you can hose yourself because
>explorer.exe can hang on to a file handle for quite a long time after
>you've browsed there. So for example, if you browsed into one of these
>.svn folders to take a peek, then ask for a cleanup, the cleanup can
>fail because of your browsing to that folder (even if you close the
>explorer window!!!). Sysinternal's handle.exe program is good for making
>sure nobody has a handle on the hierarchy structure before you start an
>operation.
>
>But MY GOD!!!! I can't believe we are running into such problems with
>this.
>
>We've already probably spent a year's license time (eg perforce) in
>person hours troubleshooting and attempting to get up and running with
>subversion.
>
>Peter
>
>-----Original Message-----
>From: Peter Yamamoto [mailto:yamamotop@page44.com]
>Sent: Tuesday, March 14, 2006 7:46 PM
>To: Nathan Kidd; users@subversion.tigris.org
>Subject: RE: Re: 'svn cleanup' no workie
>
>I was running filemon earlier and didn't see any extraneous programs
>touching the repository files (only tortoiseproc and tsvncache). I
>believe I have a dump of a complete filemon log to an error but I can't
>remember if that error was the .svn/tmp error or not... I'll check my
>notes.
>
>I have disabled realtime protection of Norton antivirus. However it does
>fire up every once in a while but it only seems to access it's own
>database file (scanning memory? I've looked to try and disable other
>options but don't see them. I may try simply killing the process).
>
>I did notice that running filemon with a limitless log will eventually
>start page faulting quite a bit, so that's why I stopped filemon-ing
>continuously (I also dropped the amount of logging but still felt that
>it hadn't shown any anomolies that I could make sense of).
>
>I have a 98Mb filemon dump of activity to the point of one of these
>errors if anybody is interested and thinks it will shed some light.
>
>If I search for the directory that gave the error I get 2312 hits. Most
>of them are status SUCCESS and DELETE PEND etc. There is a sequence with
>a "BUFFER OVERFLOW" (is that bad? There are accesses that have this as
>well) attached.
>
>But there are success-ful accesses after that.
>
>The one thing that highlights the file that generated the error message
>is that it is the last file referenced before a huge dav-spool run.
>Right after that dav-spool (or during it), it appears the error is
>generated. I'm assuming the access to the wdmaud.drv is it trying to
>play the error sound.
>
>Does that mean anything to anybody?
>Peter
>
>-----Original Message-----
>From: Nathan Kidd [mailto:nathan-svn@spicycrypto.ca]
>Sent: Tuesday, March 14, 2006 3:52 PM
>To: users@subversion.tigris.org
>Subject: Re: 'svn cleanup' no workie
>
>Peter Yamamoto wrote:
>
>
>>I am asking for help to get more information on the problem. The first
>>
>>
>
>
>
>>thing is if other people are experiencing/know about the problem. I
>>did try searching the archives but that didn't seem to get any hits so
>>
>>
>
>
>
>>I subscribed to the list. And lo and behold somebody else mentioned
>>the same problem.
>>
>>In my experience, the reliability of the .svn/tmp manipulation seems
>>to be very unstable.
>>
>>
>
>Hi Peter,
>
>I haven't followed the whole thread, but if .svn/tmp manipulation is
>having problems I wonder if there isn't some unkind process running on
>your machine? I.e. virus scanner, search indexer, etc.
>
>If you can create a small, reproducable recipe then maybe you could run
>filemon [1] and filter for any access to .svn\tmp not by svn.exe.
>
>Just a shot in the dark.
>
>-Nathan
>
>---------------------------------------------------------------------
>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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 21 13:30:14 2006