[cvsnt] timeout time for cvslockd file locks?
tony.hoyle at march-hare.com
Mon Dec 3 19:39:00 GMT 2007
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
More information about the cvsnt