James Turner wrote on Sun, Dec 17, 2006 at 12:13:07AM -0500: > On Sun, 17 Dec 2006, Ingo Schwarze wrote: >> James Turner wrote on Sat, Dec 16, 2006 at 11:28:43PM -0500:
>>> jcs@ suggested looking at loginfo in CVSROOT, but I haven't had much luck >>> there. I added "^webapp cd /var/www/webapp && cvs update -d" but there >>> seems to be a locking issue, I'm guessing cvs update tries to run before >>> the commit is finished, which it won't allow. >> >> Are you sure? `info cvs` says on page "C.3 The commit support files": >> >> :: `loginfo' >> :: The specified program is called when the commit is complete. > Below is the output of running cvs commit on my local repos. Thanks, that output was useful. Indeed, you are right. After the command `cvs commit`, cvs(1) does not remove the lock until the commands run from CVSROOT/loginfo return. I was misled by not reading the info page word by word: The specified program is indeed called when the commit is complete, but that does not imply that the lock has already been removed, as some testing just revealed to me. Thus, i suggest to try "^webapp (cd /var/www/webapp && cvs update -dP) &" in CVSROOT/loginfo. In my test scenario, a similar line produced output like this: [EMAIL PROTECTED] $ cvs commit cvs commit: Examining . Checking in testfile; /data/test-cvs/CVSROOT/testfile,v <-- testfile new revision: 1.2; previous revision: 1.1 done cvs commit: Rebuilding administrative file database cvs update: Updating . cvs update: [07:04:18] waiting for schwarze's lock in /data/test-cvs/CVSROOT [EMAIL PROTECTED] $ # half a minute later you will see: cvs update: [07:04:48] obtained lock in /data/test-cvs/CVSROOT U testfile The point is to make loginfo start the update in a subshell and put it into the background, then return such that cvs can remove the lock. Even if the first try of cvs update is still hindered by the lock, the asynchronous job will retry 30 seconds later, and eventually, the update will succeed. You might even consider to add some shorter sleep(1) between the cd and the cvs update in the subshell, if you like. But that is not even required. The -P flag in my suggestion has nothing to do with the locking issue, but pruning empty directories seems useful to me in most cases. > I should probably have noted this earlier, but I use cvs through ssh. That's fine. I don't think ssh will cause any additional trouble here. Good luck, Ingo
