NAME

scvs − Sprite Concurrent Version System

SYNOPSIS

scvs [scvs_options] [cvs_options] command [command_options] [command_args]

OPTIONS

−VPrint out verbose status messages during processing. 

−DPrint out debugging information. 

−helpPrint a summary of the command-line options and exit without updating any targets. 
 

DESCRIPTION

Scvs is a front end to the cvs source control system, which in turn is turn a front end for rcs.  It would probably help to be familiar with both cvs and rcs before dealing with scvs.  Scvs has the following features in addition to those of cvs and rcs:

• A configuration file is used to specify the root of the cvs repository, rather than an environment variable or a command line option. 

• Scvs keeps track of who has copies of which modules. When you check out a module scvs will tell you about other copies of the same module you might have, and about other users that have copies of the module.  This allows users to coordinate their modifications to a module. 

• Changes to several modules can be committed simultaneously. 

• Scvs remembers the options used to checkout a module, so that subsequent updates of the module use the same options, thus guaranteeing that the same version of the module is updated. 

• Scvs has limited support for symbolic links.  When a module is checked into the repository any symbolic links it contains are stored in a file called SCVS/links.  When a module is checked out its symbolic links are created from the contents of SCVS/links. 

COMMANDS

Each invocation of scvs must specify a particular command to be performed.  Most of these commands are slight variations on the corresponding cvs commands. 

add [−m ’message’] files...
Create a new file or directory in the repository.  Files are not actually added to the repository until a commit command is issued. See the cvs man page for more details. 

checkout [−QqlnfPi] [−c] [−r tag | −D date] modules... 
Retrieves copies of the specified modules from the repository. For each module a subdirectory with the module’s name is made in the current directory and the module’s source tree is put in the subdirectory. The default is to check out the most recent version of the module, although a particular version can be checked out by using either the −r or −D options, which will check out a version matching the given tag or date, respectively.  The semantics of the scvs checkout command differ from cvs’s in that empty directories are pruned unless the −P option is given.  Empty directories usually occur if you check out a version of a module from before a directory was created.  The −Q and −q options cause varying degrees of quietness, and the −l option causes the command to not be recursive.  The checkout command will tell you of other copies of the module that you might have, and about other users that have copies of the module.  If you are checking out a version to go off on your own and make changes that will never be checked back in, then you should use the −i option.  You will not be listed as having an official copy of the module, so other people will not be told that you have a copy.  Everything else works the same, however.  co can be used as an abbreviation for checkout. 

commit [−fnl] [−m ’log_message’] [−r revision] [modules...] [files...]
The commit command is used to check in the changes made to your copies of modules.  If no modules are specified then the current directory is checked in.  Scvs differs from cvs in that multiple modules can be checked in simultaneously, and that commit is recursive.  Scvs achieves this by locking all modules, verifying that they are up-to-date with the sources in the repository, then committing the changes.  Scvs will also update a snapshot or installed copy of the sources as indicated in the SCVS.config file (see FILES section below).  The −f option allows you to commit files that do not contain the RCS $Id or $Header keywords.  The −r sets the RCS version number, and the −n option causes any commit command in the module database to not be run. If the −m option is not specified than an editor will be invoked to allow you to enter the log message.  ci can be used as an abbreviation for commit. 

diff [−lR] [rcsdiff_options] [files...]
Same as for cvs. Runs rcsdiff on the specified files, or on only those files that you have changed.  Diff is recursive unless the −l option is specified.  If no options are given diff will print out the differences between your copy of the file and the copy you checked out, i.e. it prints the changes you made to the file.  If the −R option is given then the differences between your copy of the file and the current version is given.  This is useful if your copy is out-of-date and you want to see what changed.  See the rcsdiff man page for more details on the options. 

done [−d] modules...
When you have finished with a module you should use the done command, so that scvs can update its database of module copies.  If the −d option is given then your copy of the module will be deleted.  If your copy differs from the repository scvs will ask you whether or not you are really done.  Make sure you really, truly are done before running this command, particularly with the −d option. 

info [−l] [files...]
Prints out status information about your sources. Output is the same as for the update command.  Info is recursive unless the −l option is given. 

join [−Qqf] [−r tag | −D date] files...
Same as for cvs. Used to merge in a new vendor release of a software package.  See the cvs man page for details. 

