I really think it would help if people who experience this report it.
There appears to be a fundamental flaw in the way this is working or
it's presumptions about windows.
Yes, I know it works for 99% of the people, but that doesn't make it
right.
Yes, I know that the people who could provide more insight would really
benefit from a reproducible example, but unfortunately we don't have
that right now. Right now, it would be good to hear anything about what
type of information might be pertinent in advancing the characterization
of this problem.
I guess I could check out and inspect the code, but maybe somebody
already familiar with the .svn manipulation and windows could chime in
with some pointers? Maybe this is a dev topic?
As you say, sometimes there is an easy workaround. The error and the
state of .svn (eg entries, tmp, etc) is such that one (some people) can
figure out what may help a cleanup/update proceed. But with a large
repository, this is not always practical.
I'm just wondering if the dev people think we're loony or are doing
something bad (we've turned off as much file monitoring as is
practical/possible as far as I know, etc, this happens on a "simple"
checkout or update) and hence won't consider these cases. If that is so,
then it is indeed time for us to move on to something more practical.
Peter
-----Original Message-----
From: Anton Persson [mailto:anton@omicron.se]
Posted At: Tuesday, March 21, 2006 4:27 AM
Posted To: SVN users
Conversation: Re: 'svn cleanup' no workie
Subject: Re: 'svn cleanup' no workie
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;
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 21 21:06:58 2006