[cvsnt] Lock Retry Interval and Retry Count

Michael Wojcik Michael.Wojcik at microfocus.com
Tue Jul 18 19:27:57 BST 2006


> From: cvsnt-bounces at cvsnt.org 
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Tony Hoyle
> Sent: Tuesday, 18 July, 2006 12:43
> 
> Michael Wojcik wrote:
> > Even without that bug, though, I believe the current behavior is far
> > from optimal, and it should be configurable.
> 
> Ultimately those kinds of locks will probably go away anyway.

Sounds good, though it probably won't help me, considering how far
behind the current release our corporate servers are now...  At least I
can update my own personal CVSNT installation and enjoy the benefits
with my personal files, I suppose.

> That's 30 seconds per file.. the old cvshome setting was per
directory, so 
> it's actually considerably more generous...  You'd need to be storing
some 
> really big files for 30 seconds to be an issue - most files complete
in a 
> second or less.

In our case, it's the bogus-collision bug in very old versions of the
lockserver (they're still running 2.0.26 on the servers here) that's
causing the problem - locks in one part of the repository will produce
false locking conflicts for other parts of the repository.  Combine that
with an automatic commit-and-tag of the built binaries by our automated
build system, and we end up with a lot of unnecessary build failures.

But even without that bug, I can see a heavily-loaded server taking long
enough to get locking timeouts.  We have multiple build machines doing
parallel builds and committing the results, which often are quite large.

(Personally, I'm dubious about the wisdom of committing built binaries
to CVS.  Anything that goes out the door, perhaps, but every automated
build?  But it's not my decision.)

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus



More information about the cvsnt mailing list