Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
John Goehringer wrote: > Tony, > > I'm seeing poor performance on both the client and server > with build 69 compared to build 68 and tracked it down to > the FlushFileBuffers call in win32.c:wnt_fclose. > > Was this for AtomicCommits support? Perhaps > No, it's to work around a bug in NT. 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. On fast machines you won't notice it, but testing on a slow machine caused failure in a significant number of cases. Atomic commits make it worse, making the whole thing unusable even on the relatively fast machines I work with. I actually had to do a fair bit of mucking around with RCS to get it to close its files earlier to get anything to work at all with atomic commits enabled. Until I can work out how to get NT to actually close files when I tell it the final flush is a good safety measure... The speed seems to be comparable... nothing really noticeable on the size of repositories I've been using with it. Tony