Maintaining multiple versions of software is difficult. Usually there are two versions (at least) -- a working version and a version under development. It is impossible to maintain the two versions in the same directory since everytime a file was compiled for one version or the other, it would clobber the file that was there previously. So a seperate directory structure is maintained -- one that contains the working version and the other the version that is under development. So now the question becomes, "How to copy the source from on place to the next?"
You could "release" the source file to someone, who takes responsibility for copying it to the appropriate area. This works to a limited degree. As more people release files, the person doing the copying is more likely to miss files or copy the wrong ones. It is also difficult to continue development on a module if you are not sure exactly when the person doing the copying will copy it.
The simplest method is to just let RCS take care of it. One uses symbolic links to the RCS directory to get access to the RCS files. This keeps the files seperate and allows RCS to control access to the files, which is what it is designed to do. All the RCS commands will work if the RCS directory is accessed through a symbolic link. The following commands will make a miniature directory structure that should illustrate the method.
mkdir v1 v2 # version 1 and 2 mkdir v1/src v1/include v2/src v2/include # main directories mkdir v1/src/RCS v1/include/RCS # directories for RCS # Now create the symbolic links to the RCS directories cd v2/src ln -s ../../v1/src/RCS v2/src/RCS cd ../include ln -s ../../v1/include/RCS v2/src/RCS
If there were some files in the RCS directories under `v1/src', then they could be checked out under both `v1/src' and `v2/src' (of course only one could be locked). The revision's checked are independent. The revision under `v1' could be 1.4 and under `v2' it could be revision 1.23 that is checked out. Two people could be compiling different versions of the software without clobbering each others work.
This is great, except one does not want to have to keep track of the appropriate revision number for each file in the system. This is where RCS's symbolic names (not symbolic links, which are from Unix) come in. To compile a particular version of the software, one specifies that revision Ver1 is to be checked out.
co -rVer1 test.c
or, if using make:
make COFLAGS="-rVer1"
This would compile version 1 of the software (assuming Ver1 meant version 1, not version 2).
The developer is responsible for assigning the symbolic name, since that
is the person who knows when a revision is ready for a particular version
of the software. Assigning symbolic names can be done at check in time
or with the rcs command. Assigning a symbolic name to a revision
should not be done lightly. It implies that file is ready for release
into this version of the software. Updating a name to refer to a
different revision should not be done lightly because someday someone
might want to build that exact version of the software with that exact
bug that was fixed by your newest version. While this may not be too
likely, it should be considered.
The number of symbolic names is limitless, so there is no need to limit
yourself to names such as Ver1. We might use Ver1_1,
Ver1_2, ... and so on as needed. At the same time, one might
want to keep track of your own particular versions. This can be done by
selecting names that do not conflict (and hopefully will never conflict)
with names used by the overall system. A name like pete1_1 is
fairly safe.
Go to the first, previous, next, last section, table of contents.