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. You can apply a changeset  in
              reverse order using update -G known_changeset instead of -g.

              (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 -g 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   -g   /anthill/my/path/hierarchy/known_changeset
              (given an example host called anthill.elego.de)


       UPDATE/MERGE USING A CHANGESET
              A merge of a changeset into the current working copy is done via
              the DCVS command update. An update with a changeset and a  merge
              of a changeset are just two names for exactly the same thing.

              An  update with a changeset will find out what changes have been
              made between each pair of revisions in the changeset,  and  will
              try  to  apply  those  same  changes to the current working copy
              (like update -j -j).

              It does not matter whether the current working copy is identical
              to  the  first column of revisions in the changeset or not. How-
              ever, if they are not identical, the merge may produce conflicts
              that have to be resolved manually.

              An update with a changeset looks like this:

              dcvs update -g known_changeset

              To  apply a changeset in reverse order, e.g. to undo the changes
              made by a changeset, use -G instead of -g:

              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)

Man(1) output converted with man2html