Introduction
This is an attempt to put together some of my notes on how to use the WSG
development environment, know as "wsgdev", and available via setup.
Wsgdev has two major parts, the Imake support accessed via
wmkmf and the software version control supplied by
cvs.
CVS is used to provide version control on a number of different software
modules. It also supports several people working on the same module at the
same time, and then providing assistance in merging the changes back in.
To see how it was intended to be used, there is
Scanner's paper
that discussed what he originally set up. He also has some notes and a
tutorial.
For general background, there is a paper describing CVS called
CVS II: Parallelizing Software Development. There is also a
man page available.
In theory, when you want to work on a module, you would
check it out into your own space (locker or home
directory), make the changes and test them, commiting
the changes periodicaly. If you want to add a new file/directory to
the source tree, do a cvs add. Once all the work
is done, you need to tag and rtag
the module so you can later retrieve it. You use this to assign a new
version number (release). You can now release
your development version, and then export a
stable version into campus and rebuild it there.
If you do a cvs checkout {module}, where {module} is the
name of the module you want, it will create a source tree in the current
directory, starting with the module name.
The release command will verify that you have committed and tagged all
your changes, remove your name from the database of checked out modules
and then if you have specified "-d", remove the directory you had created
in the checkout step.
The commit command saves all your current changes back to the repository. In
the process, it does an "rcs ci" of all files that have been changed since
the last commit. For all files that have changed, you will be prompted for
the change text to include.
The export command extracts a source tree without the CVS directory info,
and places it into the directory specified with the -d option. (if you don't
use -d, it regenerates the module directory, which isn't what we want in campus)
You also need to specify what version, generally the one you just checked in.
The cvs history -T is handy to fund your options.
Suggestion - When exporting, mv the old src directory aside, and have export
create a new one. This ensures that you get a clean copy, and in case we
missed something, you won't have old and new versions fighting.
The tag information is stored in each RCS file. Unfortunatly, this makes it
harder to search globally, so we generally also do a rtag which puts the
tag info into the central repository.
You can use the "cvs history -T" command to see the current state of tags.
You generally use "cvs rtag -r {tag} {tag} {module} where {tag} is the
tag specified in the tag command. This keeps the names in sync.
You can use tags without an rtag when you want to checkpoint code that is
under development, but don't want to generate a new release yet.
New files are added to the current module with the CVS add command. You need
to be in the same directory with the file/directory. Once you add it, you
will then need to commit it, to actually get it pulled back to the repository.
You can see what modules you have checked out with the history command. To see
all the modules that are currently checked out, use the -a option.
jfinke@rpi.edu