Date: Sun, 1 Oct 1995 08:57:54 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> Cc: John Fieber <jfieber@indiana.edu>, CVS-commiters@freefall.freebsd.org, cvs-share@freefall.freebsd.org Subject: Re: cvs commit: src/share/examples/sup ports-supfile secure-stable-supfile secure-supfile stable-supfile standard-supfile Message-ID: <Pine.BSF.3.91.951001082507.397G-100000@jhome.DIALix.COM> In-Reply-To: <199509301849.LAA01926@GndRsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 30 Sep 1995, Rodney W. Grimes wrote: > > On Sat, 30 Sep 1995, John Fieber wrote: > > > > > jfieber 95/09/30 08:24:58 > > > > > > Added: share/examples/sup ports-supfile secure-stable-supfile > > > secure-supfile stable-supfile standard-supfile > > > Log: > > > Move supfile examples from share/FAQ/extras to share/examples/sup > > > > Um, the companion commit to this, the removal from share/FAQ/extras, > > apparently DID happen but I've recieved no commit message. I had started > > to commit two directories but decided to back out because I wanted to > > make another change first. I aborted after entering the second message. > > I guess the first commit (removal from share/FAQ/extras) took hold but > > didn't mail the a message. > > Your assement of what happened is correct. This is a rather serious bug > in log_accum.pl, with no simple fix. Peter Wemm has looked at it, and > tried to fix it, but it seems elusive. Not only did your commit mail > not get sent, it did not get appended to $CVSROOT/CVSROOT/commitlogs/*. > > The commit did occur, the only evidence of it will be in the rlog of the > effected files. And this mail thread on the mailling lists. Yep. This is in the "Sigh!!!" department.. Here's a couple of issues in my list with log_accum.pl.. 1: Partial commits are not logged or emailed. 2: multi-module commits go to the wrong lists/logs I know exactly what's wrong, but there's no simple fix, it's more an issue of a redesign. :-( The problem basically is that cvs executes the log script for each directory. If there is an email sent from each of these, then the volume of email for commits goes up (a fair bit, judging by the NetBSD commit lists). What log_accum.pl does, is half the story. First, commit_prep.pl creates an "intent" file, recording the last directory that was committed in. (commit_prep is run in each directory also.) When the commits happen, the log_accum script logs the information for the current directory in /tmp. It checks to see if it's got to the last directory yet (saved by commit_prep), and exits right there and then if not. If you abort now, you are screwed. :-( When it does get to the last directory, it collects all the saved data files, and assembles them into a single message. It sends them to the mailing list that is appropriate for the current (ie: last) commit. It uses the subject: line of the current (last) directory. One way of fixing it would be to split the log_accum.pl script into it's two logical halves - The gathering half and the reporting half.. Then, the gathering half only collects the data from cvs and records it in it's own format. The trick is how to get the reporting half to run. It can be done two ways.. One is to run it from cron every 5 minutes to see if there are any pending commits waiting to be reported on, and if so it does them. The other way is for the first half to launch the second half in the background. The background half detaches itself from the session, and polls the processid of the process group leader (in this case, "cvs"). The background half would sit in a loop, doing a "kill -0 $pgpid" and checking the error result (like uucp locking, ESRCH means the process is dead, and no error or EPERM means it's still there). When the parent cvs has finished (or quit, aborted, segfaulted or whatever), the background half fires up, processes whatever files are waiting, does the log and mail and then quits. That would work, but is a bit messy for my liking. I suspect it's probably the only way, with the exception of having a caretaker cron come along and clean up the mess left in /tmp from failed commits. If anybody has better ideas, I'd love to hear them.... (modifying cvs is probably out.. :-) I'm not planning on doing anything about it for a while, so there's no hurry. Cheers, -Peter > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Reliable computers for FreeBSD >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951001082507.397G-100000>