*** empty log message *** is a no-no

*** empty log message *** is a no-no

[Steinar Bang]

Doing 
        C-x v l
on the files in the public CVS gives 
        *** empty log message ***
on most checkins (maybe all).

My experience with CVS (and RCS) tells me that this is a no-no.

The most important thing you get from these versioning systems is IMO
the human readable log of changes.  If you have access to the
commitlog you can search for keywords and find out when changes were
made. 

Re: *** empty log message *** is a no-no

[Denys Duchier]

Steinar Bang <sb@metis.no> writes:

> My experience with CVS (and RCS) tells me that this is a no-no.
> 
> The most important thing you get from these versioning systems is IMO
> the human readable log of changes.  If you have access to the
> commitlog you can search for keywords and find out when changes were
> made. 

I absolutely concur.  I was about to suggest the very same thing.
Personally, when I implement something new, I usually include full
documentation in the log message.  This way (1) others reading the
logs are well informed about what I have done, (2) when I get around
to writing actual documentation, I already have an outline of it in
the logs.  When fixing a tricky bug, it is also a good idea to
document your understanding of it.  My view is that the CVS logs serve
the dual purpose of keeping everyone informed about on-going progress
in the project as well as of being a persistent repository of useful
information/documentation.

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: *** empty log message *** is a no-no

[Lars Magne Ingebrigtsen]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> I absolutely concur.  I was about to suggest the very same thing.
> Personally, when I implement something new, I usually include full
> documentation in the log message.  This way (1) others reading the
> logs are well informed about what I have done, (2) when I get around
> to writing actual documentation, I already have an outline of it in
> the logs.  When fixing a tricky bug, it is also a good idea to
> document your understanding of it.  My view is that the CVS logs serve
> the dual purpose of keeping everyone informed about on-going progress
> in the project as well as of being a persistent repository of useful
> information/documentation.

The ChangeLogs are the log files for Gnus.  So if we could get the
ChangeLog generated from the CVS logs (or the other way around,
preferably), that would be neat.

(And I always write documentation while implementing new stuff.
(Well, almost always. :-)  It's an integrated part of programming for
me.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: *** empty log message *** is a no-no

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> The ChangeLogs are the log files for Gnus.  So if we could get the
> ChangeLog generated from the CVS logs

This should be possible to do with the 
        CVSROOT/loginfo
script.

> (or the other way around, preferably), that would be neat.

Do you check in many files at a time?  Then it should be possible to
create a wrapper script for "cvs ci" that picks out the latest entry
in the ChangeLog, and uses this as the log message for the checkin.

But I prefer the first solution.

Re: *** empty log message *** is a no-no

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The ChangeLogs are the log files for Gnus.  So if we could get the
> ChangeLog generated from the CVS logs (or the other way around,
> preferably), that would be neat.

I forget which way this was, but pcl-cvs can do one direction.  And
isn't there some C-x v a or something which also does something like
this?  Hm.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: *** empty log message *** is a no-no

[William M. Perry]

Steinar Bang <sb@metis.no> writes:

> >>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
> 
> > The ChangeLogs are the log files for Gnus.  So if we could get the
> > ChangeLog generated from the CVS logs
> 
> This should be possible to do with the 
>         CVSROOT/loginfo
> script.
> 
> > (or the other way around, preferably), that would be neat.
> 
> Do you check in many files at a time?  Then it should be possible to
> create a wrapper script for "cvs ci" that picks out the latest entry
> in the ChangeLog, and uses this as the log message for the checkin.
> 
> But I prefer the first solution.

You can also do:

(add-hook 'vc-checkin-hook 'vc-update-change-log)

Every time you check in a file from within emacs, it will update the change
log with your vc change notification as well.

-Bill P.

Re: *** empty log message *** is a no-no

[Steinar Bang]

>>>>> wmperry@aventail.com (William M. Perry):

> You can also do:

> (add-hook 'vc-checkin-hook 'vc-update-change-log)

> Every time you check in a file from within emacs, it will update the
> change log with your vc change notification as well.

Yup!  But using CVSROOT/loginfo will handle things on the server side, 
no matter the emacs setup of the person doing the checkin, or whether
it was done from the command line, rather than by
        C-x C-q
(it's easier to do it from the command line for a change that affects
more than one file)

Re: *** empty log message *** is a no-no

[David Kågedal]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > The ChangeLogs are the log files for Gnus.  So if we could get the
> > ChangeLog generated from the CVS logs (or the other way around,
> > preferably), that would be neat.
> 
> I forget which way this was, but pcl-cvs can do one direction.  And
> isn't there some C-x v a or something which also does something like
> this?  Hm.

If you press C in pcl-cvs, it looks in the ChangeLog and inserts some
entries in the checkin comment that it thinks might be related to what
you are checking in.  Very useful.

-- 
David Kågedal

Re: *** empty log message *** is a no-no

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

On Nov 12, 1999, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> The ChangeLogs are the log files for Gnus.  So if we could get the
> ChangeLog generated from the CVS logs (or the other way around,
> preferably), that would be neat.

If you don't mind using a script to commit your stuff, use this one:


[-- Attachment #2: clcommit --]
[-- Type: application/x-sh, Size: 6177 bytes --]

[-- Attachment #3: Type: text/plain, Size: 431 bytes --]


I've collected this and a few other useful CVS-related shell scripts
in cvs-utils, available at
http://www.ic.unicamp.br/~oliva/snapshots/cvs-utils/

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: *** empty log message *** is a no-no

[Lars Magne Ingebrigtsen]

Alexandre Oliva <oliva@lsd.ic.unicamp.br> writes:

> If you don't mind using a script to commit your stuff, use this one:

[...]

> # The commit message will be extracted from the differences between
> # the local ChangeLog and the one in the repository (unless a message
> # was specified with `-m' or `-F').

Thanks; this is just what I need, I think.  (*reads code*)  Hm, this
doesn't pick out the bits of the changed ChangeLog that applies to
different files if there's more than one file that's changed, does it?

This is how I work:

1a) I read a bunch of bug reports, and I fix a bunch of bugs in a bunch
    of files, noting everything in the ChangeLog.
1b) I fix a bunch more bugs.

2) I see that it doesn't compile, so I fix a bunch more.

