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: 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