[ On Sunday, December 10, 2000 at 11:24:02 (-0500), Andrew Brown wrote: ]
> Subject: Re: Removing cvs from basesrc.
>
> fwiw, i use rcs all the time, and cvs almost never, hence, i am
> opposed to the idea of removing rcs from basesrc.  when working in a
> small group, rcs is fine.  removing both source code revision control
> systems from basesrc would be bad.

Indeed it would be very bad to remove all revision control systems from
basesrc.

FWIW I have been working on a modernized and rewritten "etcupdate"
script which will use RCS (and explicitly *not* CVS!) to maintain local
changes to distributed files in /etc and to assist people who build from
source in updating their /etc files without loosing any local changes.
This tool will require the daily archiving of files listed in
/etc/changelist use RCS too, of course....

In fact I think a number of current tools which at this time manage
changes to files in extremely naive ways should be "fixed" to use RCS
instead.

Such uses of RCS in basesrc tools would obviously give a solid technical
reason for keeping RCS in the tree.

As for keeping CVS in the tree, well I've never been 100% enthused about
having it there, especially since there don't seem to be any major
necessary fixes that are only in the in-tree version....

I do find some merit in the argument that since use of anonymous CVS is
a "supported" way of tracking NetBSD-current then the tool(s) used to do
that should be a part of the base system.

There's also obviously jsut as much merit in the argument that NetBSD
should have useful tools in the base system (and even games!) even if
they're not needed to build or maintain or operate the base system by
default.  So, if RCS is a useful version control tool for individual
text files and if CVS is a useful version control tool for groups of
text files, and since neither can do the other's job in a truly usable
manner then both should co-exist in the basesrc tree.

Having binary packages of CVS available (and maintained) for each
supported binary version of the system would be highly useful for many
people, of course, and thus would mitigate the need for having it in
tree, unless of course some other part of the base system were to
require it.  (By "maintained" I mean that if a new release of CVS is put
into pkgsrc then binaries for each supported NetBSD release should be
built and made available so that binary-only users can upgrade it.)

As an aside to the RCS part of this discussion I should say that
personally I still like SCCS best for simple version control of
individual files or small groups of files within one directory (for one
because it doesn't go hog-wild on silly branching features, and also
because it ensures better data integrity), but GNU CSSC is way too much
to expect to import into the system, and like MySC (CSSC's predecessor
and now maintained in parallel) it is still incomplete.  There's BitSCCS
(by Larry McVoy) which, unlike his BitKeeper product, is apparently
truly freely redistributable (and it has RCS command-line emulation
too...).  I don't know if he's actively maintaining it separately
though.

Certainly if "history" were the deciding argument though then having
SCCS in-tree would be more important, IMO, than having RCS there!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>