Re: Commit inconsistency: Up-to-date check did not fail though it sho uld have !

[Kaz Kylheku]

On Wed, 19 Feb 2003, Ludvig Borgne wrote:

> > Just go to the highest relevant directory and type ``cvs ci'' with no
> > arguments, or at most a -m to specify the message.
> 
> Hmm, this is interesting. I have always been (and still am) of the
> opinion that one should always commit individual files, and never ever
> do a 'cvs commit' on the top level of a module. Why? Because top level
> commits usually create poor log messages (same for all files), and

A log message that is the same for all files is not necessarily a poor
log message, and separate messages are not necessarily better.

Look at how ChangeLogs work. There is one entry, with a date, and the
author's name, and then descriptions of all the changes, file by file.

It's useful for a comment to gather together all related changes in one
description. If I'm browsing the history of foo.lisp, it's useful to know
how some change correlates with something in bar.lisp.

If you don't commit often enough, however, you can get into the
situation where your tree contains many unrelated changes, which should
not be described by one comment.

I combat this effect by keeping more than one sandbox for isolating
changes, but it's not always convenient.

> because it makes it far too easy to commit files that you have just
> made temporary modifications to (e.g. changing a make file to compile
> with debug flags) that you really don't want to commit at all.

Maybe your local copy of the software works only because you made these
local modifications, so that if you don't commit them along with your
``real'' changes, it will break for someone else. The other developers
may be building without the altered Makefile.

Note that if you have to change your Makefile to make a debug build,
and if changing the Makefile results in a local modification to a
sandbox file, you have a few ugly warts in your project setup.

Firstly, a nice Makefile can be constructed which will build multiple
configurations of the same software: debug, optimized, profiling, ...

On one project I worked on, six different configurations of the same
thing were compiled. I set it up so that the object files were all
dropped into the same directory, but with alternate suffixes: .o was
native optimized, .d debug, .armo was optimized, cross-compiled for
StrongARM, etc.

Secondly, if you must locally edit Makefiles, then it's probably a good
idea to actually store them in CVS under a different name, requiring
everyone to make a local copy, use a symbolic link, or invoke ``make''
with the right argument to point to the file. This becomes quite handy
if you ever need two or more different makefiles, to accomodate
incompatible make programs: e.g. Makefile.gnu, Makefile.vc.

> Oh well, I guess I must be a total idiot then...

You *can* commit individual files, if you are certain that your changes
preserve the relationships between those files and the rest of the
project.

Say you have some ``foo.c'' in which you change something in the foo()
function without changing its interface, or semantics.  Sure you can
commit that on its own.

Say that instead, you change the foo() interface or semantics, or
extend them in some backward-incompatible way, and fix all uses to
foo() that you see in your working copy to match the new version. You
shouldn't commit those files individually, because someone may have
commited a change elsewhere which introduces a new dependency on that
function's old interface or behavior.

You can also get away with individual commits most of the time, if you
remember to do a whole-tree update just before. Then you are
essentially racing to do a commit before any new changes come in that
will break it. If you win the race most of the time, you are okay most
of the time. ;)