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
Received on Sat Mar 18 00:56:08 2006