Re: Suggested new feature for ci

[Thien-Thi Nguyen]

() Keith Thompson <address@hidden>
() Thu, 11 Nov 2010 23:16:45 -0800

   Why?

Here is the text i added to rcs.texi:
--8<---------------cut here---------------start------------->8---
Note that @var{msg} is required; specifying an empty @var{msg}
results in a ``missing message for -m option'' error.
(If an empty log message were to be accepted, you would have to
run @command{rcsdiff} later just to figure out what changed for
a particular revision.)
--8<---------------cut here---------------end--------------->8---

But in case that isn't clear enough, i can give a gut-feeling answer:
rejecting an empty log message feels more anti-GIGO than allowing it.
Perhaps i have been conditioned too much to rely on ChangeLog files,
(which are thus copied into the log message in my usual editing flow)
for quickly recalling context of past changes.

Another consideration is how to go about arranging for the current
behavior should this change go forward.  That is, if i want an empty
log message to error, given a ci program that accepts empty log
messages, what must i do?  The answer would be to write a ci wrapping
script that parses "$@" (and/or RCSINIT) and recognizes the naked -m.

   For the record, I disagree.  Certainly descriptive log messages
   are usually a good thing, but there are a lot of times when I want
   to check something in without having to say anything about it.
   This is particularly true when ci is invoked automatically rather
   than manually.

   If there's no syntax for specifying an empty log message on the
   command line, I'll just continue using "ci ... < /dev/null", or maybe
   "ci -m. ...".

If ci is invoked automatically, say by cron job, you might try:

$ cat > /usr/local/bin/auto-ci <<EOF
#!/bin/sh
exec ci -m"checkin by $0" "$@"
EOF
$ chmod +x /usr/local/bin/auto-ci

   And then there's "cvs checkin -m ''".  Certainly RCS doesn't *have*
   to be completely compatible with CVS (and in many ways it can't be),
   but I don't think making (or rather keeping) RCS different in this
   particular way doesn't seem useful.

I'm not convinced of the usefulness of empty log messages, whether in
CVS or elsewhere.  I think both Git and Mercurial refuse, and suspect
others do, too.

On the other hand, consistency is important.  Perhaps to be more
internally consistent (and "consistent" with modern best practices),
non-interactive ci should be changed to refuse, just like interactive
ci.  (This could be phased in over a few releases, first as a warning.)

[a few hours later...]

Well, i've convinced myself that useful or not, it's no big deal to
default to "*** empty log message ***" for the non-interactive case,
to be consistent with the interactive case.  (See git repo.)  Thanks
for this opportunity to mull things out publically!

I think loss of the error mode is livable, but there is still time to
find another resolution, should this one be deemed too radical.