3) I see that it compiles, so I start it.

4) I see that it didn't start, so I go back to 1b) a couple of times

5) I say "cvs commit -m ''", which is why you get all those empty
   log messages.

I don't really want to commit before after I've done 4).  So I either
want something that picks out the relevant bits from the ChangeLog
entries I've added in 1), or some other way of doing things so that
the ChangeLog will be generated in 5).

Shirley this can't be an unusual way of working?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: *** empty log message *** is a no-no

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Shirley this can't be an unusual way of working?

Nope.  I also dislike commiting before testing the whole system, and
uses ChangeLogs rather than commit logs for the projects I'm involved
in.  So the current Gnus setup fits me perfectly ;-)

Re: *** empty log message *** is a no-no

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Shirley this can't be an unusual way of working?

> Nope.  I also dislike commiting before testing the whole system, and
> uses ChangeLogs rather than commit logs for the projects I'm involved
> in.  So the current Gnus setup fits me perfectly ;-)

With "the current Gnus setup" you mean "empty log messages"...?

Re: *** empty log message *** is a no-no

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> >>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
> 
> > Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> >> Shirley this can't be an unusual way of working?
> 
> > Nope.  I also dislike commiting before testing the whole system, and
> > uses ChangeLogs rather than commit logs for the projects I'm involved
> > in.  So the current Gnus setup fits me perfectly ;-)
> 
> With "the current Gnus setup" you mean "empty log messages"...?

I mean where the content of log messages aren't important, the
significant place where everything should be stated is the ChangeLog.  

Re: *** empty log message *** is a no-no

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> I mean where the content of log messages aren't important,

For the record: I disagree deeply.

> the significant place where everything should be stated is the
> ChangeLog.

Re: *** empty log message *** is a no-no

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> >>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
> 
> > I mean where the content of log messages aren't important,
> > the significant place where everything should be stated is the
> > ChangeLog.

[ I don't want the above sentense being split.  Log messages are
important, but I find them most useful in the ChangeLog. ]

> For the record: I disagree deeply.

What is your Gnus work pattern that makes finding the relevant
information in the ChangeLog deeply disagreeable?

Re: *** empty log message *** is a no-no

[Alexandre Oliva]

