Date: Tue, 18 Apr 95 10:13:14 EDT
From: den AT aisinc DOT com (Dave New)
To: kentl AT bdc DOT cirrus DOT com
Subject: RCS on multi-platforms (was Re: SCCS)
Cc: leisner AT sdsp DOT mc DOT xerox DOT com, djgpp AT sun DOT soe DOT clarkson DOT edu


Kent writes:

> I've been thinking of adopting RCS for personal projects, so 
> I'm curious: 
> 
> a) Does RCS have any mechanism like this (environment variables) to
>    help locate the archive files.
> b) Does RCS _require_ the ",v" extension, or can another naming convention
>    be used (e.g. none - archives & workfiles have same name, just different
>    path)?
> 
The RCS that we have been using under SunOS 4.1.3_U1 is actually normally
"covered" by CVS 1.3, so what is usually in a checked out directory is a
CVS directory that contains (normally) two files : Entries and Repository.

The Entries file lists the files and RCS version of the files in the parent
directory, and the Repository contains a single line that lists the fully
rooted path of where the files came from.

CVS works by setting a CVSROOT environment variable, so that it knows where the 
"root" of your repository tree is.  What this means, in general, is that RCS 
does the real check-in check-out work, but CVS adds a configuration management 
layer on top that makes the chore of freezing and tagging lists of RCS versions 
a bit easier.

CVS doesn't track groups of various freezes, though, like that version 3.4
of 'foo' goes with version 3.46 of 'bar', where 'foo' is your favorite
compiler and 'bar' is your favorite application library that was compiled
with 'foo'.  There is a package called 'BCS' (baseline control system) that
does this, but we haven't experimented with it.  BCS also sets up links to
copies of files from the repository, replacing them with real files only
if you need to edit them.  This solves another problem that CVS seems to
aggravate -- every programmer finds out rather quickly that if they want
a private "sandbox" for development, they need a copy of the whole latest
stuff from the repository local to them, so the build/makes work properly.

If the repository contains several hundred megabytes of source, a group of
five programmers can easily tie up over 2 GBytes of disk with their sandboxes.
The current attitude is that disk space is cheaper than solving that problem
in a hurry, upsetting our current development environment.  We are working to
change things by evolution, not revolution! 8-)

Our company is interested in migrating from SunOS to Windows/NT, so that is
why we are involved in figuring out how to support our development environment
on multiple platforms.  The target, by the way, is neither of these boxes.
It is embedded i960CA RISC stuff, so off-the-shelf commercial solutions don't
come easily.

We don't have a CVS running on i386, yet, either.  Seems like we could get
that to work by compiling it under dgjpp, though.  I'll be looking into that
later this week.

DaveN