[cvsnt] timeout time for cvslockd file locks?

Tony Hoyle tony.hoyle at march-hare.com
Mon Dec 3 19:39:00 GMT 2007

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.

Mark Johnson wrote:
> We are using one of those badly behaved autobuild systems
> (CruiseControl).  What has me confused is that the machine which holds
> the lock appears to be also tagging, not in the process of doing a
> "log".  Does a log operation lock?  Would a log operation (from
> another client machine) cause the tag to slow down so much that it
> might take 20+ seconds to complete a tag of a single file? Is there a
> good way for me to verify this? or to get information (in a controlled
> environment) on how long the locks are held during a tag?

Log uses a read lock, and you can't tag until it's finished (as do all 
operations, but processing a single revision is pretty fast especially 
when it's close to HEAD).

Log is the most resource heavy operation you can use - to generate its 
data it needs to parse every revision in the rcs file.  A full log is 
normally a comparitively rare operation, so it doesn't need to be fast.

I'd imagine Cruise Control is throwing the machine heavily into swap... 
that's one of the effects observed earlier - it would try to log the 
entire repository.. effectively recalculating every single revison of 
every single file in the repository and burying the server.  On occasion 
it would attempt to do this multiple times in parallel.

> We have not upgraded our cruisecontrol for a while, so I have no idea
> if this behavior has been changed.  Is there a better way to determine
> if a change has occurred, and what that change is?  I can add a
> post-commit operation to touch a file, indicating a change, but how
> would my build system know which file(s) have changed in any given
> automated build?

Use the checkout trigger to keep a working sandbox up to date, then run 
a batch build when required.  You know what is changed because of audit 
logs, commit ids, bug ids, etc.  Both the scripting and trigger 
interfaces have access to all the information available about a given 
commit (and it's all in the audit database for later consumption).. it's 
just a matter of how you want to use it.

You probably don't need to worry about the changes themselves - it's all 
in the audit database if you really want to break it down to that level 
later (and 'cvs diff' can allow an individual developer to find changes 
if required).  Just keeping the up to date sandbox and building it is 
probably enough.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook