TRAXtrack simulation, the therapy planning
gdgraphics program, and possibly many others (
$CVSROOT. For the members of the
biogroup this variable is set automatically in the login profile. Additionally, most CVS commands allow to specify this location directly. All members of the
biogroup have read access but only members of the
biodevgroup have write access to this pretty holy area.
$CVSROOTarea must be executed under the process group
biodev. This is ensured by means of the
s-bit set in all relevant directories.
The CVS installation active in Biophysics has adapted versions of
$CVSROOT/CVSROOT/loginfo.sh $CVSROOT/CVSROOT/commitinfo.shto allow special actions after check-in, e.g. automatic generation of readable (and compilable) source copies.
mkdir <repository> export CVSROOT=<repository> # include this in some central profile cvsinitThis procedure is already completed for the biophysics.
cvs co CVSROOT cd CVSROOT
modules. Add a line like
<project-name>is the name of your software project and
<dir>is the name of a directory in
$CVSROOTwhich will contain all files belonging to the project. Normally one would choose the same name for both.
cd <import-dir> cvs import <dir> <vendor-tag> <release-tag> # import into repository cvs co -d $CVSROOT/../<dir> <project-name> # checkout readable copies into reference directory chmod g+w $CVSROOT/../<dir> # make that group-writablewhere
<release-tag>are some dummy names needed by CVS to work.
cd TRKIMPORT cvs import TRK novendor norelease # import into CVS cvs co -d $CVSROOT/../TRK TRK # make reference copy for everybody chmod g+w $CVSROOT/../TRK # allow access for other developers cd .. # go back cvs co TRK # working copy for yourself
,v, same as CVS. Directly:
mkdir $CVSROOT/<project-name> chmod g+w $CVSROOT/<project-name> # allow access for other developers cp -p <project-name>/RCS/* $CVSROOT/<dir> cp -p <project-name>/* $CVSROOT/<dir> ... # additional stuff to be savedExample:
mkdir $CVSROOT/TRK cp -p $TRK/RCS/* $CVSROOT/TRK # the *,v files from RCS cp -p $TRK/* $CVSROOT/TRK # readable source files etc cp -p -r $TRK/TEST $CVSROOT/TRK # all subdirectories containg test stuff
Entries, Repository, Root
echo $CVSROOT/<dir> >CVS/Repository
echo $CVSROOT >CVS/Root
mkdir $CVSROOT/<dir> cvs add <file-list> cvs ci
cd ~ cvs co <project-name>creates a directory
<project-name>in your home directory with all (!) sources of the given project. If you want another destination directory you use
cvs co -d <other-dir> <project-name>Example:
cvs co -d TRKFUDGE TRKchecks out the complete
TRKproject to some alternative fudge directory.
cvs co -d TRiP98-my2kx -r pre2kx TRiP98This requires the existence of the release tag
cd <project-name> ... edit etc. cvs ci <file> ... rebuild libraries and executables in repositoryExample:
cd TRK vi trkvol.c ... cvs ci trkvol.c make -f trk.make # rebuild object library libtrk.a make -f trk.m # rebuild executable trkCVS will store the source file into the central repository, but keeps a local copy in your working directory. If commit fails because someone else has checked in the same file with his/her changes goto the next step.
cvs update <file>to bring your local files in sync with the central repository. It might then be necessary to repeat the previous step.
<project-name>.maketo rebuild the object library
lib<project-name>.aand a make file
<project-name>.mto rebuild the complete executable. (e.g.
cd <project-name> cvs add <file> cvs ci <file>As above, you have to rebuild the associated library and the executable.
-kbwhen files are added:
cd <project-name> cvs add -kb <file> cvs ci <file>
cd <project-name> rm <file> cvs remove <file> cvs ci <file>As above, you have to rebuild the associated library and the executable.
cvs rtag r9712 <project-name> # by last revision cvs rtag -D 2012-02-01 pre1107 TRiP98 # by datewill assign unique release tags
pre1107, respectively to all files (recursively through all directories) of the project. Note that release tags must start with a letter. One can get rid of them by e.g.:
cvs rtag -d wrongtag <project-name>
b9801with one of the two possibilities:
cvs rtag -b -r r9712 b9801 <project-name> cvs rtag -b -D "31 Dec 97" b9801 <project-name>The branch
b9801consists of all files with the tag
r9712in the first case or all revisions not older than "31-Dec-97" in the second case.
cvs co -d <project-name>9801 -r b9801 <project-name>Updates and check-ins now only occur within the branch and the local working copies, the "main trunk" remains unaffected !
cvs co -d <project-name>merge -j b9801 <project-name>will first merge the differences between main trunk and branch recorded in the repository into a merging directory. Usually conflicts have to be resolved manually, then
cd <project-name>merge cvs ciwill store back the results into the repository. Note that the branch still exists.
cvs co -d <newproject-name>IMPORT -r b9801 <project-name>Remove all
<newproject-name>) as described in Setting up a new project.
beamand all sources in project directory
cvs co -r beam -d $CVSROOT/../TRiP98BEAM/TEST/RBE TRiP98/TEST/RBEOther example:
cvs co -d $CVSROOT/../TRiP98 TRiP98will produce reference copies for the entire
emacsas its default editor for entering comments on check-in.
emacsor faulty X session. In this case one may revert to simpler editors like