On Nov 12, 1999, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Thanks; this is just what I need, I think.  (*reads code*)  Hm, this
> doesn't pick out the bits of the changed ChangeLog that applies to
> different files if there's more than one file that's changed, does it?

It picks all of the checked-out ChangeLog that's not in the committed
ChangeLog.  And it will warn you if there are blank lines in that
portion, because this means you're checking in multiple unrelated
changes as a single commit, which is not good practice if you happen
to have to hunt for a particular change in the CVS logs.  But the
script will commit it, anyway.

It might be better for the CVS logs and for whoever wants to extract a
single patch from the CVS tree to commit every time you make a change
and test it.

> So I either want something that picks out the relevant bits from the
> ChangeLog entries I've added in 1), or some other way of doing
> things so that the ChangeLog will be generated in 5).

I believe this script should do it.  If it doesn't, please let me
know, I may be able to tweak it to fit your needs.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: *** empty log message *** is a no-no

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> What is your Gnus work pattern that makes finding the relevant
> information in the ChangeLog deeply disagreeable?

        C-x v l
in a CVS versioned file, to quickly find out what the last changes
were about.

Re: *** empty log message *** is a no-no

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> >>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
> 
> > What is your Gnus work pattern that makes finding the relevant
> > information in the ChangeLog deeply disagreeable?
> 
>         C-x v l
> in a CVS versioned file, to quickly find out what the last changes
> were about.

Well, it ought to be possible to write a command that shows the last
ChangeLog entries for the current file...

Re: *** empty log message *** is a no-no

[Lars Magne Ingebrigtsen]

Alexandre Oliva <oliva@lsd.ic.unicamp.br> writes:

> It might be better for the CVS logs and for whoever wants to extract a
> single patch from the CVS tree to commit every time you make a change
> and test it.

I don't want to change the way I work; I just want to get better CVS
log entries.  :-)

So if there's a an entry in the ChangeLog that mentions file x.el, and 
x.el has changed, then I would like for something to extract the bits
from the ChangeLog that talks about x.el and use that as the commit
message for that file.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: *** empty log message *** is a no-no

[Lee Cantey]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I don't want to change the way I work; I just want to get better CVS
> log entries.  :-)
> 
> So if there's a an entry in the ChangeLog that mentions file x.el, and 
> x.el has changed, then I would like for something to extract the bits
> from the ChangeLog that talks about x.el and use that as the commit
> message for that file.

I might have missed a previous reference, but have you taken a look at
the excellent PCL-CVS frontend to CVS by Stefan Monnier?  It works
quite nicely and will lookup entries in the ChangeLog to provide
default comments.

Lee.

Re: *** empty log message *** is a no-no

[Lars Magne Ingebrigtsen]

Lee Cantey <lcantey@borland.com> writes:

> I might have missed a previous reference, but have you taken a look at
> the excellent PCL-CVS frontend to CVS by Stefan Monnier? 

<Mr. Burns>*Excellent*.</Mr. Burns>

Just what I was looking for.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: *** empty log message *** is a no-no

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Steinar Bang <sb@metis.no> writes:
>> >>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
>> 
>> > What is your Gnus work pattern that makes finding the relevant
>> > information in the ChangeLog deeply disagreeable?
>> 
>> 	C-x v l
>> in a CVS versioned file, to quickly find out what the last changes
>> were about.

> Well, it ought to be possible to write a command that shows the last
> ChangeLog entries for the current file...

Yes.  But I use CVS for completely different source code where I don't 
wish to have it look for a ChangeLog, because there isn't one.

Re: *** empty log message *** is a no-no

[Denys Duchier]

Steinar Bang <sb@metis.no> writes:

> > Well, it ought to be possible to write a command that shows the last
> > ChangeLog entries for the current file...
> 
> Yes.  But I use CVS for completely different source code where I don't 
> wish to have it look for a ChangeLog, because there isn't one.

`C-x v a' will create a ChangeLog file for you from the cvs log
entries.  There is no reason to _maintain_ a ChangeLog file,
especially since it contains less precise information than the cvs log
(e.g. time stamps).

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: *** empty log message *** is a no-no

[Jan Vroonhof]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> `C-x v a' will create a ChangeLog file for you from the cvs log
> entries.  There is no reason to _maintain_ a ChangeLog file,
> especially since it contains less precise information than the cvs log
> (e.g. time stamps).

