> > (5) Unnecessary remake of the file
> > (and all files that depend on it)
> >
> > when I repeat the process.
>
> That step is not "unnecessary" given the tools that you are using.
Agreed.
It's obviously unnecessary in an abstract sense,
but make is not smart enough to handle it.
> If you don't want the "unnecessary" recompiles then you have to either
> use a smarter build system (an incremental compiler in an IDE, for
> example);
Yes. Unfortunately, I haven't found an IDE smart enough to
handle this. Neither Cygnus CodeFusion nor Microsoft VC++
seem to be smart enough to do this.
The only IDE that seems to be smart enough to do this
is IBM Visual Age, which keeps everything in a database.
But then, you don't need CVS.
> or stop using RCS keywords in your source files.
>
> You can of course be much more selective about when keywords are
> expanded too. You could use '-ko' (which will be "sticky" in the CVS
> sense if set on checkout), or perhaps '-kk' (which I think will also
> become "sticky" on checkout). Then when you make a release with "cvs
> export" you would use '-kv' to freeze the current values of the keywords
> into your files for the actual release.
Yep.
Unfortunately, CVS's defaults are a bit awkward.
cvs admin -kk, etc, set the default flag in the repository.
cvs update -kk, etc. set the default flag in the checked out
working area, overriding the default in the repository.
If you have binary files with -kb set in the repository
(yeah, yeah, I know what you think about that Greg)
then doing a cvs co -kk breaks them.
The only safe thing is to set -kk for various files in the
repository, and then, selectively, use cvs update -kkv
when you want expansions. Export is, of course,
broken in this regard.
Of course, only expanding keywords in releases loses
much of the benefit of keywords. I use keywords for
personal use; I don't do releases. But I find keywords
useful in tracking down where files came from,
especially if there are different CVS repositories around.
(CVS, as usual, doesn't comprehend multiple
repositories. Oh, I'm waiting for BitKeeper...)
Not all CVS keyword expansions are equally bad.
$Source$, for example, doesn't hurt since it changes
rarely. $Revision$ causes the unnecessary recompiles.
But there is no way to specify "Expand $Source$ but not $Revision$."
===
This has a wierd sense of deja vue.
You may remember that Brian Berliner dissed my old Gould version
control system: he did not understand the optimistic concurrency
control, lock only in extremis algorithm, and he did not think
that saving diskspace and compilation time by managing pre-built
objects mattered.
Wrt concurrency control Berliner was just plain wrong.
I am amused that recent programming fads like XP
are moving back to stronger serialization models
during integrayion. (At least as discussed on the XP
mailing list: single integration machines.)
Wrt diskspace and compile time, he was partially right.
Well, in the years 1985-1988 I think he was wrong.
At least in the companies where I worked.
Disk space mattered, and C compilers were slow.
Admittedly, Brian left Gould/DTI before I joined;
he was probably smart enough to go off to a startup
that was willing to spend money. (I was a visa slave.)
In 1988-1999 he was right. Disk space got cheap,
and C compilers were fast enough.
Around 1998 I started using C++ heavily.
Much to my displeasure, I discover that compile
times matter again.
