vcs -- Version control made easy

Send comments, suggestions, and questions to don@vicorp.com.

Vcs is an emacs interface to a generic version control system.  Like
most other version control interfaces vcs provides its users with the
ability to check in, check out, lock, unlock and get a delta history
for its files.  So you might be wondering why you need vcs.  Well it's
quite possible that you don't.  But, if your working environment is
anything like mine I think you'll find that vcs has some very
important advantages over most other interfaces.

I work in an environment where nearly all source code is kept under
the control of sccs.  I, however, much preferred to use rcs for my own
projects.  What I wanted was a single emacs interface that would allow
me to manipulate either my employer's sccs files or my personal rcs
files.  I was unable to find an interface package that met my needs.
Nor could I find an existing rcs interface that was similar enough to
an existing sccs interface that I could feel comfortable learning and
using both simultaneously.  To make matters a bit worse, my employer,
like most that use sccs or rcs to manage a LARGE project, put shell
script wrappers around all of the normal sccs commands.  And if that
isn't enough to make most available interfaces nearly useless, throw
in the fact that the source is scattered about a directory tree
containing more than thirty sub-directories.

The other interfaces that I looked at were all designed to work in an
environment where the history (s. or ,v) files live in the same
directory as or a sub-directory of the working file's directory.  This
is great if you are the only one working on the source tree.  But with
many programmers, each possibly wanting to make conflicting (though
usually temporary) changes to the same source file, this approach
leaves much to be desired.

Vcs was designed to work in an environment where the history files
live in one directory tree and development is done out of a
programmers home directory.  The normal course of events for fixing a
bug or making an enhancement starts with copying the files you need to
somewhere in your home directory tree and locking those that you know
will need to be changed.  These files are then modified and compiled
locally and linked against the most recent version of the libraries
for testing.  When the changes are complete the unmodified files are
either unlocked or removed and the modified ones are incorporated back
into the main source tree.  If your environment is similar to this,
then vcs just might be for you.

Vcs will hunt down the source file you are looking for, without regard
for which version control system manages it or where in the file
system it lives, and allow you to manipulate it from the privacy of
your own directory.  You can even keep a copy of a public file in your
private version control directory, to incrementally log your changes
before putting the file back into its public version control
directory.  I often do this when I am making extensive changes to a
file and don't want to put an inconsistent version back into the
public source tree, but do want to be able to gracefully recover from
a mad editing session (it sure beats leaving numbered copies of the
file lying around).  On top of all that vcs provides a framework that
makes extending its capabilities to support other version control
systems (or wrappers) quite painless.

Take a look at the "complete" documentation in vcs.el for more details.

The file vcs-vi.el is provided as an example of how to deal with
wrappers that have been placed around the standard rcs and sccs
commands.

