> HOWEVER, since a *HUGE* part of ``open source'' systems is the
> ability to track "vendor" deveopments in nearly real time, and the
> arguably best way of interactively staying "current" with the tree
> is indeed by using CVS, *and* since the best (only real?) way of
> tracking and investigating the details (diffs, commit comments,
> tags, etc.) of "vendor" changes, it's not too much of a stretch to
> conclude that CVS is indeed a critical tool for self-hosted
> development of NetBSD.

But CVS is only one of several possible tools which can accomplish
this goal.  And while it's in vogue in with open source projects now,
it might not be forever.  CVS has a lot of aggravating flaws both in
its design and implementation and has a source base which is
notoriously difficult to work with.  And the level of current CVS
maintenance is lackluster at best.

I think it would be unfortunate if we integrated CVS and then, three
years down the road, it turns out that Bitkeeper or Aegis or
Subversion is popular (I know Bitkeeper has licensing issues, but that
might not always be the case) and CVS is considered old cruft.

You might argue that this situation applies to almost any development
tool, but the likelihood of CVS being successfully replaced is high in
my book, and the transition costs are much higher for replacing a
version control system than for replacing other development tools.
Different implementations of make can all handle a reasonable least
common denominator of Makefiles and much of the same command-line
syntax.  Different implementations of the C compiler can all handle
the same source code and even some of the command-line flags.  But
different version control systems are totally different from a usage
and administrative perspective.

(Disclosure of possible bias: I'm a Subversion developer, although I'm
not entirely sure whether I'll want to use it when it's done.)