Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Aug 1995 15:43:38 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        peter@haywire.dialix.com (Peter Wemm)
Cc:        bde@zeta.org.au, CVS-commiters@freefall.FreeBSD.org, cvs-sys@freefall.FreeBSD.org
Subject:   Re: cvsedit and the iron fist approach....
Message-ID:  <199508262243.PAA06504@gndrsh.aac.dev.com>
In-Reply-To: <Pine.SV4.3.91.950827051444.11438C-100000@haywire.DIALix.COM> from "Peter Wemm" at Aug 27, 95 05:27:46 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> On Sun, 27 Aug 1995, Bruce Evans wrote:
> > Date: Sun, 27 Aug 1995 06:55:21 +1000
> > From: Bruce Evans <bde@zeta.org.au>
> > To: CVS-commiters@freefall.FreeBSD.org, bde@freefall.FreeBSD.org,
> >     cvs-sys@freefall.FreeBSD.org
> > Subject: cvsinit doesn't ask about aborting for null log messages
> > 
> > I was annoyed when cvsinit didn't prompt for aborting for an empty
> > log message.  Perhaps it always has always done this, but our log
> > messages were previously rarely empty because the Submitted by:
> > (etc.) lines weren't stripped.
> > 
> > What does it do for an empty log message in the middle of a batch?
> > 
> > Bruce
> 
> 1,$s/cvsinit/cvsedit/g
> 
> Yeah, Satoshi commented about this too.
> 
> Since people are asking about it, it's obviously not desirable...
> 
> I propose the following change to cvsedit to "fix" it, since cvsedit 
> actually does the right thing on an empty file anyway.
> 
> When I wrote it, I put it in to make sure that I didn't miss any cases 
> when the filter may have totally removed all the log.  It's outlived it's 
> usefulness.
> 
> As for a mid-commit exit, it'll cause the same problem if you chose abort 
> under the old system...  Ie: log_accum will not get run to close off the 
> commit messages and send the mail, even though some commits have been 
> done.
> 
> log_accum has always had this problem right from day 1. 

:-(.  The more time that goes buy the more I am starting to hate all
this hackery in CVSROOT.  Perhaps it is time to step way way way back
and rething just how all this is done, and find a better way to do it.

Log_accum.pl is a hack, it has been hacked on seriously, and it still
has fundemental design flaws like this.

The biggest reason for using it was to reduce the mail created from
tree commits.  Perhaps we should move that into a totally external
thing from cvs, and allow cvs to do it's normal things with respect
to the log files and clean this up with a script run by sendmail.

> I've spoken with Rod about it before, and I've just had an idea 
> how to counter it...

Oh, I can see it now.. another .pl hack on the side of cvs :-(.

> 
> We could make a directory somewhere other than /tmp, and get log_accum to
> put it's checkpoint files there.  We can get a cron job to run over them
> every hour or so, and see if there are any abandoned, partially committed,
> unlogged messages left, and run log_accum.pl manually to close them
> off....  Otherwise we'll never see the commit mail for the commits that 
> were actually completed.

See above... I don't like this idea, this stuff has gotten out of hand,
is creating more problems than it solved.  We are finding bugs every 2 or
3 days, etc.  IMHO, it is time to punt and step back for a redesign.

> 
> -Peter
> 
> Index: cvsedit
> ===================================================================
> RCS file: /home/ncvs/CVSROOT/cvsedit,v
> retrieving revision 1.6
> diff -c -2 -r1.6 cvsedit
> *** 1.6	1995/08/23 11:42:34
> --- cvsedit	1995/08/26 21:14:06
> ***************
> *** 81,87 ****

Reviewed, approved, please commit as a stop gap fix.


-- 
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?199508262243.PAA06504>