The advantage of Changelogs is that you can write them at the time the
change is made, not at the time of commit. In addition Changelogs
contain the function/variable affected by the change and there is
support from Emacs to add them automatically.
Is there a way to have the same for CVS logs? What do typically do
when using CVS to document changes? use free format?

Is the resolution on the time stamps that important?

Jan

Re: *** empty log message *** is a no-no

[Denys Duchier]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> The advantage of Changelogs is that you can write them at the time the
> change is made, not at the time of commit.

Yes, that's a nice feature.  However, the ChangeLog idea is not really
appropriate for concurrent development (the record of changes only
becomes meaningful when it is synchronized with the repository,
i.e. at commit points).  I like the idea of being able to take notes
between commits, and it would be nice if appropriate default log
messages could be automatically computed from these notes.  Any
takers?

> What do typically do when using CVS to document changes? use free
> format?

`C-x v =' to diff with the committed version.  Then I document the
changes in fairly free format.  Typically, I have also added comments
in the file documenting the new stuff, or making clear the invariants
that should not be violated, etc... I also include these comments in
the log entry.

> Is the resolution on the time stamps that important?

I find it quite convenient, especially when you need to track down why
something no longer works which used to work fine before (maybe just
minutes ago).  I use `C-x v l' to get the log history, and, on the
basis of that information I use `C-x v ~' to compare with an earlier
version.  When you have lots of developers all concurrently modifying
the same files, timestamp precision can really help.  Of course, you
still have that precision in the cvs anyway, but the log messages help
you decide what to look at.

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: *** empty log message *** is a no-no

[Kai Großjohann]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> `C-x v a' will create a ChangeLog file for you from the cvs log
> entries.  There is no reason to _maintain_ a ChangeLog file,
> especially since it contains less precise information than the cvs log
> (e.g. time stamps).

Jan is right, I think.  Having the function name in there is a good
thing.  WIBNI there was a way to have that information in the CVS log,
too?

Jan, you're free to type C-x v v, then do some editing, then add stuff
to the *vc-log* buffer, then do some more editing, then finish the log
entry, then C-c C-c.  Though I've never tried...

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: *** empty log message *** is a no-no

[Jan Vroonhof]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> Yes, that's a nice feature.  However, the ChangeLog idea is not really
> appropriate for concurrent development (the record of changes only
> becomes meaningful when it is synchronized with the repository,
> i.e. at commit points).

No they are very useful for concurrent development. However I think
you mean concurrent development where everybody commits often.
I am thinking of shared development over the internet where typically
one commits complete bits of work. If they than also first submitted
for general review in the form of Patches, changelogs come in very handy. 

> `C-x v =' to diff with the committed version.  Then I document the
> changes in fairly free format.  Typically, I have also added comments
> in the file documenting the new stuff, or making clear the invariants
> that should not be violated, etc... I also include these comments in
> the log entry.

I like the fact that ChangeLog entries have a strict format that
includes the function names. I use them as a kind of CVS
annotate that is function based and not line based.
In addition in shared internet project you have the problem that CVS
annotate does not work over anonymous CVS.

> > Is the resolution on the time stamps that important?

In internet based collaborative effort timescales are of the order of
days anyway, so the resolution of one day is sufficient.

Jan

Re: *** empty log message *** is a no-no

[Denys Duchier]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> No they are very useful for concurrent development.

useful, but not appropriate.  what ultimately matters is the record of
committed changes.

> However I think you mean concurrent development where everybody
> commits often.  I am thinking of shared development over the
> internet where typically one commits complete bits of work.

My experience also comes from `internet' development projects.  Our
main project involves groups in germany, sweden and belgium.  We do
commit often (especially when responding to bug reports).  Personally,
I have several projects in computational linguistics that involve
multiple sites and a number of students modifying and extending a code
base that I provide and maintain.  And then, there are papers and
course material to be co-authored, documentation to be collaboratively
written, tools to be maintained, databases to be updated, etc...  I
don't know if my case is atypical; maybe you're right.

> > > Is the resolution on the time stamps that important?
> 
> In internet based collaborative effort timescales are of the order of
> days anyway, so the resolution of one day is sufficient.