lock [−rw] [modules...]
Each scvs command locks the module in the repository before mucking around with it, thus preventing concurrent scvs commands from creating chaos.  If you wish to run several scvs commands without allowing other users to run commands inbetween you can use lock.  A common example is committing your changes to a module.  If you don’t lock the module first there are potential races between the time you update your sources and the time you commit them, and between the time you commit them and update the installed copy.  To prevent these races you should lock any modules you want to commit, then run any commit commands, verify that the installed sources are correct, then unlock the modules.  The −w option creates a write lock (the default), so that you have exclusive access to the module.  The −r option creates a read lock, allowing other users to read the module but not modify it.  See the unlock command below. 

log [−l] [rlog_options] [files...]
Same as for cvs. Does an rlog on the specified files, or on every file in the current directory.  Log is recursive unless the −l option is specified.  See the cvs man page for details. 

pack [−l] [dirs...]
The pack command is used to put entries for all symbolic links in the given directories (or the current directory) into the file SCVS/links (see FILES section below).  This file can then be used later by the unpack command to recreate the symbolic links.  The pack command is run implicitly during a commit, and is not usually invoked explicitly.  Pack is  recursive, unless the −l option is given. 

patch [−Qqlf] [−s|−t] [−r tag|−D date [−r tag|−D date]] modules...
Same as for cvs.  Creates a patch file between the two versions of the modules.  See the cvs man page for details. 

remove files...
Same as for cvs.  Removes the specified files from the repository.  The files are not actually deleted until the current module is committed.  See the cvs man page for details. 

status [−l] [files...]
Same as for cvs.  Prints out the rcs version in your copy of the file and the current rcs version of the file in the repository.  Status is recursive unless the −l option is specified.  See the cvs man page for details. 

tag [−Qqlfn] [−d] [−r tag|−D date] symbolic_tag modules...
Same as for cvs.  Assigns a symbolic tag name to the given (or current) version of the sources in the repository.  See the cvs man page for details. 

unlock [−a] [modules...]
Removes any locks you have on the modules. If the −a option is given then all locks on the module are removed.  See the lock command above. 

unpack [−l] [dirs...]
Creates symbolic links in the specified directories (or the current directory) from the contents of the SCVS.links file. The unpack command is run implicitly during a checkout or update, and is not usually invoked explicitly.  Unpack is  recursive, unless the −l option is given. 

update [−QqlfpB] [−e dir] [−d] [−r tag|-D date] [modules...] [files...]
The update command is used to make your copies of modules up-to-date with the sources in the repository. The default behavior is to bring your copy up-to-date with the version that was checked out, although this can be modified with the −r or −D options.  You will have to specify these options to subsequent update commands if you wish to continue to use a different version than the one that was checked out.  Update is recursive by default, but this can be overridden by the −l option.  The −B option will cause update to not update your sources with any new directories in the repository.  The default behavior is to do so (this differs from cvs).  See the cvs man page for more details on the algorithm used by update and for an explanation of its output. 

who [modules...]
Prints out the names of users who have checked out copies of the modules.

FILES

SCVS.config
When scvs is invoked it works its way up the directory tree looking for the file SCVS.config.  The first one that is found is used.  The SCVS.config file has the following format.  A blank line or a line beginning with ’#’ is ignored. A line beginning with cvsroot: specifies the pathname of the cvs root directory.  The following is a sample SCVS.config file for the Sprite kernel sources. 

cvsroot: /sprite/src/kernel/Cvsroot
installdir: /sprite/src/kernel

SCVS/args
This file is created by the checkout command, and is put in the top-level subdirectory of a module copy.  It contains the arguments passed to the checkout command, so that subsequent update commands use the correct version of the sources. 

SCVS/links
The SCVS/links file contains information about symbolic links in the module sources.  Each line is of the form "linkName target", where linkName is the name of the symbolic link to be created, and target is the file to which the link points.  SCVS/links is created by the pack and commit commands, and read by the checkout and update commands.  Each subdirectory of a module has its own SCVS/links file. 

SCVS/users
The SCVS/users file exists in each module in the repository and contains information about the users who have the module checked out.  Each line is of the form: "user path date", where user is the name of the user who has the module checked out, path is the pathname of their copy of the module, and date is the time when the copy was checked out. 

SCVS/locks
Exists in the module directory in the repository and contains a list of locks on the module.  Each line is of the form "type user date", where type is one of r or w, user is the login name of the lock owner, and date is the time the lock was created. 

SEE ALSO

rcs(1), ci(1), co(1), rcsdiff(1), patch(1), rcsmerge(1), rlog(1), cvs(1)

KEYWORDS

source control, rcs, cvs
 

Sprite version 1.0  —  October 28, 1991