bug-rcs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggested new feature for ci


From: Keith Thompson
Subject: Re: Suggested new feature for ci
Date: Fri, 12 Nov 2010 08:57:32 -0800
User-agent: Mutt/1.5.19 (2009-01-05)

On Fri 10-11-12 15:42, Thien-Thi Nguyen wrote:
> () 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.

Consider this.  Sometimes when I check in a new version of a file,
the only thing I want to say about it is that this is what the file
looked like at the moment I checked it in.  Different people use RCS
in different ways, and I use it in different ways at different times.
Certainly if I've made some changes to a program source file,
I want to document those changes so I can see them in the log,
but that's not the only thing I use RCS for.

The current syntax makes it difficult to specify an empty log message,
but suppose you add the "rcs ci" feature.  Then, as we've discussed,
you're free to change the way options are parsed.  You might have

    rcs ci -m 'What I changed' filename
    rcs ci --message='What I changed' filename
    rcs ci --message 'What I changed' filename

(and "rcs checkin" might be an alias for "rcs ci").

With this syntax, you'd have to go out of your way to reject empty
messages:

    rcs ci -m '' filename
    rcs ci --message= filename
    rcs ci --message '' filename

And in any of these cases, I've made it explicit that I want an
empty message.  I'm specifying a string, and '' is as valid
a string as anything else.
 
(For the current version of RCS, if I don't want to say anything,
I'm thinking of using "-m." rather than "< /dev/null", just because
it's less typing.)

-- 
Keith Thompson (The_Other_Keith) address@hidden  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]