well, not in my experience, but I guess your mileage may vary.  My
main beef with this is that empty log messages just don't help me any.
And saying "see ChangeLog file" also does not help (see what?).  I
want `C-x v l' to give me an informative log history of the file.

Second, empty log messages (or "see ChangeLog file") in the cvs
newsgroup are totally useless.  They defeat the purpose of having such
a newsgroup.

However, not being a gnus developer myself, my opinion is hardly the
one that really matters here.

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: *** empty log message *** is a no-no

[Lee Cantey]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> The advantage of Changelogs is that you can write them at the time the
> change is made, not at the time of commit. 

This is exactly what I do.

> In addition Changelogs contain the function/variable affected by the
> change and there is support from Emacs to add them automatically.

Yes, very useful.

> Is there a way to have the same for CVS logs? What do typically do
> when using CVS to document changes? use free format?

Here's the beauty.  I use ChangeLogs when doing development, then just
use those entries for the CVS commit.  It works pretty darn well.
You might want to look at PCL-CVS which automates quote a bit of this
for you.

Lee.

Re: *** empty log message *** is a no-no

[Jan Vroonhof]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> > No they are very useful for concurrent development.
> 
> useful, but not appropriate.  what ultimately matters is the record of
> committed changes.

I don't quite understand what you mean here. If you commit the new
ChangeLog entries with the changes they refer to the ChangeLogs also
only record commited changes?

> written, tools to be maintained, databases to be updated, etc...  I
> don't know if my case is atypical; maybe you're right.

I think it is more the other way around. It is Gnus (or in my case
XEmacs) that are atypical. 

> well, not in my experience, but I guess your mileage may vary.  My
> main beef with this is that empty log messages just don't help me any.
> And saying "see ChangeLog file" also does not help (see what?).  I
> want `C-x v l' to give me an informative log history of the file.

Indeed. I was never arguing for that. In fact I think making sure the
log messages get populated from ChangeLogs is a very good idea.
XEmacs currently has CVS logs of the style "Martin's patch" or "Some
patches for 21.1.19" which is highly annoying.

I am just arguing that currently  CVS logs cannot ChangeLogs replace
ChangeLogs, because the

1. The ChangeLogs have a logical grouping and this is more or less
   enforced. The changes explicitly name the functional unit involved.
2. ChangeLogs can be distributed easily with the tarballs.

What I would really want is a better VC system than CVS.

> However, not being a gnus developer myself, my opinion is hardly the
> one that really matters here.

I think input about issues, coming from experience, is just good a
contribution as coding.

Jan

Re: *** empty log message *** is a no-no

[Russ Allbery]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:
> Jan Vroonhof <vroonhof@math.ethz.ch> writes:

>> What do typically do when using CVS to document changes? use free
>> format?

> `C-x v =' to diff with the committed version.  Then I document the
> changes in fairly free format.  Typically, I have also added comments in
> the file documenting the new stuff, or making clear the invariants that
> should not be violated, etc... I also include these comments in the log
> entry.

As someone who uses both ChangeLogs *and* CVS commit messages for at least
one project, I actually put different information in both.  The ChangeLog
gets the typical per-function brief change message; the CVS commit log
gets a free-form chatty description of what I changed and why from more of
an overall perspective.

When using CVS, I don't find the traditional ChangeLog format all that
overly useful, and if I drop one, I'll usually drop the ChangeLog in favor
of the CVS commit history and just generate the ChangeLog automatically
from the commit history.  I find the noting of what functions changed in a
file to be considerably less useful than cvs annotate.

But a lot of this is driven by what sort of software one is writing.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: *** empty log message *** is a no-no

[Jan Vroonhof]

Russ Allbery <rra@stanford.edu> writes:

> from the commit history.  I find the noting of what functions changed in a
> file to be considerably less useful than cvs annotate.
> 
> But a lot of this is driven by what sort of software one is writing.

And how.. For instance CVS annotate does not work for anonymous CVS
:-(

Jan

Re: *** empty log message *** is a no-no

[Russ Allbery]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> And how.. For instance CVS annotate does not work for anonymous CVS :-(

That's odd... I wonder why that is.  It doesn't require writing to
anything.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>