Re: A couple of features in RCS that CVS lacks... why?

[Eric Siegerman]

On Fri, Jul 27, 2001 at 01:48:25PM -0700, Josh Baudhuin wrote:
> First off, I'd expect that the  update  and  commit  command would have
> co(1)/ci(1)'s  -s<state>  option to allow you to pull the latest rev of a
> certain state.

With CVS, one tends to use tags and branches, not revision
states, to distinguish between development, stable, and release
code.

It's not that useful, IMO, to know that rev. 1.8 of foo.c is
"stable".  That revision is NOT stable in isolation, but only
when used together with rev. 1.3 of bar.c, rev. 1.17 of
everything.h, etc.  When you try to use 1.8 of foo.c with 1.15 of
everything.h, which was the latter file's "stable" revision last
week, all hell breaks loose.

With a (release, i.e. non-branch) tag, you can label a stable
"cross-section" of the the entire project.


> The second thing is that  commit  loses ci(1)'s  -T  option,
> which makes sure the archive file has the same timestamp as the
> working copy being commited. As the ci(1) documentation states:
> 
>                 . . . [Not having -T] can cause excessive  recom-
>           pilation  caused by a make(1) dependency of the working
>           file on the RCS file. . . .

(I understand that lack of -T turned out not to be your problem.
But for posterity I'll comment on it anyway.)

The reason -T is useful in RCS is that people tend to have rules
in their Makefiles to check out the latest revision of a file if
the sandbox version is out of date with respect to its ,v file.
The reason for automating it like this, I suppose, is that to
update the entire project manually would entail typing
potentially many "co" commands, and having to decide in each case
whether this was what you really wanted to do.

In CVS, it's preferable to let the user do a "cvs update"
manually, at times convenient to them, rather than having the
build system force it on them.  It's only one command to type, so
the cost of making it a manual step is low.  The benefits of
doing so include:
  - If you're in the middle of tracking down a problem, and
    someone else commits a buggy version of a file, an automatic
    update at a bad time would confuse your debugging efforts.
    In general, having to deal with other peoples' changes as
    they're made is more annoying than dealing with them only at
    times of your own choosing.

  - Because of CVS's concurrent-edit model, an update is
    potentially more expensive than in RCS -- it may entail a
    merge.  This would be especially unpleasant to deal with if
    the build system forced it on you when you didn't want it.
    (In practice, of course, merges usually aren't a big deal as
    long as you update frequently -- otherwise the
    concurrent-edit model would long ago have been rejected as
    unworkable.  But what makes the occasional big-deal merges
    acceptable is that YOU decide when to take the risk.)

  - As you've noticed, the interactions between the update and
    the build system can lead to unpleasantness.  -T is a kludge
    to help reduce this.

In short, CVS automates the drudgery of an update, so it's no
longer useful to have the build system do so; the benefits of
doing updates in "make" are reduced to the point that they no
longer outweigh the costs that were there all along.

Given that, it's thus not surprising that CVS doesn't bother
implementing -T, whose only purpose is to make this
no-longer-useful technique slightly less painful.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)