On May 15, 11:06am, Emmanuel Gravel wrote:

> I'm testing cross-compatibility between two versions
> of CVS (1.10 on Linux and 1.3 on a very old system,
> can't update it so we're stuck). The question I have
> is with regards to the newer version though.
> 
> On the 1.3, a cvs update would yield ' * ' prepending
> $Log entries (space, *, space). In the newer version
> there is nothing. I was told it may be some RCS config
> to be modified but I haven't been able to find
> anything
> about this in the docs, and haven't found anything in
> the config of 1.3 (no .cvsrc or other local config
> files) or env on that system that would indicate any
> parameters modified for this behaviour. I'm trying to
> emulate it under Linux with 1.10. Anyone know what I
> should be looking for?

It looks to me like David has answered your question so I have nothing
to add with regard to the specifics of your question.

But I do have a remark to make about the use of $Log in general. 
Simply put, I think the use of $Log is a very bad idea.  Here
are my reasons:

    1) It clutters up your source files.  If you don't prune your
       log messages occassionally, you'll end up with more lines
       of log messages than lines of source code.

    2) It makes merging of branches much more difficult since your
       log entries will result in conflicts.  (Even $Header causes
       conflicts.  I don't like $Header either, but I find $Header
       marginally easier to justify than $Log.)

    3) It makes it harder to generate useful diffs.  (Whoever gets
       the diffs will likely have to remove the $Log portions first.
       And this can be hard if the $Log hunk overlaps some real changes.)

    4) If you commit a bunch of files at once, you get the same
       log entry put in each file.  If you do a decent job of
       describing exactly what's been changed, this results
       in a lot of replicated text in each file.

    5) The log information is available separately via "cvs log". 
       IMO, this is much more useful than storing the log information
       in the file.

I much prefer GNU-style ChangeLog files for recording the changes
which were made to a project.  They have the advantage of being a
separate file that is checked into and maintained apart from your
source control database.  This means that your change information is
available if you do a "cvs export" or if you decide to use different
source code control software.  Also, and more importantly, the
change information for related files is grouped together in one place
so that if a change to foo.c is made, you can see the reason for it
by examining the surrounding ChangeLog entries.

Kevin