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. Tony