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.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Tony Hoyle > Sent: Sunday, 05 February, 2006 17:44 > > Alberto Di Fede wrote: > > > > To be more precise this behavior fails when two concurrent TAG are done > > on the same repository. At one point in the middle of the TAG the two > > operations try to tag the same file at the same time: as you wrote, the > > lock server try for 20 seconds then it returns a fail to one of the two > > operations while letting the other one finish. > > > tag itself won't lock an individual file for 20 seconds though... it's > not a situation that will normally arise, even if you try multiple tags > of the entire repository (which is itself fairly unusual). tag certainly *shouldn't* lock a file for 20 seconds. However, we're currently seeing a problem (intermittent, but reproducible) where tagging unrelated files in the same repository produces locking conflicts. We originally ran into this in our build system. For some components we're doing simultaneous builds on a Win32 build machine, an x64-Win64 build machine, and an IA64-Win64 build machine. After a successful build for a component, various files are copied to a save directory, committed, and tagged. Each platform has its own delivery directory, so the process looks roughly like this: DELIVERY_DIR=delivery-w32 # or delivery-x64, etc make cvs update -A $(DELIVERY_DIR) copy [various files] $(DELIVERY_DIR) cvs commit -m"..." $(DELIVERY_DIR) cvs tag ... $(DELIVERY_DIR) The tag commands frequently failed with locking conflicts between build machines, even though they were tagging different files (because DELIVERY_DIR is different for each system). With multiple machines tagging several files each, we often had CVS time out and give up. (I think we've seen some of these conflicts with the commit operations as well; unfortunately there's no way to tell what command the lock holder is running.) On occasion, developers have reported completely bogus lock conflicts signalled by CVS: developer A is tagging foo/bar, and CVS says it's waiting for developer B's lock on baz/biff. I set up my local CVS to run lockserver traffic through a logging TCP tunnel, and it appears that tag locks only the file it's currently tagging (as I'd expect), and a look at the lockserver code (for 2.0.51d) didn't show any obvious sources of false positives. Unfortunately I don't control the production CVS server that's giving us the trouble, or I could instrument lockserver and see what it's doing. At this point, I'm not sure there's any solution other than fixing the timeout mechanism on the client so that it waits for a decent (probably configurable) period before giving up. -- Michael Wojcik Principal Software Systems Developer, Micro Focus