You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2003/05/19 14:11:13 UTC
svn.collab.net is now running Subversion 0.23.
subject sez all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> -1
>
> Just upgrading BDB, after the fiasco that caused last time, is not a
> good idea.
>
> Instead, let's start serious stress (and performance) tests of BDB
> 4.1.x. I can try to do the Windows bit, if somebody can explain how to
> change stress.pl to not use fork.
Sorry, there were two data in my mind that I didn't say:
1. I knew that Mike Pilato has been using 4.1.25 for regular
testing, and that he plans to run it through stress.pl.
2. We later determined that there were many horked things about the
installation on svn.collab.net, which Greg Stein discovered and
cleaned up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>Well, apart from the svn_io_rename_file problem, and the deadlock buglet
>>-- both of which show up with 4.0.14 -- BDB 4.2.15 works after a fashion
>>
>>
> ^^^^^^
>
>That's really 4.1.25, right?
>
>
Yah, typo.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> Well, apart from the svn_io_rename_file problem, and the deadlock buglet
> -- both of which show up with 4.0.14 -- BDB 4.2.15 works after a fashion
^^^^^^
That's really 4.1.25, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, May 22, 2003 at 01:05:20PM -0600, D.J. Heap wrote:
> By the way, I can reproduce this in seconds with my test program now,
> *if* I turn on Sophos AV realtime scanning. But I'm not sure it is
> really the same problem. It's possible Sophos is exaggerating a Windows
> problem, or it could just be causing a different but similar problem, so
> I'm trying to remove it from the equation.
I would like to repro it without the AV running, as the AV could be written to
scan any file when it is closed.
>
> If anyone is interested I can provide the (fairly small and ugly) test
> program. It tries to mirror what I think is basically happening in
> Subversion:
>
> Create a temp file,
> update the temp file,
> close the temp file,
> turn read-only bit on for the temp file,
> turn off the read-only bit of the *real* file,
> rename the temp file onto the *real* file.
>
> Does this sequence look correct to the svn developers out there?
>
> Of course, it doesn't recreate the problem yet without AV scanning
> going.
:(
>
> DJ
>
> -----Original Message-----
> From: D.J. Heap [mailto:djheap@dhiprovo.com]
> Sent: Thursday, May 22, 2003 12:42 PM
> To: 'Kevin Pilch-Bisson'
> Cc: 'Philip Martin'; dev@subversion.tigris.org
> Subject: RE: svn.collab.net is now running Subversion 0.23.
>
>
> I haven't tried repro-ing with one stress.pl yet -- I have had three or
> four going when it happens...I've been trying (and so far wasting quite
> a bit of time) to reproduce it in a test program. I'll start up a
> single stress now and let it go.
>
> I haven't been tracking the stress.pl failures really closely, since I
> was hoping to get a test program going, but I will start doing that
> since I'm losing hope on the test program, at least until I understand
> better the sequence of operations.
>
> DJ
>
>
> -----Original Message-----
> From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
> Sent: Thursday, May 22, 2003 5:20 AM
> To: D.J. Heap
> Cc: 'Philip Martin'; dev@subversion.tigris.org
> Subject: Re: svn.collab.net is now running Subversion 0.23.
>
>
> I'd like to try to help track this down if I can, so I'd really
> appreciate
> some info on the circumstances under which it is happening.
>
> 1) Does this repro with only one instance of stress.pl (as phillip
> suggested
> trying).
> 2) This is happening on commit only also on updates?
> 3) Does it only affect entries files?
> 4) I thought I saw Brane say that the destination didn't exist. Why
> didn't
> it, if it is just updating an entries file?
>
> Can anyone give me some clearer details here?
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email
> in error please notify the system manager.
>
> This footnote also confirms that this email message has been
> swept by MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Windows 'Access Denied' errors
Posted by Jack Repenning <jr...@collab.net>.
At 9:45 AM -0600 5/23/03, D.J. Heap wrote:
>Jack Repenning wrote:
>>I think you can get "access denied" if someone else is dorking with
>>_the_directory_ that contains the file.
>
>Hmm, do you mean like adding/removing files in the same dir or
>moving/deleting the directory?
Well, I'm not exactly sure *what* I mean; it's a hazy memory. As
best I recall, it went like this:
We had a distributed service that involved files (something called
"ClearCase"; perhaps you've heard of it?). We had some files stored
on a Windows (VOB) server (WinNT 4.0sp6, I'm pretty sure). We had
both Windows and Unix clients of these files (don't ask, I just don't
want to go there). We had a Windows NFS-server product installed to
make that happen. Occasionally, things would lock up. Eventually
(with the help of the NFS product vendor) we discovered that the NFS
server would "lock" the directories in some sense, and at times
neglect to lift the lock. We were never, so far as I can recall,
clear even on what user operation led to the problem, let alone what
code the server was executing (and failing to un-execute). We had a
tool from the NFS vendor that would relinquish these locks, which we
ended up running every five minutes or something like that. But I
might be wrong about nearly any detail in that list.
But I do recall that the precise symptom depended on the interface
you used to test it. The most reliable test was to open a cmd.exe
window, on the server, and "dir" around until you found a directory
with owner shown as "Unavailable". Other symptoms included several
different errors, including (I think) "Access Denied" and "Illegal
Access."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Windows 'Access Denied' errors
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Jack Repenning wrote:
> At 7:17 PM -0600 5/22/03, D.J. Heap wrote:
>
>> Yes, this is the one big clue (it seems to me) that NTFS may be at
>> fault...access denied is the return code, not sharing violation. I
>> can only make access denied errors occur if the destination file is
>> read-only or if I don't have permissions to one of the files. Sharing
>> violation is the normal return code for 'something else is dorking
>> with the file' type situations. Perhaps filter drivers can screw with
>> that, though, I don't know...
>
>
> I think you can get "access denied" if someone else is dorking with
> _the_directory_ that contains the file.
>
> "dir" in the cases I'm thinking of shows "Illegal access" (and no
> directory contents), or something close to that.
Hmm, do you mean like adding/removing files in the same dir or
moving/deleting the directory?
I've had a single stress.pl running on two machines all night long (up
to revisions 7200 and 5400) and no troubles so far.
However, on my work machine (dual processor -- well hyperthreaded --
with Sophos) it died with access denied at revision 1204. But after
more investigation it was because I had not completely disabled AV -- so
it starts a nightly scan of the whole machine and looking at the AV
logs, stress.pl died at about the time the AV scan reached those
directories. And now I'm suspecting that is what caused my other
'access denied' failures...I've never had them during the day (with AV
off). Argh.
Of course, that doesn't explain Brane's failure...but I'm to the point
now where I think all my failures can be laid at AV scanning's door. I
will start up multiple stresses tomorrow if I have no more failures
today or tonight with AV *uninstalled*. I wish I could leave it that
way permanently.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Windows 'Access Denied' errors was: Re: svn.collab.net is
now running Subversion 0.23.
Posted by Jack Repenning <jr...@collab.net>.
At 7:17 PM -0600 5/22/03, D.J. Heap wrote:
>Yes, this is the one big clue (it seems to me) that NTFS may be at
>fault...access denied is the return code, not sharing violation. I
>can only make access denied errors occur if the destination file is
>read-only or if I don't have permissions to one of the files.
>Sharing violation is the normal return code for 'something else is
>dorking with the file' type situations. Perhaps filter drivers can
>screw with that, though, I don't know...
I think you can get "access denied" if someone else is dorking with
_the_directory_ that contains the file.
"dir" in the cases I'm thinking of shows "Illegal access" (and no
directory contents), or something close to that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Windows 'Access Denied' errors was: Re: svn.collab.net is now
running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> Branko Čibej wrote:
>
>> Nonsense. Any system component may touch the files I create only in a
>> way that doesn't interfere with normal file handling semantics. I submit
>> that any filter drivers that are fiddling with those files are broken if
>> my user-mod app can detect them (via an access-denied status on move,
>> for example).
>
>
> Yes, this is the one big clue (it seems to me) that NTFS may be at
> fault...access denied is the return code, not sharing violation. I
> can only make access denied errors occur if the destination file is
> read-only or if I don't have permissions to one of the files. Sharing
> violation is the normal return code for 'something else is dorking
> with the file' type situations. Perhaps filter drivers can screw with
> that, though, I don't know...
Filter drivers can screw with anything they like. A very powerful tool
-- full protective clothing required, and your life insurance doesn't
cover it. :-)
> Anyway, immediately after getting a failure I can go look at the files
> -- the destination file is not read-only and I have full permissions
> on both. AND a simple retry works.
Exactly. That means there's a reace somewhere. Whether we can uncover it
using a simple testcase remains to be seen...
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Windows 'Access Denied' errors was: Re: svn.collab.net is now running
Subversion 0.23.
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Branko Čibej wrote:
> Nonsense. Any system component may touch the files I create only in a
> way that doesn't interfere with normal file handling semantics. I submit
> that any filter drivers that are fiddling with those files are broken if
> my user-mod app can detect them (via an access-denied status on move,
> for example).
Yes, this is the one big clue (it seems to me) that NTFS may be at
fault...access denied is the return code, not sharing violation. I can
only make access denied errors occur if the destination file is
read-only or if I don't have permissions to one of the files. Sharing
violation is the normal return code for 'something else is dorking with
the file' type situations. Perhaps filter drivers can screw with that,
though, I don't know...
Anyway, immediately after getting a failure I can go look at the files
-- the destination file is not read-only and I have full permissions on
both. AND a simple retry works.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Kevin Pilch-Bisson wrote:
>Here's a quote I got about the subject:
>"even without a virusscanner, you just can't assume that you're the only
>component interested in a file. You "must" write your code with the
>assumption that there will be a sharing violation when you try to open the
>file. Indexing service, disk defragmenter, backup software, etc are all
>possibilities."
>
Bah. I don't have disk defragmenter, nor backup software running on my
system. Just stress.pl on an NTFS mounted on a RAM-based disk device.
SVN is creating all the files in this case. If the indexing service is
blocking access to my files, then that's a bug in the indexing service,
so sorry.
>Looks like the best approach would be to trap the error, and retry. (Given
>this argument, I might argue that it belongs in APR too.)
>
Nonsense. Any system component may touch the files I create only in a
way that doesn't interfere with normal file handling semantics. I submit
that any filter drivers that are fiddling with those files are broken if
my user-mod app can detect them (via an access-denied status on move,
for example).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
This is one of the basic semantic differences for file behavior between
Windows and a unix-type OS, right? A unix OS allows the opening or
moving or deletion of files that are in use by another process
(ref-counting and inode thingies?), while Windows does not unless all
processes explicitly declare the sharing semantics when they open...I
think?
If that is true, then retrying is about the only way to handle it in
Windows, I guess, unless you can get all processes to cooperate. Haha.
I'm inclined to say it should go into Subversion rather than APR,
though, since apparently MS expects applications to do the retrying (or
they would do it in the APIs?)...but I have no strong feelings. I will
probably take a shot at a patch for svn_io_file_rename later tonight or
tomorrow, if no one else wants to.
DJ
-----Original Message-----
From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
Sent: Thursday, May 22, 2003 9:52 AM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
Here's a quote I got about the subject:
"even without a virusscanner, you just can't assume that you're the only
component interested in a file. You "must" write your code with the
assumption that there will be a sharing violation when you try to open
the
file. Indexing service, disk defragmenter, backup software, etc are all
possibilities."
Looks like the best approach would be to trap the error, and retry.
(Given
this argument, I might argue that it belongs in APR too.)
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
Here's a quote I got about the subject:
"even without a virusscanner, you just can't assume that you're the only
component interested in a file. You "must" write your code with the
assumption that there will be a sharing violation when you try to open the
file. Indexing service, disk defragmenter, backup software, etc are all
possibilities."
Looks like the best approach would be to trap the error, and retry. (Given
this argument, I might argue that it belongs in APR too.)
On Thu, May 22, 2003 at 02:20:57PM -0600, D.J. Heap wrote:
> Yes, I definitely agree there is a bug somewhere...at this point I have
> no idea where it is at, but I'm doubting more and more that it is really
> in Windows. Brane, you were running on a ramdisk, right? Is it a MS
> supported ramdisk driver?
>
> For the stat64 calls -- I believe apr does the stat calls as part of the
> setting-read-only-on-off, and I have included that piece of apr code in
> the test program, so I think I've got those covered.
>
> I have also run four of them in different directories simultaneously
> trying to stress the file system and no luck so far.
>
> The feedback I've gotten from MS (just on their
> microsoft.public.win2000.file_system newsgroup) is that they strongly
> believe it is a third party service or AV type utility (even inactive)
> and that CloseHandle is definitely synchronous -- meaning the kernel and
> file system do all work and remove sharing reservations before the call
> returns.
>
> So far I have been completely unable to reproduce this on any machine
> but my multiprocessor one that has Sophos on it.
>
> DJ
>
> -----Original Message-----
> From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
> Sent: Thursday, May 22, 2003 1:39 PM
> To: dev@subversion.tigris.org
> Subject: Re: svn.collab.net is now running Subversion 0.23.
>
>
> "D.J. Heap" <dj...@dhiprovo.com> writes:
>
> > By the way, I can reproduce this in seconds with my test program now,
> > *if* I turn on Sophos AV realtime scanning. But I'm not sure it is
> > really the same problem. It's possible Sophos is exaggerating a
> Windows
> > problem, or it could just be causing a different but similar problem,
> so
> > I'm trying to remove it from the equation.
>
> If switching on "Sophos AV realtime scanning" causes a working program
> to fail then that looks like a bug to me. As I have no idea what
> "realtime scanning" involves I can't say whether it a bug in your
> program, in Sophos, or in Windows.
>
> > If anyone is interested I can provide the (fairly small and ugly) test
> > program. It tries to mirror what I think is basically happening in
> > Subversion:
> >
> > Create a temp file,
> > update the temp file,
> > close the temp file,
> > turn read-only bit on for the temp file,
> > turn off the read-only bit of the *real* file,
> > rename the temp file onto the *real* file.
> >
> > Does this sequence look correct to the svn developers out there?
>
> If I strace a commit (only bar1/foo1 modified) on Linux I see
>
> open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
> = 3
> open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
> = 3
> open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
> = 3
> open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/.svn/entries",
> O_RDONLY) = 3
> open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries",
> O_RDONLY) = 3
> open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar2/.svn/entries",
> O_RDONLY) = 3
> open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/entri
> es", O_WRONLY|O_CREAT, 0666) = 13
> stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries
> ", {st_mode=S_IFREG|0444, st_size=781, ...}) = 0
> chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries"
> , 0666) = 0
> rename("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/ent
> ries",
> "/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries") = 0
> stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries
> ", {st_mode=S_IFREG|0644, st_size=797, ...}) = 0
> chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries"
> , 0444) = 0
>
> so it looks like you are missing some stat calls.
>
> > Of course, it doesn't recreate the problem yet without AV scanning
> > going.
>
> Perhaps you need to stress the filesystem, i.e. have a second
> program/thread which is just opening, reading and/or writing, and then
> closing a set of files.
>
> --
> Philip Martin
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email
> in error please notify the system manager.
>
> This footnote also confirms that this email message has been
> swept by MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
> Irrelevant. The error is from the filesystem, not the disk driver --
and
> the filesystem happens to be NTFS in this case, which by all the gods
is
> supported by Microsoft.
True.
> I think it's a race in the filesystem. The fact that you can expose it
> by turning on Sophos' intercheck seems to confirm that -- it changes
the
> timings just enough for the problem to show up, when it wouldn't in a
> "normal" test case.
Yes, that makes sense, but I don't think MS will seriously investigate
until there's a small repro program that fails on a freshly installed
machine without any 3rd party stuff. I'm still working with it, but I'm
not optimistic...
DJ
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
>Yes, I definitely agree there is a bug somewhere...at this point I have
>no idea where it is at, but I'm doubting more and more that it is really
>in Windows. Brane, you were running on a ramdisk, right? Is it a MS
>supported ramdisk driver?
>
Irrelevant. The error is from the filesystem, not the disk driver -- and
the filesystem happens to be NTFS in this case, which by all the gods is
supported by Microsoft.
I think it's a race in the filesystem. The fact that you can expose it
by turning on Sophos' intercheck seems to confirm that -- it changes the
timings just enough for the problem to show up, when it wouldn't in a
"normal" test case.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
Yes, I definitely agree there is a bug somewhere...at this point I have
no idea where it is at, but I'm doubting more and more that it is really
in Windows. Brane, you were running on a ramdisk, right? Is it a MS
supported ramdisk driver?
For the stat64 calls -- I believe apr does the stat calls as part of the
setting-read-only-on-off, and I have included that piece of apr code in
the test program, so I think I've got those covered.
I have also run four of them in different directories simultaneously
trying to stress the file system and no luck so far.
The feedback I've gotten from MS (just on their
microsoft.public.win2000.file_system newsgroup) is that they strongly
believe it is a third party service or AV type utility (even inactive)
and that CloseHandle is definitely synchronous -- meaning the kernel and
file system do all work and remove sharing reservations before the call
returns.
So far I have been completely unable to reproduce this on any machine
but my multiprocessor one that has Sophos on it.
DJ
-----Original Message-----
From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
Sent: Thursday, May 22, 2003 1:39 PM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
"D.J. Heap" <dj...@dhiprovo.com> writes:
> By the way, I can reproduce this in seconds with my test program now,
> *if* I turn on Sophos AV realtime scanning. But I'm not sure it is
> really the same problem. It's possible Sophos is exaggerating a
Windows
> problem, or it could just be causing a different but similar problem,
so
> I'm trying to remove it from the equation.
If switching on "Sophos AV realtime scanning" causes a working program
to fail then that looks like a bug to me. As I have no idea what
"realtime scanning" involves I can't say whether it a bug in your
program, in Sophos, or in Windows.
> If anyone is interested I can provide the (fairly small and ugly) test
> program. It tries to mirror what I think is basically happening in
> Subversion:
>
> Create a temp file,
> update the temp file,
> close the temp file,
> turn read-only bit on for the temp file,
> turn off the read-only bit of the *real* file,
> rename the temp file onto the *real* file.
>
> Does this sequence look correct to the svn developers out there?
If I strace a commit (only bar1/foo1 modified) on Linux I see
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
= 3
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
= 3
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
= 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/.svn/entries",
O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries",
O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar2/.svn/entries",
O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/entri
es", O_WRONLY|O_CREAT, 0666) = 13
stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries
", {st_mode=S_IFREG|0444, st_size=781, ...}) = 0
chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries"
, 0666) = 0
rename("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/ent
ries",
"/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries") = 0
stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries
", {st_mode=S_IFREG|0644, st_size=797, ...}) = 0
chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries"
, 0444) = 0
so it looks like you are missing some stat calls.
> Of course, it doesn't recreate the problem yet without AV scanning
> going.
Perhaps you need to stress the filesystem, i.e. have a second
program/thread which is just opening, reading and/or writing, and then
closing a set of files.
--
Philip Martin
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
"D.J. Heap" <dj...@dhiprovo.com> writes:
> By the way, I can reproduce this in seconds with my test program now,
> *if* I turn on Sophos AV realtime scanning. But I'm not sure it is
> really the same problem. It's possible Sophos is exaggerating a Windows
> problem, or it could just be causing a different but similar problem, so
> I'm trying to remove it from the equation.
If switching on "Sophos AV realtime scanning" causes a working program
to fail then that looks like a bug to me. As I have no idea what
"realtime scanning" involves I can't say whether it a bug in your
program, in Sophos, or in Windows.
> If anyone is interested I can provide the (fairly small and ugly) test
> program. It tries to mirror what I think is basically happening in
> Subversion:
>
> Create a temp file,
> update the temp file,
> close the temp file,
> turn read-only bit on for the temp file,
> turn off the read-only bit of the *real* file,
> rename the temp file onto the *real* file.
>
> Does this sequence look correct to the svn developers out there?
If I strace a commit (only bar1/foo1 modified) on Linux I see
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/.svn/entries", O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries", O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar2/.svn/entries", O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/entries", O_WRONLY|O_CREAT, 0666) = 13
stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries", {st_mode=S_IFREG|0444, st_size=781, ...}) = 0
chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries", 0666) = 0
rename("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/entries", "/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries") = 0
stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries", {st_mode=S_IFREG|0644, st_size=797, ...}) = 0
chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries", 0444) = 0
so it looks like you are missing some stat calls.
> Of course, it doesn't recreate the problem yet without AV scanning
> going.
Perhaps you need to stress the filesystem, i.e. have a second
program/thread which is just opening, reading and/or writing, and then
closing a set of files.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
By the way, I can reproduce this in seconds with my test program now,
*if* I turn on Sophos AV realtime scanning. But I'm not sure it is
really the same problem. It's possible Sophos is exaggerating a Windows
problem, or it could just be causing a different but similar problem, so
I'm trying to remove it from the equation.
If anyone is interested I can provide the (fairly small and ugly) test
program. It tries to mirror what I think is basically happening in
Subversion:
Create a temp file,
update the temp file,
close the temp file,
turn read-only bit on for the temp file,
turn off the read-only bit of the *real* file,
rename the temp file onto the *real* file.
Does this sequence look correct to the svn developers out there?
Of course, it doesn't recreate the problem yet without AV scanning
going.
DJ
-----Original Message-----
From: D.J. Heap [mailto:djheap@dhiprovo.com]
Sent: Thursday, May 22, 2003 12:42 PM
To: 'Kevin Pilch-Bisson'
Cc: 'Philip Martin'; dev@subversion.tigris.org
Subject: RE: svn.collab.net is now running Subversion 0.23.
I haven't tried repro-ing with one stress.pl yet -- I have had three or
four going when it happens...I've been trying (and so far wasting quite
a bit of time) to reproduce it in a test program. I'll start up a
single stress now and let it go.
I haven't been tracking the stress.pl failures really closely, since I
was hoping to get a test program going, but I will start doing that
since I'm losing hope on the test program, at least until I understand
better the sequence of operations.
DJ
-----Original Message-----
From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
Sent: Thursday, May 22, 2003 5:20 AM
To: D.J. Heap
Cc: 'Philip Martin'; dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
I'd like to try to help track this down if I can, so I'd really
appreciate
some info on the circumstances under which it is happening.
1) Does this repro with only one instance of stress.pl (as phillip
suggested
trying).
2) This is happening on commit only also on updates?
3) Does it only affect entries files?
4) I thought I saw Brane say that the destination didn't exist. Why
didn't
it, if it is just updating an entries file?
Can anyone give me some clearer details here?
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
I haven't tried repro-ing with one stress.pl yet -- I have had three or
four going when it happens...I've been trying (and so far wasting quite
a bit of time) to reproduce it in a test program. I'll start up a
single stress now and let it go.
I haven't been tracking the stress.pl failures really closely, since I
was hoping to get a test program going, but I will start doing that
since I'm losing hope on the test program, at least until I understand
better the sequence of operations.
DJ
-----Original Message-----
From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
Sent: Thursday, May 22, 2003 5:20 AM
To: D.J. Heap
Cc: 'Philip Martin'; dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
I'd like to try to help track this down if I can, so I'd really
appreciate
some info on the circumstances under which it is happening.
1) Does this repro with only one instance of stress.pl (as phillip
suggested
trying).
2) This is happening on commit only also on updates?
3) Does it only affect entries files?
4) I thought I saw Brane say that the destination didn't exist. Why
didn't
it, if it is just updating an entries file?
Can anyone give me some clearer details here?
On Wed, May 21, 2003 at 08:48:43AM -0600, D.J. Heap wrote:
> The other odd thing is that normally a file still in use (like
> CloseHandle hasn't been called) gives a different return code (File in
> use), not Access Denied. I guess since CloseHandle has been called,
> though, the file is in some oddball state or something. I'll look and
> ask around on the MS dev forums.
>
> DJ
>
> -----Original Message-----
> From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
> Sent: Wednesday, May 21, 2003 8:18 AM
> To: dev@subversion.tigris.org
> Subject: Re: svn.collab.net is now running Subversion 0.23.
>
>
> "D.J. Heap" <dj...@shadyvale.net> writes:
>
> > Simply retrying the MoveFileEx seems to work fine most of the
> > time...once in a while it requires multiple retries to get through,
> > though. A Sleep(1) in front of the retry has been 100% successful
for
> > me so far, though I'd guess that's just timing luck. It certainly
has
> > the feel of a race.
>
> I am a little surprised, I would expect a race to be much more widely
> seen, but I did find this
>
> http://www.cvsnt.org/pipermail/cvsnt/2003-February/005151.html
>
> "Basically, when you call CloseHandle, it doesn't actually close the
> handle, it just asks to OS nicely to do it when it gets around to it.
> This can randomly cause the MoveFileEx that happens about 100th of a
> second later to fail with a locked file."
>
> I don't know enough about Windows to be able to say if the explanation
> is correct, but the symptoms sound the same.
>
> Now when Subversion calls svn_io_file_rename it always expects the
> rename to succeed, perhaps we should use that knowledge and change
> svn_io_file_rename to something like
>
> status = apr_file_rename (...);
> #ifdef SVN_WIN32
> if (status is "Access is denied")
> {
> status = apr_file_rename (...); // immediate retry
> if (status is "Access is denied")
> {
> apr_sleep (...); // or some sort of Windows flush or
magic
> SVN_ERR (apr_file_rename (...));
> }
> }
> #endif
>
> We can't really do that in APR since it is, in general, perfectly
> acceptable for apr_file_rename to fail with a permissions problem.
>
> --
> Philip Martin
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
I'd like to try to help track this down if I can, so I'd really appreciate
some info on the circumstances under which it is happening.
1) Does this repro with only one instance of stress.pl (as phillip suggested
trying).
2) This is happening on commit only also on updates?
3) Does it only affect entries files?
4) I thought I saw Brane say that the destination didn't exist. Why didn't
it, if it is just updating an entries file?
Can anyone give me some clearer details here?
On Wed, May 21, 2003 at 08:48:43AM -0600, D.J. Heap wrote:
> The other odd thing is that normally a file still in use (like
> CloseHandle hasn't been called) gives a different return code (File in
> use), not Access Denied. I guess since CloseHandle has been called,
> though, the file is in some oddball state or something. I'll look and
> ask around on the MS dev forums.
>
> DJ
>
> -----Original Message-----
> From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
> Sent: Wednesday, May 21, 2003 8:18 AM
> To: dev@subversion.tigris.org
> Subject: Re: svn.collab.net is now running Subversion 0.23.
>
>
> "D.J. Heap" <dj...@shadyvale.net> writes:
>
> > Simply retrying the MoveFileEx seems to work fine most of the
> > time...once in a while it requires multiple retries to get through,
> > though. A Sleep(1) in front of the retry has been 100% successful for
> > me so far, though I'd guess that's just timing luck. It certainly has
> > the feel of a race.
>
> I am a little surprised, I would expect a race to be much more widely
> seen, but I did find this
>
> http://www.cvsnt.org/pipermail/cvsnt/2003-February/005151.html
>
> "Basically, when you call CloseHandle, it doesn't actually close the
> handle, it just asks to OS nicely to do it when it gets around to it.
> This can randomly cause the MoveFileEx that happens about 100th of a
> second later to fail with a locked file."
>
> I don't know enough about Windows to be able to say if the explanation
> is correct, but the symptoms sound the same.
>
> Now when Subversion calls svn_io_file_rename it always expects the
> rename to succeed, perhaps we should use that knowledge and change
> svn_io_file_rename to something like
>
> status = apr_file_rename (...);
> #ifdef SVN_WIN32
> if (status is "Access is denied")
> {
> status = apr_file_rename (...); // immediate retry
> if (status is "Access is denied")
> {
> apr_sleep (...); // or some sort of Windows flush or magic
> SVN_ERR (apr_file_rename (...));
> }
> }
> #endif
>
> We can't really do that in APR since it is, in general, perfectly
> acceptable for apr_file_rename to fail with a permissions problem.
>
> --
> Philip Martin
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email
> in error please notify the system manager.
>
> This footnote also confirms that this email message has been
> swept by MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
cmpilato@collab.net writes:
> You really don't think APR should do this?
It was more of an assumption on my part that the APR maintainers would
object. The MoveFileEx in apr_file_rename could legitimately fail
because of a permissions problem, it could be a permanent failure that
is not going to be "cured" simply by sleeping or by sort of filesystem
flush. In those circumstances the overhead of a one second sleep
could well be deemed intolerable.
I certainly won't object if apr_file_rename fixes the problem :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 21, 2003 at 10:36:48PM +0200, Branko ??ibej wrote:
> cmpilato@collab.net wrote:
>
> >Philip Martin <ph...@codematters.co.uk> writes:
>...
> > I think this is a perfectly reasonable thing to ask of
> >APR. If, in fact, there is a real permissions problem, the second
> >rename attempt would be allowed to fail with that error.
> >
> >You really don't think APR should do this?
>
> No, I think it shouldn't. It's not APR's mandate to provide reliable
> functionality; the mission statement reads "consistent if not
> identical", so this is quite all right.
Agreed.
We know that it should succeed, but APR doesn't know that. And it really
shouldn't go and do all that work to try and force it.
> What's more, we actually know that there _can't_ be a permission
> problem, since we're creating the files oursleves. So yes, something
> like this might be appropriate; but I'd rather create a small testcase
> and send it to MS. D.J.'s right -- the handle must be in an inconsistent
> state in order to get an access deined error, and that state simply
> shouldn't be visible to a (user mode) applicaition.
It's a known problem that obviously hits users. We should go ahead and work
around the issue rather than just hope that MSFT will eventually get it
fixed.
Adequate docco in the code would be great.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>Now when Subversion calls svn_io_file_rename it always expects the
>>rename to succeed, perhaps we should use that knowledge and change
>>svn_io_file_rename to something like
>>
>> status = apr_file_rename (...);
>>#ifdef SVN_WIN32
>> if (status is "Access is denied")
>> {
>> status = apr_file_rename (...); // immediate retry
>> if (status is "Access is denied")
>> {
>> apr_sleep (...); // or some sort of Windows flush or magic
>> SVN_ERR (apr_file_rename (...));
>> }
>> }
>>#endif
>>
>>We can't really do that in APR since it is, in general, perfectly
>>acceptable for apr_file_rename to fail with a permissions problem.
>>
>>
>
>I dunno about all that, now. APR's job is to provide reliable
>functionality across all platforms. Certainly that task includes
>making up for shortcoming in those areas of operating systems that
>have them.
>
It's not a shortcoming, it's a fact. And yes, CloseHandle is
asynchronous (internally, that is -- theoretically it should block the
caller, but it's notoriously hard to do that in the filesystem
implementation).
> I think this is a perfectly reasonable thing to ask of
>APR. If, in fact, there is a real permissions problem, the second
>rename attempt would be allowed to fail with that error.
>
>You really don't think APR should do this?
>
>
No, I think it shouldn't. It's not APR's mandate to provide reliable
functionality; the mission statement reads "consistent if not
identical", so this is quite all right.
What's more, we actually know that there _can't_ be a permission
problem, since we're creating the files oursleves. So yes, something
like this might be appropriate; but I'd rather create a small testcase
and send it to MS. D.J.'s right -- the handle must be in an inconsistent
state in order to get an access deined error, and that state simply
shouldn't be visible to a (user mode) applicaition.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by cm...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Now when Subversion calls svn_io_file_rename it always expects the
> rename to succeed, perhaps we should use that knowledge and change
> svn_io_file_rename to something like
>
> status = apr_file_rename (...);
> #ifdef SVN_WIN32
> if (status is "Access is denied")
> {
> status = apr_file_rename (...); // immediate retry
> if (status is "Access is denied")
> {
> apr_sleep (...); // or some sort of Windows flush or magic
> SVN_ERR (apr_file_rename (...));
> }
> }
> #endif
>
> We can't really do that in APR since it is, in general, perfectly
> acceptable for apr_file_rename to fail with a permissions problem.
I dunno about all that, now. APR's job is to provide reliable
functionality across all platforms. Certainly that task includes
making up for shortcoming in those areas of operating systems that
have them. I think this is a perfectly reasonable thing to ask of
APR. If, in fact, there is a real permissions problem, the second
rename attempt would be allowed to fail with that error.
You really don't think APR should do this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
The other odd thing is that normally a file still in use (like
CloseHandle hasn't been called) gives a different return code (File in
use), not Access Denied. I guess since CloseHandle has been called,
though, the file is in some oddball state or something. I'll look and
ask around on the MS dev forums.
DJ
-----Original Message-----
From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
Sent: Wednesday, May 21, 2003 8:18 AM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
"D.J. Heap" <dj...@shadyvale.net> writes:
> Simply retrying the MoveFileEx seems to work fine most of the
> time...once in a while it requires multiple retries to get through,
> though. A Sleep(1) in front of the retry has been 100% successful for
> me so far, though I'd guess that's just timing luck. It certainly has
> the feel of a race.
I am a little surprised, I would expect a race to be much more widely
seen, but I did find this
http://www.cvsnt.org/pipermail/cvsnt/2003-February/005151.html
"Basically, when you call CloseHandle, it doesn't actually close the
handle, it just asks to OS nicely to do it when it gets around to it.
This can randomly cause the MoveFileEx that happens about 100th of a
second later to fail with a locked file."
I don't know enough about Windows to be able to say if the explanation
is correct, but the symptoms sound the same.
Now when Subversion calls svn_io_file_rename it always expects the
rename to succeed, perhaps we should use that knowledge and change
svn_io_file_rename to something like
status = apr_file_rename (...);
#ifdef SVN_WIN32
if (status is "Access is denied")
{
status = apr_file_rename (...); // immediate retry
if (status is "Access is denied")
{
apr_sleep (...); // or some sort of Windows flush or magic
SVN_ERR (apr_file_rename (...));
}
}
#endif
We can't really do that in APR since it is, in general, perfectly
acceptable for apr_file_rename to fail with a permissions problem.
--
Philip Martin
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
"D.J. Heap" <dj...@shadyvale.net> writes:
> Simply retrying the MoveFileEx seems to work fine most of the
> time...once in a while it requires multiple retries to get through,
> though. A Sleep(1) in front of the retry has been 100% successful for
> me so far, though I'd guess that's just timing luck. It certainly has
> the feel of a race.
I am a little surprised, I would expect a race to be much more widely
seen, but I did find this
http://www.cvsnt.org/pipermail/cvsnt/2003-February/005151.html
"Basically, when you call CloseHandle, it doesn't actually close the
handle, it just asks to OS nicely to do it when it gets around to it.
This can randomly cause the MoveFileEx that happens about 100th of a
second later to fail with a locked file."
I don't know enough about Windows to be able to say if the explanation
is correct, but the symptoms sound the same.
Now when Subversion calls svn_io_file_rename it always expects the
rename to succeed, perhaps we should use that knowledge and change
svn_io_file_rename to something like
status = apr_file_rename (...);
#ifdef SVN_WIN32
if (status is "Access is denied")
{
status = apr_file_rename (...); // immediate retry
if (status is "Access is denied")
{
apr_sleep (...); // or some sort of Windows flush or magic
SVN_ERR (apr_file_rename (...));
}
}
#endif
We can't really do that in APR since it is, in general, perfectly
acceptable for apr_file_rename to fail with a permissions problem.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Simply retrying the MoveFileEx seems to work fine most of the
time...once in a while it requires multiple retries to get through,
though. A Sleep(1) in front of the retry has been 100% successful for
me so far, though I'd guess that's just timing luck. It certainly has
the feel of a race.
Also, I can only recreate this problem on my hyperthreaded cpu box...it
just doesn't happen if I disable a cpu or if I'm on a single cpu box. I
can even turn on the AV realtime scanning and it doesn't happen. Is
anyone having this problem on a single cpu system?
DJ
D.J. Heap wrote:
> I will also test retrying MoveFileEx. As for MS developer support, they
> are pretty good if you can give them a small reproduction test program
> or recipe...that's what I was originally trying to do but couldn't
> outside of Subversion. I'm not sure how they would respond to
> Subversion and stress.pl as the recipe...they might look at it, but I'm
> not sure. Even if they did and found a problem, though, it could easily
> be months or years or never before they actually fix it.
>
> DJ
>
> -----Original Message-----
> From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
> Sent: Tuesday, May 20, 2003 4:02 PM
> To: dev@subversion.tigris.org
> Subject: Re: svn.collab.net is now running Subversion 0.23.
>
>
> "D.J. Heap" <dj...@dhiprovo.com> writes:
>
>
>>Back when I was looking at this problem a while ago, I could relieve
>>the problem (or it seemed to) by changing the apr_file_rename to use
>>the non-unicode-os code. That is, do the Delete and MoveFile rather
>>than MoveFileEx. I will try it later tonight or tomorrow when I
>>have some time.
>
>
> That could be OK as a test but as a long term solution it looks a bit
> dodgy--what happens if the MoveFile fails, or if the process is killed
> between Delete and MoveFile, does the destination disappear?
> Subversion relies on an Atomic rename, if you delete the destination
> and then fail to complete the rename the working copy is likely to be
> broken. I wonder if simply trying MoveFileEx again would do the
> trick?
>
> Has anyone asked Microsoft about this? I've been told their developer
> support is pretty good, although I have never used it myself.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
I will also test retrying MoveFileEx. As for MS developer support, they
are pretty good if you can give them a small reproduction test program
or recipe...that's what I was originally trying to do but couldn't
outside of Subversion. I'm not sure how they would respond to
Subversion and stress.pl as the recipe...they might look at it, but I'm
not sure. Even if they did and found a problem, though, it could easily
be months or years or never before they actually fix it.
DJ
-----Original Message-----
From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
Sent: Tuesday, May 20, 2003 4:02 PM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
"D.J. Heap" <dj...@dhiprovo.com> writes:
> Back when I was looking at this problem a while ago, I could relieve
> the problem (or it seemed to) by changing the apr_file_rename to use
> the non-unicode-os code. That is, do the Delete and MoveFile rather
> than MoveFileEx. I will try it later tonight or tomorrow when I
> have some time.
That could be OK as a test but as a long term solution it looks a bit
dodgy--what happens if the MoveFile fails, or if the process is killed
between Delete and MoveFile, does the destination disappear?
Subversion relies on an Atomic rename, if you delete the destination
and then fail to complete the rename the working copy is likely to be
broken. I wonder if simply trying MoveFileEx again would do the
trick?
Has anyone asked Microsoft about this? I've been told their developer
support is pretty good, although I have never used it myself.
--
Philip Martin
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
"D.J. Heap" <dj...@dhiprovo.com> writes:
> Back when I was looking at this problem a while ago, I could relieve
> the problem (or it seemed to) by changing the apr_file_rename to use
> the non-unicode-os code. That is, do the Delete and MoveFile rather
> than MoveFileEx. I will try it later tonight or tomorrow when I
> have some time.
That could be OK as a test but as a long term solution it looks a bit
dodgy--what happens if the MoveFile fails, or if the process is killed
between Delete and MoveFile, does the destination disappear?
Subversion relies on an Atomic rename, if you delete the destination
and then fail to complete the rename the working copy is likely to be
broken. I wonder if simply trying MoveFileEx again would do the
trick?
Has anyone asked Microsoft about this? I've been told their developer
support is pretty good, although I have never used it myself.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
Back when I was looking at this problem a while ago, I could relieve the problem (or it seemed to) by changing the apr_file_rename to use the non-unicode-os code. That is, do the Delete and MoveFile rather than MoveFileEx. I will try it later tonight or tomorrow when I have some time.
DJ
-----Original Message-----
From: Branko Èibej [mailto:brane@xbc.nu]
Sent: Tuesday, May 20, 2003 2:24 PM
To: Julian Reschke
Cc: D.J. Heap; 'Subversion Developers'
Subject: Re: svn.collab.net is now running Subversion 0.23.
Julian Reschke wrote:
>>From: D.J. Heap [mailto:djheap@dhiprovo.com]
>>Sent: Tuesday, May 20, 2003 6:59 PM
>>To: 'Branko Cibej'; 'Subversion Developers'
>>Subject: RE: svn.collab.net is now running Subversion 0.23.
>>
>>
>>After running stress.pl for a while this morning on Windows, I can
>>confirm that I still have the svn_io_rename_file problem (with no AV
>>scanning going on), although it is pretty rare, and can also confirm the
>>rather large degradation of performance when I switch to BDB 4.1.15 --
>>approximately 3-4x worse running local and through mod_dav_svn...it's
>>much much more noticeable under mod_dav_svn, of course.
>>
>>
>
>I'm not sure whether there's relation, but we are currently seeing a
>possibly related problem with Windows file system caching (in a totally
>different context). Our tests include:
>
>- creating a folder "a" containing a resource "b"
>- renaming "a" to "c"
>- looking up "a/b" (which is supposed to fail but doesn't always)
>
>and
>
>- creating a file "a"
>- changing the file's contents (with a different size)
>- checking the file length for "a" (which sometimes returns the old length)
>
>As far as I can tell, the following conditions add to the probability of
>failure:
>
>- the files being on a remote file system
>- the "local machine" (W2K) configured as "optimized as server" instead of
>"optimized for desktop operations" (not sure about how the UI calls that in
>english language systems.)
>
>Is this possibly "simply" a caching bug in Windows?
>
>
I suspect something like that, although in the svn_io_rename_file case,
it's on a local filesystem. All the symptoms point to a caching problem.
It's fairly weird, and a simple test case obviouisly won't uncover the
bug; but it's quite possible, given how horrendously difficult it is to
write even a simple Windows filesystem driver.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Julian Reschke wrote:
>>From: D.J. Heap [mailto:djheap@dhiprovo.com]
>>Sent: Tuesday, May 20, 2003 6:59 PM
>>To: 'Branko Cibej'; 'Subversion Developers'
>>Subject: RE: svn.collab.net is now running Subversion 0.23.
>>
>>
>>After running stress.pl for a while this morning on Windows, I can
>>confirm that I still have the svn_io_rename_file problem (with no AV
>>scanning going on), although it is pretty rare, and can also confirm the
>>rather large degradation of performance when I switch to BDB 4.1.15 --
>>approximately 3-4x worse running local and through mod_dav_svn...it's
>>much much more noticeable under mod_dav_svn, of course.
>>
>>
>
>I'm not sure whether there's relation, but we are currently seeing a
>possibly related problem with Windows file system caching (in a totally
>different context). Our tests include:
>
>- creating a folder "a" containing a resource "b"
>- renaming "a" to "c"
>- looking up "a/b" (which is supposed to fail but doesn't always)
>
>and
>
>- creating a file "a"
>- changing the file's contents (with a different size)
>- checking the file length for "a" (which sometimes returns the old length)
>
>As far as I can tell, the following conditions add to the probability of
>failure:
>
>- the files being on a remote file system
>- the "local machine" (W2K) configured as "optimized as server" instead of
>"optimized for desktop operations" (not sure about how the UI calls that in
>english language systems.)
>
>Is this possibly "simply" a caching bug in Windows?
>
>
I suspect something like that, although in the svn_io_rename_file case,
it's on a local filesystem. All the symptoms point to a caching problem.
It's fairly weird, and a simple test case obviouisly won't uncover the
bug; but it's quite possible, given how horrendously difficult it is to
write even a simple Windows filesystem driver.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by Julian Reschke <ju...@gmx.de>.
> From: D.J. Heap [mailto:djheap@dhiprovo.com]
> Sent: Tuesday, May 20, 2003 6:59 PM
> To: 'Branko Cibej'; 'Subversion Developers'
> Subject: RE: svn.collab.net is now running Subversion 0.23.
>
>
> After running stress.pl for a while this morning on Windows, I can
> confirm that I still have the svn_io_rename_file problem (with no AV
> scanning going on), although it is pretty rare, and can also confirm the
> rather large degradation of performance when I switch to BDB 4.1.15 --
> approximately 3-4x worse running local and through mod_dav_svn...it's
> much much more noticeable under mod_dav_svn, of course.
I'm not sure whether there's relation, but we are currently seeing a
possibly related problem with Windows file system caching (in a totally
different context). Our tests include:
- creating a folder "a" containing a resource "b"
- renaming "a" to "c"
- looking up "a/b" (which is supposed to fail but doesn't always)
and
- creating a file "a"
- changing the file's contents (with a different size)
- checking the file length for "a" (which sometimes returns the old length)
As far as I can tell, the following conditions add to the probability of
failure:
- the files being on a remote file system
- the "local machine" (W2K) configured as "optimized as server" instead of
"optimized for desktop operations" (not sure about how the UI calls that in
english language systems.)
Is this possibly "simply" a caching bug in Windows?
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn.collab.net is now running Subversion 0.23.
Posted by "D.J. Heap" <dj...@dhiprovo.com>.
After running stress.pl for a while this morning on Windows, I can
confirm that I still have the svn_io_rename_file problem (with no AV
scanning going on), although it is pretty rare, and can also confirm the
rather large degradation of performance when I switch to BDB 4.1.15 --
approximately 3-4x worse running local and through mod_dav_svn...it's
much much more noticeable under mod_dav_svn, of course.
DJ
-----Original Message-----
From: Branko Cibej [mailto:brane@xbc.nu]
Sent: Tuesday, May 20, 2003 10:48 AM
To: Subversion Developers
Cc: kfogel@collab.net; cmpilato@collab.net
Subject: Re: svn.collab.net is now running Subversion 0.23.
Branko Čibej wrote:
>kfogel@collab.net wrote:
>
>
>
>>cmpilato@collab.net writes:
>>
>>
>>
>>
>>>subject sez all.
>>>
>>>
>>>
>>>
>>In one week, let's upgrade to Berkeley 4.1.25, what say?
>>
>>
>>
>
>-1
>
>Just upgrading BDB, after the fiasco that caused last time, is not a
>good idea.
>
>Instead, let's start serious stress (and performance) tests of BDB
>4.1.x. I can try to do the Windows bit, if somebody can explain how to
>change stress.pl to not use fork.
>
>
Well, apart from the svn_io_rename_file problem, and the deadlock buglet
-- both of which show up with 4.0.14 -- BDB 4.2.15 works after a fashion
on Windows. It is also about 3x slower than 4.0.14, and getting slower
all the time. I have no idea at all what's going on; I'm on a RAM disk,
and the CPU usage is 1/3 of what it was with 4.0.14, so it can't be
increased I/O. There must be some really, really stupid blocking in BDB,
or we're using it wrong.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>kfogel@collab.net wrote:
>
>
>
>>cmpilato@collab.net writes:
>>
>>
>>
>>
>>>subject sez all.
>>>
>>>
>>>
>>>
>>In one week, let's upgrade to Berkeley 4.1.25, what say?
>>
>>
>>
>
>-1
>
>Just upgrading BDB, after the fiasco that caused last time, is not a
>good idea.
>
>Instead, let's start serious stress (and performance) tests of BDB
>4.1.x. I can try to do the Windows bit, if somebody can explain how to
>change stress.pl to not use fork.
>
>
Well, apart from the svn_io_rename_file problem, and the deadlock buglet
-- both of which show up with 4.0.14 -- BDB 4.2.15 works after a fashion
on Windows. It is also about 3x slower than 4.0.14, and getting slower
all the time. I have no idea at all what's going on; I'm on a RAM disk,
and the CPU usage is 1/3 of what it was with 4.0.14, so it can't be
increased I/O. There must be some really, really stupid blocking in BDB,
or we're using it wrong.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Blair Zajac <bl...@orcaware.com>.
cmpilato@collab.net wrote:
>
> cmpilato@collab.net writes:
>
> > =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> >
> > > >In one week, let's upgrade to Berkeley 4.1.25, what say?
> > > >
> > >
> > > -1
> > >
> > > Just upgrading BDB, after the fiasco that caused last time, is not a
> > > good idea.
> >
> > Yes yes yes. I've been using 4.1.25 on my laptop for a few weeks now,
> > with an outstanding TODO of banging it with stress.pl. While we
> > *think* the problems we had with svn.collab.net weren't related to
> > BDB, it costs too much to be wrong about such things.
>
> Yuck. I just ran 4 instances of stress.pl. At about revision 125,
> two of them pooped out with conflicted commits. I started two more to
> replace them and went back to what I was working on. Now, at revision
> 361, I have two more failed instances (conflicts again), but also two
> that are hung.
>
> This significantly reduces the chances of my smiling for the next few
> moments.
>
> .
> .
> .
> .
>
> Okay. I'm over it now.
>
> But there is at least something to be examined here.
Yes, I think having one of the core svn developers look at this would
make myself and other BDB 4.1.25 users very happy :)
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
>
> > >In one week, let's upgrade to Berkeley 4.1.25, what say?
> > >
> >
> > -1
> >
> > Just upgrading BDB, after the fiasco that caused last time, is not a
> > good idea.
>
> Yes yes yes. I've been using 4.1.25 on my laptop for a few weeks now,
> with an outstanding TODO of banging it with stress.pl. While we
> *think* the problems we had with svn.collab.net weren't related to
> BDB, it costs too much to be wrong about such things.
Yuck. I just ran 4 instances of stress.pl. At about revision 125,
two of them pooped out with conflicted commits. I started two more to
replace them and went back to what I was working on. Now, at revision
361, I have two more failed instances (conflicts again), but also two
that are hung.
This significantly reduces the chances of my smiling for the next few
moments.
.
.
.
.
Okay. I'm over it now.
But there is at least something to be examined here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> >In one week, let's upgrade to Berkeley 4.1.25, what say?
> >
>
> -1
>
> Just upgrading BDB, after the fiasco that caused last time, is not a
> good idea.
Yes yes yes. I've been using 4.1.25 on my laptop for a few weeks now,
with an outstanding TODO of banging it with stress.pl. While we
*think* the problems we had with svn.collab.net weren't related to
BDB, it costs too much to be wrong about such things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Barrie Slaymaker <ba...@slaysys.com>.
On Mon, May 19, 2003 at 01:01:29PM -0700, Blair Zajac wrote:
> Philip Martin wrote:
> >
> > Branko ??ibej <br...@xbc.nu> writes:
> >
> > > Instead, let's start serious stress (and performance) tests of BDB
> > > 4.1.x. I can try to do the Windows bit, if somebody can explain how to
> > > change stress.pl to not use fork.
> >
> > Does Perl on Windows have IPC::Open3? If so, then how about
>
> I don't know about IPC::Open3, but the file says it's been ported
> to Win32.
>
> Another possibility is to use IPC::Run to handle this kind of stuff
> and more complicated redirections, pipes, etc on Windows. I've had
> good luck with this package.
See also IPC::Run3 if all you want is system() with a few redirects; its
run3() is smaller, more portable (I hope!) and faster, especially on
Win32.
That said, I've only tested it on WinNT, will be testing it more on XP
coming up.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Blair Zajac <bl...@orcaware.com>.
Philip Martin wrote:
>
> Branko Äibej <br...@xbc.nu> writes:
>
> > Instead, let's start serious stress (and performance) tests of BDB
> > 4.1.x. I can try to do the Windows bit, if somebody can explain how to
> > change stress.pl to not use fork.
>
> Does Perl on Windows have IPC::Open3? If so, then how about
I don't know about IPC::Open3, but the file says it's been ported
to Win32.
Another possibility is to use IPC::Run to handle this kind of stuff
and more complicated redirections, pipes, etc on Windows. I've had
good luck with this package.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Committing:
> Status:
> svn: Item already exists in filesystem
> svn: successor id `0.0.v4' (for `0.0.uv') already exists in filesystem 'r://repostress/db'
> svn: Berkeley DB deadlock error
> svn: Berkeley DB error while reading node revision for filesystem r://repostress/db:
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
> svn st -u wcstress.3768: failed: 256
A known problem (that is, we know of the problem, we don't know the
cause)
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=245179
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
>>
>>
>
>A long while back, I came up with an idea that I think might help this out
>quite a bit. I suggested the notion of an "operation count" that is stored
>in each trail object. Every time we hit BDB, we do that within the context
>of a trail. If we simply increment an opcount for each operation, and then
>discover that certain things would create an opcount of 5000, then we know
>we've got some investigation.
>
>The fewer BDB operations per trail, then the smaller the locks. Generally.
>It is at least a start to find the problematic areas.
>
>Does that seem reasonable? Or am I missing something, and this wouldn't
>actually help much?
>
>
I'm very much in favor of statistics and logging features. I mention
adding a logging feature in my "still to be released" document. Man I
sound like a broken record. I'm *way* sorry about the delay.
Currently, with little effort at all, print_fs_stats or a "locking only
version" of it could be called upon entry and exit of suspect methods.
As an aside: making transactions smaller only helps when they are
artificially large. IOW, if making transactions smaller merely pushes
more conflict responsibility to us, we get nowhere. Access patterns
have to be understood to make real progress. Explicit locking
mechanisms, predictable access patterns, and schema changes will yield
the biggest wins IMO.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, May 20, 2003 at 04:32:58PM +0200, brane@xbc.nu wrote:
> Quoting "Glenn A. Thompson" <gt...@cdr.net>:
>
> > Hey,
> >
> > >Yes. The granularity of our transactions is far, far too large, and we
> > >have absolutely no control over locking order. I'm 99% certain that's
> > >where the deadlock comes from -- we simply don't access the various BDB
> > >tables in a well-known order, and we keep stuff locked longer than
> > >necessary.
> > >
> > >
> > Are there any methods in particular that rise to the top of a potential
> > hit list?
>
> Once upon a time I started analysing that code, and failed miserably. :-( Trails
> start so high up in the API that it's practically impossible to refactor things
> without turning the API upside down. Which, I understand, is what _you_'re
> doing. So there's hope after all. :-)
A long while back, I came up with an idea that I think might help this out
quite a bit. I suggested the notion of an "operation count" that is stored
in each trail object. Every time we hit BDB, we do that within the context
of a trail. If we simply increment an opcount for each operation, and then
discover that certain things would create an opcount of 5000, then we know
we've got some investigation.
The fewer BDB operations per trail, then the smaller the locks. Generally.
It is at least a start to find the problematic areas.
Does that seem reasonable? Or am I missing something, and this wouldn't
actually help much?
There's an issue opened on this, but I think it might be marked as post-1.0.
Of course, that simply means "we'll do it later, but if somebody is
motivated, then supply a patch and we'll do it now".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
>Once upon a time I started analyzing that code, and failed miserably. :-( Trails
>start so high up in the API that it's practically impossible to refactor things
>without turning the API upside down. Which, I understand, is what _you_'re
>doing. So there's hope after all. :-)
>
Well I don't know about upside down. Mostly, I want to make sure that
we can tweak and share without hosing and crashing:-)
*Then* we can turn it upside down ;-)
Frankly, I've lost count of the number of times that my brain has turned
to mush while trying to weigh concurency against consistency with
respect to the Subversion FS:-)
BTW I think this paper is worth reading. It does lose me in places.
It's good brain food though.
http://www.cs.duke.edu/~junyang/cps216/papers/berenson-etal-1995.pdf
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by br...@xbc.nu.
Quoting "Glenn A. Thompson" <gt...@cdr.net>:
> Hey,
>
> >Yes. The granularity of our transactions is far, far too large, and we
> >have absolutely no control over locking order. I'm 99% certain that's
> >where the deadlock comes from -- we simply don't access the various BDB
> >tables in a well-known order, and we keep stuff locked longer than
> >necessary.
> >
> >
> Are there any methods in particular that rise to the top of a potential
> hit list?
Once upon a time I started analysing that code, and failed miserably. :-( Trails
start so high up in the API that it's practically impossible to refactor things
without turning the API upside down. Which, I understand, is what _you_'re
doing. So there's hope after all. :-)
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
>Yes. The granularity of our transactions is far, far too large, and we
>have absolutely no control over locking order. I'm 99% certain that's
>where the deadlock comes from -- we simply don't access the various BDB
>tables in a well-known order, and we keep stuff locked longer than
>necessary.
>
>
Are there any methods in particular that rise to the top of a potential
hit list?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>So, I'm remember how we print error messages, it looks like the
>deadlock happens first, and *then* the "already exists" is tacked onto
>it.
>
> err = svn_fs__bdb_get_node_revision (NULL, fs, new_id, trail);
> if ((! err) || (err->apr_err != SVN_ERR_FS_ID_NOT_FOUND))
> {
> svn_string_t *id_str = svn_fs_unparse_id (id, trail->pool);
> svn_string_t *new_id_str = svn_fs_unparse_id (new_id, trail->pool);
> return svn_error_createf
> (SVN_ERR_FS_ALREADY_EXISTS, err,
> "successor id `%s' (for `%s') already exists in filesystem '%s'",
> new_id_str->data, id_str->data, fs->path);
> }
>
>Ah. So, our error message isn't really all that helpful, since any
>error except "not found" (include "deadlock error") will make it
>appear that there is, to use TuttSpeak :-), a NodeRev PK conflict. I
>remain confident that our filesystem code isn't generating clashing
>node-rev-ids.
>
Right, I was pretty certain of that myself.
>Still, the deadlock concerns me.
>
>
Yes. The granularity of our transactions is far, far too large, and we
have absolutely no control over locking order. I'm 99% certain that's
where the deadlock comes from -- we simply don't access the various BDB
tables in a well-known order, and we keep stuff locked longer than
necessary.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
William Uther wrote:
>
> On Tuesday, May 20, 2003, at 02:40 PM, cmpilato@collab.net wrote:
>
>> =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
>>
>>> Branko ÄŒibej wrote:
>>>
>>>> I now have stress.pl running on Windows
>>>
>
>>> svn: Berkeley DB deadlock error
>>> svn: Berkeley DB error while reading node revision for filesystem
>>> r://repostress/db:
>>> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
>>> svn st -u wcstress.3768: failed: 256
>>
>>
>> So, I'm remember how we print error messages, it looks like the
>> deadlock happens first, and *then* the "already exists" is tacked onto
>> it.
>
>
> [snip part about "already exists" being bogus]
>
>> Still, the deadlock concerns me.
>
>
> Deadlocks are to be expected, I think. You either:
>
> i) Avoid deadlock by using one big lock. This is inefficient.
> ii) Avoid deadlock by making sure you always acquire locks in the same
> order, and release them in reverse order. This might be possible if
> you made sure that paths were accessed in sorted order. I don't
> really know how this works with the subversion schema and BDB
> transactions though. I think the lazy copies make this impossible.
You could be right about that.
> iii) Don't avoid deadlock, but deal with it seamlessly. When you get
> a deadlock, one of the deadlocked transactions is aborted. You should
> be able to redo the command though, and I would have thought that svn
> should do this automatically. When restarted, the command should
> succeed (the other transaction in the deadlock should have
> completed). One detail is that when you restart a commit you may find
> you are no longer up to date and so abort for that reason.
We actually do have code in trail that retries a transaction in case of
a deadlock. I suspect the deadlock error code is being wrapped
somewhere, so this could be a simple coding bug. I can consistently
reproduce this error message on both Windows and Linux with BDB 4.0.14,
if I get three stress.pl instances running in parallel.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by William Uther <wi...@cse.unsw.edu.au>.
On Tuesday, May 20, 2003, at 02:40 PM, cmpilato@collab.net wrote:
> =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
>
>> Branko Äibej wrote:
>>
>>> I now have stress.pl running on Windows
>> svn: Berkeley DB deadlock error
>> svn: Berkeley DB error while reading node revision for filesystem
>> r://repostress/db:
>> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
>> svn st -u wcstress.3768: failed: 256
>
> So, I'm remember how we print error messages, it looks like the
> deadlock happens first, and *then* the "already exists" is tacked onto
> it.
[snip part about "already exists" being bogus]
> Still, the deadlock concerns me.
Deadlocks are to be expected, I think. You either:
i) Avoid deadlock by using one big lock. This is inefficient.
ii) Avoid deadlock by making sure you always acquire locks in the same
order, and release them in reverse order. This might be possible if
you made sure that paths were accessed in sorted order. I don't really
know how this works with the subversion schema and BDB transactions
though. I think the lazy copies make this impossible.
iii) Don't avoid deadlock, but deal with it seamlessly. When you get a
deadlock, one of the deadlocked transactions is aborted. You should be
able to redo the command though, and I would have thought that svn
should do this automatically. When restarted, the command should
succeed (the other transaction in the deadlock should have completed).
One detail is that when you restart a commit you may find you are no
longer up to date and so abort for that reason.
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> Branko Čibej wrote:
>
> >I now have stress.pl running on Windows
> >
> ...
>
> >Looks fine for now, so I'll let it run overnight.
> >
> >
>
> Oops.
>
> Updating:
> U wcstress.3768\trunk\foo1
> U wcstress.3768\trunk\foo2
> G wcstress.3768\trunk\bar1\foo1
> G wcstress.3768\trunk\bar1\foo2
> G wcstress.3768\trunk\bar2\foo1
> G wcstress.3768\trunk\bar2\foo2
> Updated to revision 369.
> Committing:
> Status:
> svn: Item already exists in filesystem
> svn: successor id `0.0.v4' (for `0.0.uv') already exists in filesystem 'r://repostress/db'
> svn: Berkeley DB deadlock error
> svn: Berkeley DB error while reading node revision for filesystem r://repostress/db:
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
> svn st -u wcstress.3768: failed: 256
So, I'm remember how we print error messages, it looks like the
deadlock happens first, and *then* the "already exists" is tacked onto
it.
err = svn_fs__bdb_get_node_revision (NULL, fs, new_id, trail);
if ((! err) || (err->apr_err != SVN_ERR_FS_ID_NOT_FOUND))
{
svn_string_t *id_str = svn_fs_unparse_id (id, trail->pool);
svn_string_t *new_id_str = svn_fs_unparse_id (new_id, trail->pool);
return svn_error_createf
(SVN_ERR_FS_ALREADY_EXISTS, err,
"successor id `%s' (for `%s') already exists in filesystem '%s'",
new_id_str->data, id_str->data, fs->path);
}
Ah. So, our error message isn't really all that helpful, since any
error except "not found" (include "deadlock error") will make it
appear that there is, to use TuttSpeak :-), a NodeRev PK conflict. I
remain confident that our filesystem code isn't generating clashing
node-rev-ids.
Still, the deadlock concerns me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>I now have stress.pl running on Windows
>
...
>Looks fine for now, so I'll let it run overnight.
>
>
Oops.
Updating:
U wcstress.3768\trunk\foo1
U wcstress.3768\trunk\foo2
G wcstress.3768\trunk\bar1\foo1
G wcstress.3768\trunk\bar1\foo2
G wcstress.3768\trunk\bar2\foo1
G wcstress.3768\trunk\bar2\foo2
Updated to revision 369.
Committing:
Status:
svn: Item already exists in filesystem
svn: successor id `0.0.v4' (for `0.0.uv') already exists in filesystem 'r://repostress/db'
svn: Berkeley DB deadlock error
svn: Berkeley DB error while reading node revision for filesystem r://repostress/db:
DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
svn st -u wcstress.3768: failed: 256
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>>Perhaps there is a filesystem race somewhere?
>>>
>>>
>>>
>>I think this must be it. When I examine those paths, the first exists
>>(and is writable/deletable), and the second doesn't, and I can do the move.
>>
>>
>
>If you want to try stress.pl on a filesystem other than a RAM one you
>might want to use the -W flag (used with -c) to get --bdb-txn-nosync.
>
>
Thanks, I saw that option. But it's NTFS on a ramdisk, not a special
RAM-based filesystem; no difference there.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> >Perhaps there is a filesystem race somewhere?
> >
> I think this must be it. When I examine those paths, the first exists
> (and is writable/deletable), and the second doesn't, and I can do the move.
If you want to try stress.pl on a filesystem other than a RAM one you
might want to use the -W flag (used with -c) to get --bdb-txn-nosync.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>Here's another beauty. I thought that had been fixed?
>>
>>Updating:
>>U wcstress.2708\trunk\bar1\foo1
>>G wcstress.2708\trunk\bar1\foo2
>>G wcstress.2708\trunk\foo2
>>G wcstress.2708\trunk\bar2\foo2
>>Updated to revision 741.
>>Committing:
>>svn: A problem occurred; see later errors for details
>>svn: Commit succeeded, but other errors follow:
>>svn: Access is denied.
>>svn: Error bumping revisions post-commit (details follow):
>>svn: svn_io_file_rename: can't move 'r:/wcstress.2708/trunk/bar2/.svn/tmp/entries' to 'r:/wcstress.2708/trunk/bar2/.svn/entries'
>>
>>
>
>Does this fail because of permissions, or because the destination
>already exists, or what?
>
>It's very odd, all the commits by stress.pl are more or less the same,
>and there doesn't appear to be anything pathological about the
>filenames in this commit. For a failure like this I would expect
>nearly every commit to be affected. Perhaps there is a filesystem
>race somewhere?
>
I think this must be it. When I examine those paths, the first exists
(and is writable/deletable), and the second doesn't, and I can do the move.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Here's another beauty. I thought that had been fixed?
>
> Updating:
> U wcstress.2708\trunk\bar1\foo1
> G wcstress.2708\trunk\bar1\foo2
> G wcstress.2708\trunk\foo2
> G wcstress.2708\trunk\bar2\foo2
> Updated to revision 741.
> Committing:
> svn: A problem occurred; see later errors for details
> svn: Commit succeeded, but other errors follow:
> svn: Access is denied.
> svn: Error bumping revisions post-commit (details follow):
> svn: svn_io_file_rename: can't move 'r:/wcstress.2708/trunk/bar2/.svn/tmp/entries' to 'r:/wcstress.2708/trunk/bar2/.svn/entries'
Does this fail because of permissions, or because the destination
already exists, or what?
It's very odd, all the commits by stress.pl are more or less the same,
and there doesn't appear to be anything pathological about the
filenames in this commit. For a failure like this I would expect
nearly every commit to be affected. Perhaps there is a filesystem
race somewhere?
Did the previous commit by this instance of the script succeed or
fail? If it failed, did that leave the working copy in a state that
caused the above failure? If you run a single instance of stress.pl
(use -n to increase the number of commits) then there should be no
conflicting commits and so every commit should succeed, does the
problem still occur?
> Sending wcstress.2708\trunk\bar1\foo2
> Sending wcstress.2708\trunk\bar2\foo1
> Sending wcstress.2708\trunk\bar2\foo2
> Sending wcstress.2708\trunk\foo2
> unexpected commit fail: exit status: 256
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Here's another beauty. I thought that had been fixed?
Updating:
U wcstress.2708\trunk\bar1\foo1
G wcstress.2708\trunk\bar1\foo2
G wcstress.2708\trunk\foo2
G wcstress.2708\trunk\bar2\foo2
Updated to revision 741.
Committing:
svn: A problem occurred; see later errors for details
svn: Commit succeeded, but other errors follow:
svn: Access is denied.
svn: Error bumping revisions post-commit (details follow):
svn: svn_io_file_rename: can't move 'r:/wcstress.2708/trunk/bar2/.svn/tmp/entries' to 'r:/wcstress.2708/trunk/bar2/.svn/entries'
Sending wcstress.2708\trunk\bar1\foo2
Sending wcstress.2708\trunk\bar2\foo1
Sending wcstress.2708\trunk\bar2\foo2
Sending wcstress.2708\trunk\foo2
unexpected commit fail: exit status: 256
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>Instead, let's start serious stress (and performance) tests of BDB
>>4.1.x. I can try to do the Windows bit, if somebody can explain how to
>>change stress.pl to not use fork.
>>
>>
>
>Does Perl on Windows have IPC::Open3? If so, then how about
>
>Index: tools/dev/stress.pl
>===================================================================
>--- tools/dev/stress.pl (revision 5978)
>+++ tools/dev/stress.pl (working copy)
>
[etc]
Wow, thanks, Philip! After a few more tweaks, I now have stress.pl
running on Windows (3 parallel sessions on a dual-CPU box -- on a
ramdisk, no less -- plus one to clean up the BDB log files every 5
seconds). Looks fine for now, so I'll let it run overnight.
BTW, this is with the 0.23.0 binaries, still with BDB 4.0.14.
I'll be committing the changes soon.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Instead, let's start serious stress (and performance) tests of BDB
> 4.1.x. I can try to do the Windows bit, if somebody can explain how to
> change stress.pl to not use fork.
Does Perl on Windows have IPC::Open3? If so, then how about
Index: tools/dev/stress.pl
===================================================================
--- tools/dev/stress.pl (revision 5978)
+++ tools/dev/stress.pl (working copy)
@@ -76,6 +76,7 @@
# can be quite hypnotic!
+use IPC::Open3;
use Getopt::Std;
use File::Find;
use File::Path;
@@ -144,18 +145,11 @@
# while other errors are not. Thus there is a need to check the
# return value and parse the error text.
- pipe COMMIT_ERR_READ, COMMIT_ERR_WRITE or die "pipe: $!\n";
- my $pid = fork();
- die "fork failed: $!\n" if not defined $pid;
- if ( not $pid )
- {
- # This is the child process
- open( STDERR, ">&COMMIT_ERR_WRITE" ) or die "redirect failed: $!\n";
- exec $svn_cmd or die "exec $svn_cmd failed: $!\n";
- }
+ my $pid = open3( \*COMMIT_WRITE, \*COMMIT_READ, \*COMMIT_ERR_READ,
+ $svn_cmd);
# This is the main parent process, look for acceptable errors
- close COMMIT_ERR_WRITE or die "close COMMIT_ERR_WRITE: $!\n";
+ close COMMIT_WRITE or die "close COMMIT_WRITE: $!\n";
my $acceptable_error = 0;
while ( <COMMIT_ERR_READ> )
{
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>cmpilato@collab.net writes:
>
>
>>subject sez all.
>>
>>
>
>In one week, let's upgrade to Berkeley 4.1.25, what say?
>
-1
Just upgrading BDB, after the fiasco that caused last time, is not a
good idea.
Instead, let's start serious stress (and performance) tests of BDB
4.1.x. I can try to do the Windows bit, if somebody can explain how to
change stress.pl to not use fork.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Blair Zajac <bl...@orcaware.com>.
kfogel@collab.net wrote:
>
> cmpilato@collab.net writes:
> > subject sez all.
>
> In one week, let's upgrade to Berkeley 4.1.25, what say?
>
> (One variable at a time.)
+1.
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by kf...@collab.net.
cmpilato@collab.net writes:
> subject sez all.
In one week, let's upgrade to Berkeley 4.1.25, what say?
(One variable at a time.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net is now running Subversion 0.23.
Posted by Greg Stein <gs...@lyra.org>.
On Mon, May 19, 2003 at 09:11:13AM -0500, cmpilato@collab.net wrote:
> subject sez all.
and I was finally able to switch that working copy off a deleted branch... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org