DCVS(1) DCVS(1)
NAME
dcvs - Distributed Concurrent Versions System
SYNOPSIS
dcvs [ dcvs_options ]
dcvs_command [ command_options ] [ command_args ]
NOTE
This manpage is based on the FreeBSD cvs (1) manpage. It was enhanced
to describe new features introduced by Distributed-CVS (DCVS). (October
24, 2005)
DESCRIPTION
DCVS is based on the well known CVS (Concurrent Versions System)
project. In addition to all CVS functionality, DCVS offers interesting
new features:
Distribution
DCVS allows distributing the repository across multiple servers,
which can cross-replicate automatically. A secure and practical
model to split responsibilities among the repository servers is
enforced.
Snapshots
A snapshot is simply a map of file names to specific revision
numbers. The concept is similar to a tag, but in contrast, a
snapshot is stored as a single, separate file, independent of
the repository files themselves.
For a complete description and examples, see `Changesets and
Snapshots' below.
Changesets
A changeset is an explicit way to denote the difference between
two configurations. It is basically like a snapshot, but with
two revision numbers mapped to every file name. It is also kept
in a single text file, independent of the repository files them-
selves.
For a complete description and examples, see `Changesets and
Snapshots' below.
Just like CVS, DCVS is a version control system, which allows you to
keep old versions of files (usually source code), keep a log of who,
when, and why changes occurred, etc., also similar to RCS or SCCS.
Unlike the simpler systems, DCVS does not just operate on one file at a
time or one directory at a time, but operates on hierarchical collec-
tions of directories consisting of version controlled files. DCVS
helps to manage releases and to control the concurrent editing of
source files among multiple authors. DCVS allows triggers to
enable/log/control various operations and works well over a wide area
network.
dcvs keeps virtually a single copy of the master sources, which will be
replicated across the distributed servers. This copy is called the
source ``repository''; it contains all the information to permit
extracting previous software releases at any time based on a symbolic
revision tag, a snapshot, or a date in the past.
ESSENTIAL COMMANDS
dcvs provides a rich variety of commands (dcvs_command in the Synop-
sis), each of which often has a wealth of options, to satisfy the many
needs of source management in distributed environments. However, you
don't have to master every detail to do useful work with dcvs; in fact,
five commands are sufficient to use (and contribute to) the source
repository.
dcvs checkout modules...
A necessary preliminary for most dcvs work: creates your private
copy of the source for modules (named collections of source; you
can also use a path relative to the source repository here).
You can work with this copy without interfering with others'
work. At least one subdirectory level is always created.
dcvs update
Execute this command from within your private source directory
when you wish to update your copies of source files from changes
that other developers have made to the source in the repository.
dcvs add file...
Use this command to enroll new files in dcvs records of your
working directory. The files will be added to the repository
the next time you run `dcvs commit'. Note: You should use the
`dcvs import' command to bootstrap new sources into the source
repository. `dcvs add' is only used for new files to an already
checked-out module.
dcvs remove file...
Use this command (after erasing any files listed) to declare
that you wish to eliminate files from the repository. The
removal does not affect others until you run `dcvs commit'.
dcvs commit file...
Use this command when you wish to ``publish'' your changes to
other developers, by incorporating them in the source reposi-
tory.
OPTIONS
The dcvs command line can include dcvs_options, which apply to the
overall dcvs program; a dcvs_command, which specifies a particular
action on the source repository; and command_options and command_argu-
ments to fully specify what the dcvs_command will do.
Warning: you must be careful of precisely where you place options rela-
tive to the dcvs_command. The same option can mean different things
depending on whether it is in the dcvs_options position (to the left of
a dcvs command) or in the command_options position (to the right of a
dcvs command).
There are only two situations where you may omit dcvs_command: `dcvs
-H' or `dcvs --help' elicits a list of available commands, and `dcvs
-v' or `dcvs --version' displays version information on dcvs itself.
DCVS OPTIONS
dcvs supports GNU style long options as well as short options (since
cvs release 1.6). Only a few long options are currently supported,
these are listed in brackets after the short options whose functions
they duplicate.
Use these options to control the overall dcvs program:
-H [ --help ]
Display usage information about the specified dcvs_command (but
do not actually execute the command). If you don't specify a
command name, `dcvs -H' displays a summary of all the commands
available.
-Q Causes the command to be really quiet; the command will generate
output only for serious problems.
-q Causes the command to be somewhat quiet; informational messages,
such as reports of recursion through subdirectories, are sup-
pressed.
-b bindir
Use bindir as the directory where RCS programs are located (CVS
1.9 and older). Overrides the setting of the RCSBIN environment
variable. This value should be specified as an absolute path-
name.
-d CVS_root_directory
Use CVS_root_directory as the root directory pathname of the
master source repository. Overrides the setting of the DCVSROOT
environment variable. This value should be specified as an
absolute pathname.
-e editor
Use editor to enter revision log information. Overrides the
setting of the CVSEDITOR, VISUAL, and EDITOR environment vari-
ables.
-f Do not read the dcvs startup file (~/.cvsrc).
-n Do not change any files. Attempt to execute the dcvs_command,
but only to issue reports; do not remove, update, or merge any
existing files, or create any new files.
-t Trace program execution; display messages showing the steps of
dcvs activity. Particularly useful with -n to explore the
potential impact of an unfamiliar command.
-r Makes new working files read-only. Same effect as if the CVS-
READ environment variable is set.
-R Turns on read-only repository mode. This allows one to check
out from a read-only repository, such as within an anoncvs
server, or from a CDROM repository. Same effect as if the CVS-
READONLYFS environment variable is set. Using -R can also con-
siderably speed up checkout's over NFS.
-v [ --version ]
Displays version and copyright information for dcvs.
-w Makes new working files read-write (default). Overrides the
setting of the CVSREAD environment variable.
-g Forces group-write perms on working files. This option is typi-
cally used when you have multiple users sharing a single checked
out source tree, allowing them to operate their shells with a
less dangerous umask. To use this feature, create a directory
to hold the checked-out source tree, set it to a private group,
and set up the directory such that files created under it
inherit the group id of the directory. This occurs automati-
cally with FreeBSD. With SysV you must typically set the SGID
bit on the directory. The users who are to share the checked
out tree must be placed in that group. Note that the sharing of
a single checked-out source tree is very different from giving
several users access to a common DCVS repository. Access to a
common DCVS repository already maintains shared group-write
perms and does not require this option.
To use the option transparently, simply place the line 'dcvs -g'
in your ~/.cvsrc file. Doing this is not recommended unless you
firewall all your source checkouts within a private group or
within a private mode 0700 directory.
-x Encrypt all communication between the client and the server. As
of this writing, this is only implemented when using a Kerberos
connection.
-z compression-level
When transferring files across the network use gzip with com-
pression level compression-level to compress and de-compress
data as it is transferred. Requires the presence of the GNU
gzip program in the current search path at both ends of the
link.
USAGE
Except when requesting general help with `dcvs -H', you must specify a
dcvs_command to dcvs to select a specific release control function to
perform. Each dcvs command accepts its own collection of options and
arguments. However, many options are available across several com-
mands. You can display a usage summary for each command by specifying
the -H option with the command.
DCVS STARTUP FILE
Normally, when DCVS starts up, it reads the .cvsrc file from the home
directory of the user reading it. This startup procedure can be turned
off with the -f flag.
The .cvsrc file lists DCVS commands with a list of arguments, one com-
mand per line. For example, the following line in .cvsrc:
diff -c
will mean that the `dcvs diff' command will always be passed the -c
option in addition to any other options that are specified in the com-
mand line (in this case it will have the effect of producing context
sensitive diffs for all executions of `dcvs diff' ).
Global options are specified using the dcvs keyword. For example, the
following:
dcvs -q
will mean that all `dcvs' commands will behave as though the -q global
option had been supplied.
COMMANDS NEW IN DCVS
These commands were introduced by DCVS -- they are an addition to the
known CVS commands. A complete description with examples can be found
under `Changesets and Snapshots' below.
catcset
Print out one or more changeset files, that were previously cre-
ated with mkcset (or commit -g )
catsnap
Print out one or more snapshot files, that were previously cre-
ated with mksnap (or tag -S )
lscset List existing changesets, that were previously created with mkc-
set (or commit -g )
lssnap List existing snapshots, that were previously created with
mksnap (or tag -S )
mkcset Create a new changeset, based on two revisions, snapshots or
dates.
mksnap Create a new snapshot, based on a revision, a date or the work-
ing copy.
CVS COMMANDS IN DCVS
CVS commands work exactly the same in DCVS. Additionally, the commands
checkout, commit, diff, tag and update offer command options for snap-
shots and changesets. It follows a complete list of commands that DCVS
inherited from CVS:
add Add a new file or directory to the repository, pending a `dcvs
commit' on the same file. Can only be done from within sources
created by a previous `dcvs checkout' invocation. Use `dcvs
import' to place whole new hierarchies of sources under dcvs
control. (Does not directly affect repository; changes working
directory.)
admin Execute control functions on the source repository. (Changes
repository directly; uses working directory without changing
it.)
checkout
Make a working directory of source files for editing. (Creates
or changes working directory.)
commit Apply to the source repository changes, additions, and deletions
from your working directory. (Changes repository.)
diff Show differences between files in working directory and source
repository, or between two revisions in source repository.
(Does not change either repository or working directory.)
export Prepare copies of a set of source files for shipment off site.
Differs from `dcvs checkout' in that no dcvs administrative
directories are created (and therefore `dcvs commit' cannot be
executed from a directory prepared with `dcvs export'), and a
symbolic tag must be specified. (Does not change repository;
creates directory similar to working directories).
history
Show reports on dcvs commands that you or others have executed
on a particular file or directory in the source repository.
(Does not change repository or working directory.) History logs
are kept only if enabled by creation of the `$DCVSROOT/DCVS-
ROOT/history' file; see dcvs(5).
import Incorporate a set of updates from off-site into the source
repository, as a ``vendor branch''. (Changes repository.)
init Initialize a repository by adding the DCVSROOT subdirectory and
some default control files. You must use this command or ini-
tialize the repository in some other way before you can use it.
log Display log information. (Does not change repository or working
directory.)
rdiff Prepare a collection of diffs as a patch file between two
releases in the repository. (Does not change repository or
working directory.)
release
Cancel a `dcvs checkout', abandoning any changes. (Can delete
working directory; no effect on repository.)
remove Remove files from the source repository, pending a `dcvs commit'
on the same files. (Does not directly affect repository;
changes working directory.)
rtag Explicitly specify a symbolic tag for particular revisions of
files in the source repository. See also `dcvs tag'. (Changes
repository directly; does not require or affect working direc-
tory.)
status Show current status of files: latest version, version in working
directory, whether working version has been edited and, option-
ally, symbolic tags in the RCS file. (Does not change reposi-
tory or working directory.)
tag Specify a symbolic tag for files in the repository. By default,
tags the revisions that were last synchronized with your working
directory. (Changes repository directly; uses working direc-
tory without changing it.)
update Bring your working directory up to date with changes from the
repository. Merges are performed automatically when possible; a
warning is issued if manual resolution is required for conflict-
ing changes. (Changes working directory; does not change repos-
itory.)
COMMON COMMAND OPTIONS
This section describes the command_options that are available across
several dcvs commands. Not all commands support all of these options;
each option is only supported for commands where it makes sense. How-
ever, when a command has one of these options you can count on the same
meaning for the option as in other commands. (Other command options,
which are listed with the individual commands, may have different mean-
ings from one dcvs command to another.) Warning: the history command
is an exception; it supports many options that conflict even with these
standard options.
-D date_spec
Use the most recent revision no later than date_spec (a single
argument, date description specifying a date in the past). A
wide variety of date formats are supported, in particular ISO
("1972-09-24 20:05") or Internet ("24 Sep 1972 20:05"). The
date_spec is interpreted as being in the local timezone, unless
a specific timezone is specified. The specification is
``sticky'' when you use it to make a private copy of a source
file; that is, when you get a working file using -D, dcvs
records the date you specified, so that further updates in the
same directory will use the same date (unless you explicitly
override it; see the description of the update command). -D is
available with the checkout, diff, history, export, rdiff, rtag,
and update commands. Examples of valid date specifications
include:
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
yesterday
a fortnight ago
3/31/92 10:00:07 PST
January 23, 1987 10:05pm
22:00 GMT
-f When you specify a particular date or tag to dcvs commands, they
normally ignore files that do not contain the tag (or did not
exist on the date) that you specified. Use the -f option if you
want files retrieved even when there is no match for the tag or
date. (The most recent version is used in this situation.) -f
is available with these commands: checkout, export, rdiff, rtag,
and update.
-g changeset
Either use the given name to create a new changeset (commit), or
retrieve revision numbers from the given existing changeset file
(diff, update).
-k kflag
Alter the default processing of keywords. The -k option is
available with the add, checkout, diff, export, rdiff, and
update commands. Your kflag specification is ``sticky'' when
you use it to create a private copy of a source file; that is,
when you use this option with the checkout or update commands,
dcvs associates your selected kflag with the file, and continues
to use it with future update commands on the same file until you
specify otherwise.
Some of the more useful kflags are -ko and -kb (for binary
files), and -kv which is useful for an export where you wish to
retain keyword information after an import at some other site.
-l Local; run only in current working directory, rather than recur-
ring through subdirectories. Available with the following com-
mands: checkout, commit, diff, export, remove, rdiff, rtag, sta-
tus, tag, and update.
-n Do not run any checkout/commit/tag/update program. (A program
can be specified to run on each of these activities, in the mod-
ules database; this option bypasses it.) Available with the
checkout, commit, export, and rtag commands. Warning: this is
not the same as the overall `dcvs -n' option, which you can
specify to the left of a dcvs command!
-P Prune (remove) directories that are empty after being updated,
on checkout, or update. Normally, an empty directory (one that
is void of revision-controlled files) is left alone. Specifying
-P will cause these directories to be silently removed from your
checked-out sources. This does not remove the directory from
the repository, only from your checked out copy. Note that this
option is implied by the -r or -D options of checkout and
export.
-T Create/Update DCVS/Template by copying it from the (local)
repository. This option is useful for developers maintaining a
local dcvs repository but commiting to a remote repository. By
maintaining DCVS/Template the remote commits will still be able
to bring up the proper template in the commit editor session.
Available with the checkout and update commands.
-p Pipe the files retrieved from the repository to standard output,
rather than writing them in the current directory. Available
with the checkout and update commands.
-r tag Use the revision specified by the tag argument instead of the
default ``head'' revision. As well as arbitrary tags defined
with the tag or rtag command, two special tags are always avail-
able: `HEAD' refers to the most recent version available in the
repository, and `BASE' refers to the revision you last checked
out into the current working directory.
The tag specification is ``sticky'' when you use this option
with `dcvs checkout' or `dcvs update' to make your own copy of a
file: dcvs remembers the tag and continues to use it on future
update commands, until you specify otherwise. tag can be either
a symbolic or numeric tag. Specifying the -q global option
along with the -r command option is often useful, to suppress
the warning messages when the RCS file does not contain the
specified tag. -r is available with the checkout, commit, diff,
history, export, rdiff, rtag, and update commands. Warning:
this is not the same as the overall `dcvs -r' option, which you
can specify to the left of a dcvs command!
-S snapshot
Either create a new snapshot with the given name (tag), or use
the revision numbers from the given existing snapshot (checkout,
diff, update).
DCVS COMMANDS
Here (finally) are details on all the dcvs commands and the options
each accepts. The summary lines at the top of each command's descrip-
tion highlight three kinds of things:
Command Options and Arguments
Special options are described in detail below; common command
options may appear only in the summary line.
Working Directory, or Repository?
Some dcvs commands require a working directory to operate;
some require a repository. Also, some commands change the
repository, some change the working directory, and some
change nothing.
Synonyms
Many commands have synonyms, which you may find easier to
remember (or type) than the principal name.
add [-k kflag] [-m 'message'] files...
Requires: repository, working directory.
Changes: working directory.
Synonym: new
Use the add command to create a new file or directory in the
source repository. The files or directories specified with add
must already exist in the current directory (which must have
been created with the checkout command). To add a whole new
directory hierarchy to the source repository (for example, files
received from a third-party vendor), use the `dcvs import' com-
mand instead.
If the argument to `dcvs add' refers to an immediate sub-direc-
tory, the directory is created at the correct place in the
source repository, and the necessary dcvs administration files
are created in your working directory. If the directory already
exists in the source repository, `dcvs add' still creates the
administration files in your version of the directory. This
allows you to use `dcvs add' to add a particular directory to
your private sources even if someone else created that directory
after your checkout of the sources. You can do the following:
example% mkdir new_directory
example% dcvs add new_directory
example% dcvs update new_directory
An alternate approach using `dcvs update' might be:
example% dcvs update -d new_directory
(To add any available new directories to your working directory,
it's probably simpler to use `dcvs checkout' or `dcvs update
-d'.)
The added files are not placed in the source repository until
you use `dcvs commit' to make the change permanent. Doing a
`dcvs add' on a file that was removed with the `dcvs remove'
command will resurrect the file, if no `dcvs commit' command
intervened.
You will have the opportunity to specify a logging message, as
usual, when you use `dcvs commit' to make the new file perma-
nent. If you'd like to have another logging message associated
with just creation of the file (for example, to describe the
file's purpose), you can specify it with the `-m message' option
to the add command.
The `-k kflag' option specifies the default way that this file
will be checked out. The `kflag' argument is stored in the RCS
file and can be changed with `dcvs admin'. Specifying `-ko' is
useful for checking in binaries that shouldn't have keywords
expanded.
admin [rcs-options] files...
Requires: repository, working directory.
Changes: repository.
Synonym: rcs
This is the dcvs interface to assorted administrative facili-
ties, similar to rcs(1). This command works recursively, so
extreme care should be used.
catcset [options] name_or_pattern...
Requires: repository.
Changes: nothing.
Synonyms: cc
Print out one or more existing changesets.
For a complete description and examples, see `Changesets and
Snapshots' below.
catsnap [options] name_or_pattern...
Requires: repository.
Changes: nothing.
Synonyms: cs
Print out one or more existing snapshots.
For a complete description and examples, see `Changesets and
Snapshots' below.
checkout [options] modules...
Requires: repository.
Changes: working directory.
Synonyms: co, get
Make a working directory containing copies of the source files
specified by modules. You must execute `dcvs checkout' before
using most of the other dcvs commands, since most of them oper-
ate on your working directory.
modules are either symbolic names (themselves defined as the
module `modules' in the source repository; see dcvs(5)) for some
collection of source directories and files, or paths to directo-
ries or files in the repository.
Depending on the modules you specify, checkout may recursively
create directories and populate them with the appropriate source
files. You can then edit these source files at any time
(regardless of whether other software developers are editing
their own copies of the sources); update them to include new
changes applied by others to the source repository; or commit
your work as a permanent change to the repository.
Note that checkout is used to create directories. The top-level
directory created is always added to the directory where check-
out is invoked, and usually has the same name as the specified
module. In the case of a module alias, the created sub-direc-
tory may have a different name, but you can be sure that it will
be a sub-directory, and that checkout will show the relative
path leading to each file as it is extracted into your private
work area (unless you specify the -Q global option).
Running `dcvs checkout' on a directory that was already built by
a prior checkout is also permitted, and has the same effect as
specifying the -d option to the update command described below.
The options permitted with `dcvs checkout' include the standard
command options -P, -f, -k kflag , -l, -n, -p, -r tag, -S snap-
shot, and -D date.
Use a command of the form `dcvs checkout -S snapshot' to check-
out the file revisions as given in an existing snapshot. This is
similar to `dcvs checkout -r tag'.
For a complete description and examples, see `Changesets and
Snapshots' below.
In addition to those, you can use these special command options
with checkout:
Use the -A option to reset any sticky tags, dates, or -k
options. (If you get a working file using one of the -r, -D, or
-k options, dcvs remembers the corresponding tag, date, or kflag
and continues using it on future updates; use the -A option to
make dcvs forget these specifications, and retrieve the ``head''
version of the file).
The -j branch option merges the changes made between the result-
ing revision and the revision that it is based on (e.g., if the
tag refers to a branch, dcvs will merge all changes made in that
branch into your working file).
With two -j options, dcvs will merge in the changes between the
two respective revisions. This can be used to ``remove'' a cer-
tain delta from your working file.
In addition, each -j option can contain an optional date speci-
fication which, when used with branches, can limit the chosen
revision to one within a specific date. An optional date is
specified by adding a colon (:) to the tag. An example might be
what `dcvs import' tells you to do when you have just imported
sources that have conflicts with local changes:
example% dcvs checkout -jTAG:yesterday -jTAG module
Use the -N option with `-d dir' to avoid shortening module paths
in your working directory. (Normally, dcvs shortens paths as
much as possible when you specify an explicit target directory.)
Use the -c option to copy the module file, sorted, to the stan-
dard output, instead of creating or modifying any files or
directories in your working directory.
Use the -d dir option to create a directory called dir for the
working files, instead of using the module name. Unless you
also use -N, the paths created under dir will be as short as
possible.
Use the -s option to display per-module status information
stored with the -s option within the modules file.
commit [-lnR] [-m 'log_message' | -F file] [-r revision] [-g
new_changeset] [files...]
Requires: working directory, repository.
Changes: repository.
Synonym: ci
Use `dcvs commit' when you want to incorporate changes from your
working source files into the general source repository.
If you don't specify particular files to commit, all of the
files in your working current directory are examined. commit is
careful to change in the repository only those files that you
have really changed. By default (or if you explicitly specify
the -R option), files in subdirectories are also examined and
committed if they have changed; you can use the -l option to
limit commit to the current directory only. Sometimes you may
want to force a file to be committed even though it is
unchanged; this is achieved with the -f flag, which also has the
effect of disabling recursion (you can turn it back on with -R
of course).
commit verifies that the selected files are up to date with the
current revisions in the source repository; it will notify you,
and exit without committing, if any of the specified files must
be made current first with `dcvs update'. commit does not call
the update command for you, but rather leaves that for you to do
when the time is right.
When all is well, an editor is invoked to allow you to enter a
log message that will be written to one or more logging programs
and placed in the source repository file. You can instead spec-
ify the log message on the command line with the -m option, thus
suppressing the editor invocation, or use the -F option to spec-
ify that the argument file contains the log message.
The -r option can be used to commit to a particular symbolic or
numeric revision. For example, to bring all your files up to
the revision ``3.0'' (including those that haven't changed), you
might do:
example% dcvs commit -r3.0
The -g new_changeset option creates a new changeset that
reflects all changes made during this commit. For a complete
description and examples, see `Changesets and Snapshots' below.
dcvs will only allow you to commit to a revision that is on the
main trunk (a revision with a single dot). However, you can
also commit to a branch revision (one that has an even number of
dots) with the -r option. To create a branch revision, one typ-
ically use the -b option of the rtag or tag commands. Then,
either checkout or update can be used to base your sources on
the newly created branch. >From that point on, all commit
changes made within these working sources will be automatically
added to a branch revision, thereby not perturbing main-line
development in any way. For example, if you had to create a
patch to the 1.2 version of the product, even though the 2.0
version is already under development, you might do:
example% dcvs rtag -b -rFCS1_2 FCS1_2_Patch product_module
example% dcvs checkout -rFCS1_2_Patch product_module
example% cd product_module
[[ hack away ]]
example% dcvs commit
Say you have been working on some extremely experimental soft-
ware, based on whatever revision you happened to checkout last
week. If others in your group would like to work on this soft-
ware with you, but without disturbing main-line development, you
could commit your change to a new branch. Others can then
checkout your experimental stuff and utilize the full benefit of
dcvs conflict resolution. The scenario might look like:
example% dcvs tag -b EXPR1
example% dcvs update -rEXPR1
[[ hack away ]]
example% dcvs commit
Others would simply do `dcvs checkout -rEXPR1 whatever_module'
to work with you on the experimental change.
diff [-kl] [format_options] [ [[-r rev1 | -S snapshot1 | -D date1 | -j
rev1:date1] [-r rev2 | -S snapshot2 | -D date2 | -j rev2:date2]] | -g
changeset] [files...]
Requires: working directory, repository.
Changes: nothing.
You can compare your working files with revisions in the source
repository, with the `dcvs diff' command. If you don't specify
a particular revision, your files are compared with the revi-
sions they were based on. You can also use the standard dcvs
command option -r to specify a particular revision to compare
your files with. Finally, if you use -r twice, you can see dif-
ferences between two revisions in the repository. You can also
specify -S options to diff against an existing snapshot, -D
options to diff against a revision (on the head branch) in the
past, and you can also specify -j options to diff against a
revision relative to a branch tag in the past. The -r , -S , -D
and -j options can be mixed together with at most two options
ever specified.
Instead of -r , -S , -D and -j options, a single -g changeset
option may be specified to diff between the two columns of a
changeset.
For a complete description and examples, see `Changesets and
Snapshots' below.
See `dcvs --help diff' for a list of supported format_options.
If you don't specify any files, diff will display differences
for all those files in the current directory (and its subdirec-
tories, unless you use the standard option -l) that differ from
the corresponding revision in the source repository (i.e. files
that you have changed), or that differ from the revision speci-
fied.
export [-flNnQq] -r rev|-D date [-d dir] [-k kflag] module...
Requires: repository.
Changes: current directory.
This command is a variant of `dcvs checkout'; use it when you
want a copy of the source for module without the dcvs adminis-
trative directories. For example, you might use `dcvs export'
to prepare source for shipment off-site. This command requires
that you specify a date or tag (with -D or -r), so that you can
count on reproducing the source you ship to others.
The only non-standard options are `-d dir' (write the source
into directory dir) and `-N' (don't shorten module paths).
These have the same meanings as the same options in `dcvs check-
out'.
The -kv option is useful when export is used. This causes any
keywords to be expanded such that an import done at some other
site will not lose the keyword revision information. Other
kflags may be used with `dcvs export' and are described in
co(1).
history [-report] [-flags] [-options args] [files...]
Requires: the file `$DCVSROOT/DCVSROOT/history'
Changes: nothing.
dcvs keeps a history file that tracks each use of the checkout,
commit, rtag, update, and release commands. You can use `dcvs
history' to display this information in various formats.
Warning: `dcvs history' uses `-f', `-l', `-n', and `-p' in ways
that conflict with the descriptions in COMMON COMMAND OPTIONS.
Several options (shown above as -report) control what kind of
report is generated:
-c Report on each time commit was used (i.e., each time the
repository was modified).
-m module
Report on a particular module. (You can meaningfully use -m
more than once on the command line.)
-o Report on checked-out modules.
-T Report on all tags.
-x type
Extract a particular set of record types X from the dcvs his-
tory. The types are indicated by single letters, which you
may specify in combination. Certain commands have a single
record type: checkout (type `O'), release (type `F'), and
rtag (type `T'). One of four record types may result from an
update: `W', when the working copy of a file is deleted dur-
ing update (because it was gone from the repository); `U',
when a working file was copied from the repository; `G', when
a merge was necessary and it succeeded; and 'C', when a merge
was necessary but collisions were detected (requiring manual
merging). Finally, one of three record types results from
commit: `M', when a file was modified; `A', when a file is
first added; and `R', when a file is removed.
-e Everything (all record types); equivalent to specifying
`-xMACFROGWUT'.
-z zone
Use time zone zone when outputting history records. The zone
name LT stands for local time; numeric offsets stand for
hours and minutes ahead of UTC. For example, +0530 stands
for 5 hours and 30 minutes ahead of (i.e. east of) UTC.
The options shown as -flags constrain the report without requiring
option arguments:
-a Show data for all users (the default is to show data only for
the user executing `dcvs history').
-l Show last modification only.
-w Show only the records for modifications done from the same
working directory where `dcvs history' is executing.
The options shown as -options args constrain the report based on
an argument:
-b str
Show data back to a record containing the string str in
either the module name, the file name, or the repository
path.
-D date
Show data since date.
-p repository
Show data for a particular source repository (you can specify
several -p options on the same command line).
-r rev
Show records referring to revisions since the revision or tag
named rev appears in individual RCS files. Each RCS file is
searched for the revision or tag.
-t tag
Show records since tag tag was last added to the history
file. This differs from the -r flag above in that it reads
only the history file, not the RCS files, and is much faster.
-u name
Show records for user name.
import [-options] repository vendortag releasetag...
Requires: Repository, source distribution directory.
Changes: repository.
Use `dcvs import' to incorporate an entire source distribution
from an outside source (e.g., a source vendor) into your source
repository directory. You can use this command both for initial
creation of a repository, and for wholesale updates to the mod-
ule form the outside source.
The repository argument gives a directory name (or a path to a
directory) under the DCVS root directory for repositories; if
the directory did not exist, import creates it.
When you use import for updates to source that has been modified
in your source repository (since a prior import), it will notify
you of any files that conflict in the two branches of develop-
ment; use `dcvs checkout -j' to reconcile the differences, as
import instructs you to do.
By default, certain file names are ignored during `dcvs import':
names associated with DCVS administration, or with other common
source control systems; common names for patch files, object
files, archive files, and editor backup files; and other names
that are usually artifacts of assorted utilities. For an up to
date list of ignored file names, see the Cederqvist manual (as
described in the SEE ALSO section of this manpage).
The outside source is saved in a first-level branch, by default
`1.1.1'. Updates are leaves of this branch; for example, files
from the first imported collection of source will be revision
`1.1.1.1', then files from the first imported update will be
revision `1.1.1.2', and so on.
At least three arguments are required. repository is needed to
identify the collection of source. vendortag is a tag for the
entire branch (e.g., for `1.1.1'). You must also specify at
least one releasetag to identify the files at the leaves created
each time you execute `dcvs import'.
One of the standard dcvs command options is available: -m mes-
sage. If you do not specify a logging message with -m, your
editor is invoked (as with commit) to allow you to enter one.
There are three additional special options.
Use `-d' to specify that each file's time of last modification
should be used for the checkin date and time.
Use `-b branch' to specify a first-level branch other than
`1.1.1'.
Use `-I name' to specify file names that should be ignored dur-
ing import. You can use this option repeatedly. To avoid
ignoring any files at all (even those ignored by default), spec-
ify `-I !'.
log [-l] rlog-options [files...]
Requires: repository, working directory.
Changes: nothing.
Synonym: rlog
Display log information for files. Among the more useful
options are -h to display only the header (including tag defini-
tions, but omitting most of the full log); -r to select logs on
particular revisions or ranges of revisions; and -d to select
particular dates or date ranges. See rlog(1) for full explana-
tions. This command is recursive by default, unless the -l
option is specified.
lscset [-lr] [name_or_pattern...]
Requires: repository.
Changes: nothing.
List existing changesets.
For a complete description and examples, see `Changesets and
Snapshots' below.
lssnap [-lr] [name_or_pattern...]
Requires: repository.
Changes: nothing.
List existing snapshots.
For a complete description and examples, see `Changesets and
Snapshots' below.
mkcset [options] new_changeset
Requires: repository, working directory.
Changes: repository.
Creates a new changeset.
For a complete description and examples, see `Changesets and
Snapshots' below.
mksnap [options] new_snapshot
Requires: repository, working directory.
Changes: repository.
Creates a new snapshot.
For a complete description and examples, see `Changesets and
Snapshots' below.
rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
Requires: repository.
Changes: nothing.
Synonym: patch
Builds a Larry Wall format patch(1) file between two releases,
that can be fed directly into the patch program to bring an old
release up-to-date with the new release. (This is one of the
few dcvs commands that operates directly from the repository,
and doesn't require a prior checkout.) The diff output is sent
to the standard output device. You can specify (using the stan-
dard -r and -D options) any combination of one or two revisions
or dates. If only one revision or date is specified, the patch
file reflects differences between that revision or date and the
current ``head'' revisions in the RCS file.
Note that if the software release affected is contained in more
than one directory, then it may be necessary to specify the -p
option to the patch command when patching the old sources, so
that patch is able to find the files that are located in other
directories.
The standard option flags -f, and -l are available with this
command. There are also several special option flags:
If you use the -s option, no patch output is produced. Instead,
a summary of the changed or added files between the two releases
is sent to the standard output device. This is useful for find-
ing out, for example, which files have changed between two dates
or revisions.
If you use the -t option, a diff of the top two revisions is
sent to the standard output device. This is most useful for
seeing what the last change to a file was.
If you use the -u option, the patch output uses the newer ``uni-
diff'' format for context diffs.
You can use -c to explicitly specify the `diff -c' form of con-
text diffs (which is the default), if you like.
release [-dQq] modules...
Requires: Working directory.
Changes: Working directory, history log.
This command is meant to safely cancel the effect of `dcvs
checkout'. Since dcvs doesn't lock files, it isn't strictly
necessary to use this command. You can always simply delete
your working directory, if you like; but you risk losing changes
you may have forgotten, and you leave no trace in the dcvs his-
tory file that you've abandoned your checkout.
Use `dcvs release' to avoid these problems. This command checks
that no un-committed changes are present; that you are executing
it from immediately above, or inside, a dcvs working directory;
and that the repository recorded for your files is the same as
the repository defined in the module database.
If all these conditions are true, `dcvs release' leaves a record
of its execution (attesting to your intentionally abandoning
your checkout) in the dcvs history log.
You can use the -d flag to request that your working copies of
the source files be deleted if the release succeeds.
remove [-lR] [files...]
Requires: Working directory.
Changes: Working directory.
Synonyms: rm, delete
Use this command to declare that you wish to remove files from
the source repository. Like most dcvs commands, `dcvs remove'
works on files in your working directory, not directly on the
repository. As a safeguard, it also requires that you first
erase the specified files from your working directory.
The files are not actually removed until you apply your changes
to the repository with commit; at that point, the corresponding
RCS files in the source repository are moved into the `Attic'
directory (also within the source repository).
This command is recursive by default, scheduling all physically
removed files that it finds for removal by the next commit. Use
the -l option to avoid this recursion, or just specify that
actual files that you wish remove to consider.
rtag [-falnRQq] [-b] [-d] [-r tag | -D date] symbolic_tag modules...
Requires: repository.
Changes: repository.
Synonym: rfreeze
You can use this command to assign symbolic tags to particular,
explicitly specified source versions in the repository. `dcvs
rtag' works directly on the repository contents (and requires no
prior checkout). Use `dcvs tag' instead, to base the selection
of versions to tag on the contents of your working directory.
In general, tags (often the symbolic names of software distribu-
tions) should not be removed, but the -d option is available as
a means to remove completely obsolete symbolic names if neces-
sary (as might be the case for an Alpha release, say).
`dcvs rtag' will not move a tag that already exists. With the
-F option, however, `dcvs rtag' will re-locate any instance of
symbolic_tag that already exists on that file to the new reposi-
tory versions. Without the -F option, attempting to use `dcvs
rtag' to apply a tag that already exists on that file will pro-
duce an error message.
The -b option makes the tag a ``branch'' tag, allowing concur-
rent, isolated development. This is most useful for creating a
patch to a previously released software distribution.
You can use the standard -r and -D options to tag only those
files that already contain a certain tag. This method would be
used to rename a tag: tag only the files identified by the old
tag, then delete the old tag, leaving the new tag on exactly the
same files as the old tag.
rtag executes recursively by default, tagging all subdirectories
of modules you specify in the argument. You can restrict its
operation to top-level directories with the standard -l option;
or you can explicitly request recursion with -R.
The modules database can specify a program to execute whenever a
tag is specified; a typical use is to send electronic mail to a
group of interested parties. If you want to bypass that pro-
gram, use the standard -n option.
Use the -a option to have rtag look in the `Attic' for removed
files that contain the specified tag. The tag is removed from
these files, which makes it convenient to re-use a symbolic tag
as development continues (and files get removed from the up-com-
ing distribution).
status [-lRqQ] [-v] [files...]
Requires: working directory, repository.
Changes: nothing.
Display a brief report on the current status of files with
respect to the source repository, including any ``sticky'' tags,
dates, or -k options. (``Sticky'' options will restrict how
`dcvs update' operates until you reset them; see the description
of `dcvs update -A...'.)
You can also use this command to anticipate the potential impact
of a `dcvs update' on your working source directory. If you do
not specify any files explicitly, reports are shown for all
files that dcvs has placed in your working directory. You can
limit the scope of this search to the current directory itself
(not its subdirectories) with the standard -l option flag; or
you can explicitly request recursive status reports with the -R
option.
The -v option causes the symbolic tags for the RCS file to be
displayed as well.
tag [-lQqR] [-F] [-b] [-d]
[-r tag | -D date | - S snapshot] [-f] symbolic_tag [files...]
Requires: working directory, repository.
Changes: repository.
Synonym: freeze
Use this command to assign symbolic tags to the nearest reposi-
tory versions to your working sources. The tags are applied
immediately to the repository, as with rtag.
One potentially surprising aspect of the fact that dcvs tag
operates on the repository is that you are tagging the checked-
in revisions, which may differ from locally modified files in
your working directory. If you want to avoid doing this by mis-
take, specify the -c option to dcvs tag. If there are any
locally modified files, DCVS will abort with an error before it
tags any files.
One use for tags is to record a state of the current sources
when the software freeze date of a project arrives. As bugs are
fixed after the freeze date, only those changed sources that are
to be part of the release need be re-tagged.
The symbolic tags are meant to permanently record which revi-
sions of which files were used in creating a software distribu-
tion. The checkout, export and update commands allow you to
extract an exact copy of a tagged release at any time in the
future, regardless of whether files have been changed, added, or
removed since the release was tagged.
You can use the standard -r and -D options to tag only those
files that already contain a certain tag. This method would be
used to rename a tag: tag only the files identified by the old
tag, then delete the old tag, leaving the new tag on exactly the
same files as the old tag.
In contrast, the -S option here creates a new snapshot that
shows the same revision numbers as the tag created with this
command. Thus, a tag and a corresponding snapshot are being cre-
ated at the same time.
Specifying the -f flag in addition to the -r or -D flags will
tag those files named on the command line even if they do not
contain the old tag or did not exist on the specified date.
By default (without a -r or -D flag) the versions to be tagged
are supplied implicitly by the dcvs records of your working
files' history rather than applied explicitly.
If you use `dcvs tag -d symbolic_tag...', the symbolic tag you
specify is deleted instead of being added. Warning: Be very
certain of your ground before you delete a tag; doing this
effectively discards some historical information, which may
later turn out to have been valuable.
`dcvs tag' will not move a tag that already exists. With the -F
option, however, `dcvs tag' will re-locate any instance of sym-
bolic_tag that already exists on that file to the new repository
versions. Without the -F option, attempting to use `dcvs tag'
to apply a tag that already exists on that file will produce an
error message.
The -b option makes the tag a ``branch'' tag, allowing concur-
rent, isolated development. This is most useful for creating a
patch to a previously released software distribution.
Normally, tag executes recursively through subdirectories; you
can prevent this by using the standard -l option, or specify the
recursion explicitly by using -R.
update [-ACdflPpQqR] [-d] [-r tag|-D date] files...
Requires: repository, working directory.
Changes: working directory.
After you've run checkout to create your private copy of source
from the common repository, other developers will continue
changing the central source. From time to time, when it is con-
venient in your development process, you can use the update com-
mand from within your working directory to reconcile your work
with any revisions applied to the source repository since your
last checkout or update.
update keeps you informed of its progress by printing a line for
each file, prefaced with one of the characters `U P A R M C ?'
to indicate the status of the file:
U file The file was brought up to date with respect to the reposi-
tory. This is done for any file that exists in the reposi-
tory but not in your source, and for files that you haven't
changed but are not the most recent versions available in the
repository.
P file Like U, but the DCVS server sends a patch instead of an
entire file. This accomplishes the same thing as U using
less bandwidth.
A file The file has been added to your private copy of the sources,
and will be added to the source repository when you run `dcvs
commit' on the file. This is a reminder to you that the file
needs to be committed.
R file The file has been removed from your private copy of the
sources, and will be removed from the source repository when
you run `dcvs commit' on the file. This is a reminder to you
that the file needs to be committed.
M file The file is modified in your working directory. `M' can
indicate one of two states for a file you're working on:
either there were no modifications to the same file in the
repository, so that your file remains as you last saw it; or
there were modifications in the repository as well as in your
copy, but they were merged successfully, without conflict, in
your working directory.
C file A conflict was detected while trying to merge your changes to
file with changes from the source repository. file (the copy
in your working directory) is now the result of merging the
two versions; an unmodified copy of your file is also in your
working directory, with the name `.#file.version', where ver-
sion is the revision that your modified file started from.
(Note that some systems automatically purge files that begin
with `.#' if they have not been accessed for a few days. If
you intend to keep a copy of your original file, it is a very
good idea to rename it.)
? file file is in your working directory, but does not correspond to
anything in the source repository, and is not in the list of
files for dcvs to ignore (see the description of the -I
option).
Use the -A option to reset any sticky tags, dates, or -k options.
(If you get a working copy of a file by using one of the -r, -D,
or -k options, dcvs remembers the corresponding tag, date, or
kflag and continues using it on future updates; use the -A option
to make dcvs forget these specifications, and retrieve the
``head'' version of the file).
The -jbranch option merges the changes made between the resulting
revision and the revision that it is based on (e.g., if the tag
refers to a branch, dcvs will merge all changes made in that
branch into your working file).
With two -j options, dcvs will merge in the changes between the
two respective revisions. This can be used to ``remove'' a cer-
tain delta from your working file. E.g., If the file foo.c is
based on revision 1.6 and I want to remove the changes made
between 1.3 and 1.5, I might do:
example% dcvs update -j1.5 -j1.3 foo.c # note the order...
In addition, each -j option can contain on optional date specifi-
cation which, when used with branches, can limit the chosen revi-
sion to one within a specific date. An optional date is specified
by adding a colon (:) to the tag.
-jSymbolic_Tag:Date_Specifier
Use the -d option to create any directories that exist in the
repository if they're missing from the working directory. (Nor-
mally, update acts only on directories and files that were already
enrolled in your working directory.) This is useful for updating
directories that were created in the repository since the initial
checkout; but it has an unfortunate side effect. If you deliber-
ately avoided certain directories in the repository when you cre-
ated your working directory (either through use of a module name
or by listing explicitly the files and directories you wanted on
the command line), then updating with -d will create those direc-
tories, which may not be what you want.
Use -I name to ignore files whose names match name (in your work-
ing directory) during the update. You can specify -I more than
once on the command line to specify several files to ignore. By
default, update ignores files whose names match certain patterns;
for an up to date list of ignored file names, see the Cederqvist
manual (as described in the SEE ALSO section of this manpage).
Use `-I !' to avoid ignoring any files at all.
Use the `-C' option to overwrite locally modified files with clean
copies from the repository (the modified file is saved in
`.#file.revision', however).
The standard dcvs command options -f, -k, -l, -P, -p, and -r are
also available with update.
DISTRIBUTED REPOSITORY
DCVS has the capability to distribute the repository across multiple
servers, which can synchronize automatically. The synchronization is
performed by DCVSup, an extended version of the well-known and effi-
cient CVSup, developed by John D. Polstra. The combination of DCVS
repository, DCVSup server, and DCVS server program (extended CVS
server) is called DCVS server or simply server subsequently.
A developer can check out all development lines of all servers from any
single DCVS server. In DCVS, all operations that do not modify the
repository (diff, patch, log, annotate etc.) work just like in CVS, but
can be much faster by using the local DCVS repository.
Every DCVS server gets assigned a set of development lines (DCVS
branches) for which it is responsible. Modifications to a certain line
of development may only be checked-in at the server responsible for
this branch. The separation of modifications by lines of development
makes it possible to automatically transfer and distribute changes in
the DCVS network. Repository synchronization is performed on the level
of single RCS delta elements by the dcvsupd (extended cvsupd) pro-
cesses.
It is still possible to commit changes for a development line your
local DCVS server is not responsible for, in two ways: by committing to
the responsible server directly over the internet, or, preferrably, by
creating a new development line (branch) on the local server. The local
DCVS server will automatically be responsible for any such newly cre-
ated branch. If these changes need to be applied to the original
branch, a developer on the reponsible DCVS server needs to perform a
merge operation.
Generally it will be easiest to follow a change set-oriented style of
development model, where developers produce small sets of changes
related to a feature or a defect, that can then be applied by others.
Deltas on a certain line of development can be identified as belonging
to a certain DCVS server: CVS uses so-called magic branch numbers,
which are revision numbers with an even number of elements and the num-
ber 0 at the second-last position. Let's take 1.32.0.4 as an example,
the branch number being 4. Deltas belonging to this line of development
will be labeled 1.34.4.1, 1.34.4.2, 1.34.4.3, etc., the branch number
replacing the zero. To separate lines of development on different
servers, DCVS ensures that the branch numbers are different for every
server. This applies to the creation of new branches (tags) as well as
the creation of new RCS deltas.
In particular, DCVS assigns a unique range of branch numbers to every
(server, collection) pair. All ranges for all servers and collections
must be mutually exclusive. The definitions for servers, collections,
and ranges are read from a single configuration file, which must be
kept identical on all DCVS servers. Each DCVS server obeys the respon-
sibilities spelled out in this file.
Another problem arising when working with distributed repositories is
the actual name of a configuration (tag). Alike a branch number, it
must be uniquely assignable to exactly one DCVS server. DCVS solves
this problem in a very simple fashion by extending all tags with a
server-specific suffix, like _at_dcvs_mydomain_org, so that no con-
flicts in the tag name space may arise. This suffix is appended auto-
matically for most client operations, so that ease of use is not
affected.
It follows a sample configuration file for illustrating the distribu-
tion of responsibilities.
A complete description of the DCVS configuration file is given in
dcvs_config (5). There is more documentation, for example the
DCVS_IN_30_MINUTES how-to, in the dcvs package as well as on the web
(http://www.elegosoft.de).
# A sample DCVS configuration with several ranges, servers, and collections
# We start by defining several ranges, each consisting of 10000 possible
# revision branch numbers. You usually do not need to change this;
# only add new ranges when you need them for new servers.
range base 0..9999
range r1 10000..19999
range r2 20000..29999
range r3 30000..39999
range r4 40000..49999
# Our simple DCVS network consists of two servers:
server willow willow.tree.org 44555
server ash ash.forest.net 44555
# We also have two client computers at server willow and one at server ash:
client ws1 ws1.tree.org willow
client ws2 ws2.tree.org willow
client ws11 ws11.forest.net ash
# We distribute one repository, currently consisting of 4 different
# collections.
# The main trunk and vendor branch of collections c1, c3, and c4 is on
# willow, ash is responsible for the trunk and import of collection
# c2. Ash generally uses range r1 for its other collections, willow
# uses range r2.
collection c1 /repos/dcvs c1
willow:base
ash:r1
end
collection c2 /repos/dcvs libs/io
willow:r2
ash:base
end
collection c3 /repos/dcvs libs/text
willow:base
ash:r1
end
collection c4 /repos/dcvs libs/list
willow:base
ash:r1
end
CHANGESETS AND SNAPSHOTS
A snapshot is a single, frozen (bound) configuration, in basic idea
similar to tags, while having some more desirable traits than tags.
A changeset contains the difference between two configurations A and B,
which do not have to be based on the exact same set of files.
Both changesets and snapshots can be identified by hierarchical names,
like a file system path.
Note that many changeset and snapshot commands are very similar. Some
are even exactly the same in usage and implementation. Similarities
will be pointed out in the following detailed descriptions of change-
sets and snapshots:
SNAPSHOTS
A snapshot is simply a map of file names to specific revision numbers.
The concept is similar to a tag, but in contrast, a snapshot is stored
as a single, separate file, independent of the repository files them-
selves.
A snapshot is an explicit way to denote a bound configuration. It is
stored as a single plain text file below snapshots, a subdirectory of
the DCVSMETA module. Within this directory, snapshot files may be orga-
nized in a file system hierarchy.
Snapshots contain meta information about when and how they were cre-
ated, by whom and by which command. Here is an example snapshot called
/site-A/elego/dcvs/release-1.0:
# File: /example/DCVSMETA/snapshots/site-A/elego/dcvs/release-1.0
# Created: Tue Oct 11 17:25:54 2005
# Creator: neels
# Command: dcvs mksnap -r DCVS-1.0 elego/dcvs/release-1.0
# Description: first official release of DCVS
PkgTags 1.1
cvsup/getlogs.sh 1.1.1.1
cvsup/mkflist.sh 1.1.1.1
cvsup/Announce 1.2
cvsup/Blurb 1.2
cvsup/Install 1.2
cvsup/License 1.2
cvsup/Makefile 1.6
cvsup/Acknowledgments 1.1.1.2
cvsup/ChangeLog 1.3
...
tkdcvs/tkdcvs/tkdiff/PATCHES 1.1.1.1
tkdcvs/tkdcvs/tkdiff/tkdiff 1.1.1.1
tkdcvs/tkdiff/COPYING 1.1
tkdcvs/tkdiff/PATCHES 1.1
tkdcvs/tkdiff/tkdiff 1.1
CREATING A SNAPSHOT
A snapshot may be created based on a tag, a date or the current
contents of a workspace (mksnap). It may also be created on-the-
fly along with a tag (tag -S). Upon creation, the user provides
a snapshot name, which may contain a path hierarchy. Here are a
few examples:
Creating a snapshot...
based on the working copy:
dcvs mksnap my_new_snapshot
based on the working copy, with a path hierarchy:
dcvs mksnap my/path/hierarchy/my_new_snapshot
based on a known tag:
dcvs mksnap -r known_tag my_new_snapshot
based on a date:
dcvs mksnap -D 2005-12-24 my_new_snapshot
dcvs mksnap -D now my_new_snapshot
while creating a tag (see tag):
dcvs tag -S my_new_snapshot my_new_tag
All these commands can handle a path hierarchy in the snapshot
name. If a path is issued, a corresponding directory structure
will be created in the snapshot directory of the repository. You
will always have to issue the full path to make use of a snap-
shot that was created in a lower directory. (See Applying a
Snapshot)
Note that DCVS will always put new snapshots below a directory
that has the same name as the current DCVS server ID. This is
partly invisible, as DCVS will look up snapshots on all servers
automatically (see `Applying a Snapshot').
In effect, the server ID is prepended to the snapshot name in
the form of a path structure; example:
Given that the current DCVS server is `anthill.elego.de', and a
snapshot name `foo/bar' is used to create a snapshot, it would
end up at
DCVSMETA/snapshots/anthill/foo/bar
(All first-level subdirectories of the snapshot repository root,
i.e. DCVSMETA/snapshots/*, are treated as servers' directo-
ries.)
APPLYING A SNAPSHOT
Snapshots may be used for checkout, update, and diff commands.
By using the -S option like -S known_snapshot, these commands
can use the revision numbers from a provided snapshot. Gener-
ally, -S known_snapshot acts exactly like the well-known option
-r known_tag.
(The following paragraphs are exactly similar for snapshots and
changesets:)
There are different ways of providing the name of a snapshot;
conveniently and automatic (1), or explicitly and unique (2).
This is done to partly hide the fact that snapshots exist across
different servers. As mentioned above, new snapshots will always
be placed in a sub-directory corresponding to the current DCVS
server ID...
(1) DCVS can add this server ID automatically, by searching all
servers for a match. This will only work as long as there is
only one match. Just supply the snapshot name exactly the same
as on creation, and make sure that it does not start with a
slash /, e.g.:
dcvs update -S my/path/hierarchy/known_snapshot
(2) When having to be precise, a leading slash, followed by the
server ID, can be issued in the snapshot name. This will switch
off searching and handle the snapshot name as an "absolute
path", e.g.:
dcvs update -S /anthill/my/path/hierarchy/known_snapshot
(given an example host called anthill.elego.de)
CHECKOUT USING A SNAPSHOT
Doing a checkout initially downloads files from the server. When
issuing an -S snapshot_name option, DCVS will checkout the given
selection based on the revision numbers given in the snapshot,
e.g.:
dcvs checkout -S known_snapshot all
Here, all is the module to checkout (refer to the checkout com-
mand).
For known_snapshot, you can pass an "absolute" snapshot path
with a leading slash and a server ID, or simply a relative snap-
shot path to be searched for on all servers (see `Applying a
Snapshot').
UPDATE USING A SNAPSHOT
An update with a snapshot will bring your current working copy
to the state denoted by the revision numbers in the snapshot. An
update with a snapshot looks like this:
dcvs update -S known_snapshot
You may or may not provide files/modules to update, just as
update has worked before:
dcvs update -S known_snapshot files/*
For known_snapshot, you can pass an "absolute" snapshot path
with a leading slash and a server ID, or simply a relative snap-
shot path to be searched for on all servers (see `Applying a
Snapshot').
DIFF USING A SNAPSHOT
A diff will list all changes between two revisions in form of a
standard diff output, as is the case in CVS. With DCVS, you have
the option to replace any one of the -r or -D options with an -S
known_snapshot option. Here are a few examples:
Diff a snapshot against the working copy:
dcvs diff -S known_snapshot
Diff a snapshot against a tag:
dcvs diff -r known_tag -S known_snapshot
dcvs diff -S known_snapshot -r known_tag
Diff a snapshot against a date:
dcvs diff -D 2004-12-24 -S known_snapshot
dcvs diff -S known_snapshot -D 2004-12-24
Diff a snapshot against another snapshot:
dcvs diff -S known_snapshot1 -S known_snapshot2
For known_snapshot, you can pass an "absolute" snapshot path
with a leading slash and a server ID, or simply a relative snap-
shot path to be searched for on all servers (see `Applying a
Snapshot').
QUERYING SNAPSHOTS
(The following paragraphs are exactly similar for snapshots and
changesets:)
Existing snapshots can both be listed (lssnap) and printed out
(catsnap). These two mechanisms use very similar search algo-
rithms. The search algorithms work like this:
First of all, the same concept as described above applies:
either provide an "absolute" path including a leading slash and
a server ID, or provide a relative path (without a leading
slash) to be searched for on all hosts.
On top of that, wildcard characters can be used similarly to
standard shell patterns. Important: most wildcard patterns have
to be enclosed in quotes so that the shell does not expand them
before passing them to DCVS.
When providing no search pattern at all, lssnap will list all
available snapshot names of all servers; trying to use catsnap
without a search pattern will fail.
LISTING AVAILABLE SNAPSHOTS
(The following paragraphs are exactly similar for snapshots and
changesets:)
For listing snapshots, use the lssnap command. There is a long
format option -l available to print out creation date and user
ownership along with the snapshot names.
lssnap can either list all available snapshots, or list a subset
as given by one or more wildcard patterns similar to standard
shell patterns. Important: most wildcard patterns have to be
enclosed in quotes so that the shell does not expand them before
passing them to DCVS.
Note that lssnap will always print out "absolute" snapshot paths
including a leading slash and the server ID, no matter which
type of search pattern was used.
Here are a few examples:
List all snapshots:
dcvs lssnap
List all snapshots in long format:
dcvs lssnap -l
List all snapshots on server `anthill.elego.de' (recursive):
dcvs lssnap -r "/anthill/*"
(note the quotes that keep the shell from trying to expand the
asterisk)
List all snapshots two directories below any server's snapshot
root that start with foo and end on a digit up to 3:
dcvs lssnap "*/*/foo*[0123]"
The same complicated selection, but limited to server
`anthill.elego.de':
dcvs lssnap "/anthill/*/*/foo*[0123]"
List all snapshots of servers that have bar in their name:
dcvs lssnap -r "/*bar*/*"
PRINT OUT AVAILABLE SNAPSHOTS
(The following paragraphs are exactly similar for snapshots and
changesets:)
To print out existing snapshots to the screen, the DCVS command
catsnap can be used (name inspired by the common un*x command
cat). There is a verbose format (-v) available, which prints
out error messages for command arguments, if any, and the file
names of the snapshots themselves (they are also contained in
the snapshot headers). To print separation lines between snap-
shots, option -l can be used. To recurse into subdirectories,
option -r can be used.
Note that catsnap will simply print out the snapshot files
exactly as they are in the repository file system. catsnap does
not detect any syntax errors or the like. Only snapshot files
(text files) are allowed in the snapshot repository -- catsnap
assumes compliance.
Here are a few examples:
Print out any snapshots called foo on any servers' snapshot
roots:
dcvs catsnap foo
Print out the snapshot called foo on server anthill's snapshot
root:
dcvs catsnap /anthill/foo
Print out all snapshots in snapshot directory sub/dir on any
servers: dcvs catsnap sub/dir/*
Print out the same snapshots in verbose format:
dcvs catsnap -v "sub/dir/*"
Print out the same snapshots with lines separating snapshot
dumps:
dcvs catsnap -l "sub/dir/*"
Print out all snapshots two directories below any server's snap-
shot root that start with foo and end on a digit up to 3:
dcvs catsnap "*/*/foo*[0123]"
The same complicated selection, but limited to server
`anthill.elego.de':
dcvs catsnap "/anthill/*/*/foo*[0123]"
Print out snapshots called foo of servers that have bar in their
name:
dcvs catsnap "/*bar*/foo"
Print out all snapshots of all servers, with file names and
lines:
dcvs catsnap -lrv *
CHANGESETS
Changesets are, like snapshots, explicit mappings of file names to
revision numbers, kept in a single plain text file, independent of the
repository files themselves.
A changeset is an explicit way to denote the difference between two
configurations, thus every file name is mapped to two revision numbers.
One of the revisions may be -, to indicate that the file does not exist
in that configuration.
A changeset is stored as a single plain text file below changesets, a
subdirectory of the DCVSMETA module. Within this directory, changeset
files may be organized in a file system hierarchy, similar to snap-
shots.
Changesets contain meta information about when and how they were cre-
ated, by whom and by which command. Here is an example changeset called
/site-A/elego/dcvs/release-1-fix-02:
# File: /example/DCVSMETA/changesets/site-A/elego/dcvs/release-1-fix-02
# Created: Fri Oct 14 10:50:54 2005
# Creator: neels
# Command: dcvs mkcset -r release-1-0-0 -r release-1-0-1
# Description: fixes for issues 224, 265, and 887
PkgTags 1.1 1.5
cvsup/Announce 1.2 1.3
cvsup/Blurb 1.2 1.3
...
tkdcvs/tkdiff/PATCHES 1.1 1.2
tkdcvs/tkdiff/tkdiff 1.1 1.2
CREATING A CHANGESET
A Changeset may be created based on tags, dates or snapshots
(`mkcset'). It may also be created on-the-fly along with a com-
mit (`commit -g'). Upon creation, the user provides a changeset
name, which may contain a path hierarchy. Here are a few exam-
ples:
Creating a changeset...
based on two dates:
dcvs mkcset -D yesterday -D now my_new_changeset
based on two dates, with a path hierarchy:
dcvs mkcset -D yesterday -D now my/path/hierarchy/my_new_change-
set
based on two known tags:
dcvs mkcset -r known_tag1 -r known_tag2 my_new_changeset
based on two known snapshots:
dcvs mkcset -S known_snapshot1 -S known_snapshot2 my_new_change-
set
based on mixtures of tags/snapshots/dates:
dcvs mkcset -r tag -S snapshot my_new_changeset
dcvs mkcset -D date -r tag my_new_changeset
dcvs mkcset -S snapshot -D date my_new_changeset
(etc.)
while committing (see commit):
dcvs commit -g my_new_changeset
All these commands can handle a path hierarchy in the changeset
name. If a path is issued, a corresponding directory structure
will be created in the changeset directory of the repository.
You will always have to issue the full path to make use of a
changeset that was created in a lower directory. (See Applying a
Changeset)
Note that DCVS will always put new changesets below a directory
that has the same name as the current DCVS server ID. This is
partly invisible, as DCVS will look up changesets on all servers
automatically (see `Applying a Changeset').
In effect, the server ID is prepended to the changeset name in
the form of a path structure; example:
Given that the current DCVS server is `anthill.elego.de', and a
changeset name `foo/bar' is used to create a changeset, it would
end up at
DCVSMETA/changesets/anthill/foo/bar
(All first-level subdirectories of the changeset repository
root, i.e. DCVSMETA/changesets/*, are treated as servers'
directories.)
APPLYING A CHANGESET
Changesets may be used for update and diff commands. By using
the -g option like -g known_changeset, these commands can use
the revision numbers from a provided changeset. In update and
diff, the option -g known_changeset acts alike -j tag1 -j tag2,
and -r tag1 -r tag2, respectively.
(The following paragraphs are exactly similar for snapshots and
changesets:)
There are different ways of providing the name of a changeset;
conveniently and automatic (1), or explicitly and unique (2).
This is done to partly hide the fact that changesets exist
across different servers. As mentioned above, new changesets
will always be placed in a sub-directory corresponding to the
current DCVS server ID...
(1) DCVS can add this server ID automatically, by searching all
servers for a match. This will only work as long as there is
only one match. Just supply the changeset name exactly the same
as on creation, and make sure that it does not start with a
slash /, e.g.:
dcvs update -S my/path/hierarchy/known_changeset
(2) When having to be precise, a leading slash, followed by the
server ID, can be issued in the changeset name. This will switch
off searching and handle the changeset name as an "absolute
path", e.g.:
dcvs update -S /anthill/my/path/hierarchy/known_changeset
(given an example host called anthill.elego.de)
UPDATE USING A CHANGESET
An update with a changeset will act like a merge of changes made
on a branch that had been merged previously (like update -j -j).
(* TODO: explain much more here *)
An update with a changeset looks like this:
dcvs update -g known_changeset
For known_changeset, you can pass an "absolute" changeset path
with a leading slash and a server ID, or simply a relative
changeset path to be searched for on all servers (see `Applying
a Changeset').
DIFF USING A CHANGESET
A diff with a changeset lists the changes between each pair of
revisions in the changeset, given in form of a standard diff
output. Just issue a -g known_changeset option, replacing any
-r/-D options you would have issued otherwise.
Diff on a changeset:
dcvs diff -g known_changeset
For known_changeset, you can pass an "absolute" changeset path
with a leading slash and a server ID, or simply a relative
changeset path to be searched for on all servers (see `Applying
a Changeset').
QUERYING CHANGESETS
(The following paragraphs are exactly similar for snapshots and
changesets:)
Existing changesets can both be listed (lscset) and printed out
(catcset). These two mechanisms use very similar search algo-
rithms. The search algorithms work like this:
First of all, the same concept as described above applies:
either provide an "absolute" path including a leading slash and
a server ID, or provide a relative path (without a leading
slash) to be searched for on all hosts.
On top of that, wildcard characters can be used similarly to
standard shell patterns. Important: most wildcard patterns have
to be enclosed in quotes so that the shell does not expand them
before passing them to DCVS.
When providing no search pattern at all, lscset will list all
available changeset names of all servers; trying to use catcset
without a search pattern will fail.
LISTING AVAILABLE CHANGESETS
(The following paragraphs are exactly similar for snapshots and
changesets:)
For listing changesets, use the lscset command. There is a long
format option -l available to print out creation date and user
ownership along with the changeset names.
lscset can either list all available changesets, or list a sub-
set as given by one or more wildcard patterns similar to stan-
dard shell patterns. Important: most wildcard patterns have to
be enclosed in quotes so that the shell does not expand them
before passing them to DCVS.
Note that lscset will always print out "absolute" changeset
paths including a leading slash and the server ID, no matter
which type of search pattern was used.
Here are a few examples:
List all changesets:
dcvs lscset
List all changesets in long format:
dcvs lscset -l
List all changesets on server `anthill.elego.de' (recursive):
dcvs lscset -r "/anthill/*"
(note the quotes that keep the shell from trying to expand the
asterisk)
List all changesets two directories below any server's changeset
root that start with foo and end on a digit up to 3:
dcvs lscset "*/*/foo*[0123]"
The same complicated selection, but limited to server
`anthill.elego.de':
dcvs lscset "/anthill/*/*/foo*[0123]"
List all changesets of servers that have bar in their name:
dcvs lscset -r "/*bar*/*"
PRINT OUT AVAILABLE CHANGESETS
(The following paragraphs are exactly similar for snapshots and
changesets:)
To print out existing changesets to the screen, the DCVS command
catcset can be used (name inspired by the common un*x command
cat). There is a verbose format (-v) available, which prints
out error messages for command arguments, if any, and the file
names of the changesets themselves (they are also contained in
the changeset headers). There is an option to print separation
lines between changesets (-l).
Note that catcset will simply print out the changeset files
exactly as they are in the repository file system. catcset does
not detect any syntax errors or the like. Only changeset files
(text files) are allowed in the changeset repository -- catcset
assumes compliance.
Here are a few examples:
Print out any changesets called foo on any servers' changeset
roots:
dcvs catcset foo
Print out the changeset called foo on server anthill's changeset
root:
dcvs catcset /anthill/foo
Print out all changesets in changeset directory sub/dir on any
servers:
dcvs catcset "sub/dir/*"
Print out the same changesets in verbose format:
dcvs catcset -v "sub/dir/*"
Print out the same changesets with lines separating changeset
dumps:
dcvs catcset -l "sub/dir/*"
Print out all changesets two directories below any server's
changeset root that start with foo and end on a digit up to 3:
dcvs catcset "*/*/foo*[0123]"
The same complicated selection, but limited to server
`anthill.elego.de':
dcvs catcset "/anthill/*/*/foo*[0123]"
Print out changesets called foo of servers that have bar in
their name:
dcvs catcset "/*bar*/foo"
Print out all changesets of all servers, with file names and
lines:
dcvs catcset -lrv *
FILES
For more detailed information on dcvs supporting files, see cvs(5).
Files in home directories:
.cvsrc The dcvs initialization file. Lines in this file can be used to
specify default options for each dcvs command. For example the
line `diff -c' will ensure that `dcvs diff' is always passed the
-c option in addition to any other options passed on the command
line.
.cvswrappers
Specifies wrappers to be used in addition to those specified in
the DCVSROOT/cvswrappers file in the repository.
Files in working directories:
CVS A directory of dcvs administrative files. Do not delete.
CVS/Entries
List and status of files in your working directory.
CVS/Entries.Backup
A backup of `DCVS/Entries'.
CVS/Entries.Static
Flag: do not add more entries on `dcvs update'.
CVS/Root
Pathname to the repository ( DCVSROOT ) location at the time of
checkout. This file is used instead of the DCVSROOT environment
variable if the environment variable is not set. A warning mes-
sage will be issued when the contents of this file and the DCVS-
ROOT environment variable differ. The file may be over-ridden
by the presence of the CVS_IGNORE_REMOTE_ROOT environment vari-
able.
CVS/Repository
Pathname to the corresponding directory in the source reposi-
tory.
CVS/Tag
Contains the per-directory ``sticky'' tag or date information.
This file is created/updated when you specify -r or -D to the
checkout or update commands, and no files are specified.
CVS/Checkin.prog
Name of program to run on `dcvs commit'.
CVS/Update.prog
Name of program to run on `dcvs update'.
Files in source repositories:
$DCVSROOT/DCVSROOT
Directory of global administrative files for repository.
DCVSROOT/commitinfo,v
Records programs for filtering `dcvs commit' requests.
DCVSROOT/cvswrappers,v
Records dcvs wrapper commands to be used when checking files
into and out of the repository. Wrappers allow the file or
directory to be processed on the way in and out of DCVS. The
intended uses are many, one possible use would be to reformat a
C file before the file is checked in, so all of the code in the
repository looks the same.
DCVSROOT/editinfo,v
Records programs for editing/validating `dcvs commit' log
entries.
DCVSROOT/history
Log file of dcvs transactions.
DCVSROOT/loginfo,v
Records programs for piping `dcvs commit' log entries.
DCVSROOT/modules,v
Definitions for modules in this repository.
DCVSROOT/rcsinfo,v
Records pathnames to templates used during a `dcvs commit' oper-
ation.
DCVSROOT/taginfo,v
Records programs for validating/logging `dcvs tag' and `dcvs
rtag' operations.
MODULE/Attic
Directory for removed source files.
#cvs.lock
A lock directory created by dcvs when doing sensitive changes to
the source repository.
#cvs.tfl.pid
Temporary lock file for repository.
#cvs.rfl.pid
A read lock.
#cvs.wfl.pid
A write lock.
ENVIRONMENT
DCVSROOT
Should contain the full pathname to the root of the dcvs source
repository (where the RCS files are kept). This information
must be available to dcvs for most commands to execute; if DCVS-
ROOT is not set, or if you wish to override it for one invoca-
tion, you can supply it on the command line: `dcvs -d cvsroot
dcvs_command...' You may not need to set DCVSROOT if your dcvs
binary has the right path compiled in.
CVSREAD
If this is set, checkout and update will try hard to make the
files in your working directory read-only. When this is not
set, the default behavior is to permit modification of your
working files.
CVSREADONLYFS
If this is set, the -R option is assumed, and dcvs operates in
read-only repository mode.
RCSBIN Specifies the full pathname where to find RCS programs, such as
co(1) and ci(1) (DCVS 1.9 and older).
CVSEDITOR
Specifies the program to use for recording log messages during
commit. If not set, the VISUAL and EDITOR environment variables
are tried (in that order). If neither is set, a system-depen-
dent default editor (e.g., vi) is used.
CVS_CLIENT_PORT
If this variable is set then dcvs will use this port in pserver
mode rather than the default port (cvspserver 2401).
CVS_IGNORE_REMOTE_ROOT
If this variable is set then dcvs will ignore all references to
remote repositories in the DCVS/Root file.
CVS_OPTIONS
Specifies a set of default options for dcvs. These options are
interpreted before the startup file (~/.cvsrc) is read and can
be overridden by explicit command line parameters.
CVS_RSH
dcvs uses the contents of this variable to determine the name of
the remote shell command to use when starting a dcvs server. If
this variable is not set then `ssh' is used.
CVS_SERVER
dcvs uses the contents of this variable to determine the name of
the dcvs server command. If this variable is not set then
`dcvs' is used.
CVSWRAPPERS
This variable is used by the `cvswrappers' script to determine
the name of the wrapper file, in addition to the wrappers
defaults contained in the repository (DCVSROOT/cvswrappers) and
the user's home directory (~/.cvswrappers).
AUTHORS (CVS PROJECT)
Dick Grune
Original author of the cvs shell script version posted to
comp.sources.unix in the volume6 release of December, 1986.
Credited with much of the cvs conflict resolution algorithms.
Brian Berliner
Coder and designer of the cvs program itself in April, 1989,
based on the original work done by Dick.
Jeff Polk
Helped Brian with the design of the cvs module and vendor branch
support and author of the checkin(1) shell script (the ancestor
of `cvs import').
And many others too numerous to mention here.
AUTHORS (DCVS PROJECT)
elego Software Solutions (GmbH)
http://www.elegosoft.com
SEE ALSO
dcvs_config(5), dcvsupd(8), dcvsup(1), cvsupadm(1).
For DCVS updates, more information on documentation, software related
to DCVS, development of DCVS, and more, see:
http://www.elegosoft.com
Also related, but might not be installed:
ci(1), co(1), cvs(1), cvs(5), cvsbug(8), diff(1), grep(1), patch(1),
rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).
DCVS(1)