cvsupd.class(5)           FreeBSD File Formats Manual          cvsupd.class(5)


NAME

     dcvsupd.class -- client class based access restrictions on CVSup collec-
     tions


DESCRIPTION

     dcvsupd.class is the configuration file read by the cvsupd(8) daemon to
     specify access rights and restrictions to collections of files based on
     the class of the client.  If dcvsupd.class does not exist, dcvsupd grants
     free access to all collections by default.

     The dcvsupd.class file resides in the base directory of the dcvsupd
     server.  By default, the base directory is /usr/local/etc/cvsup, but the
     location can be overridden with the -b option to dcvsupd.

     The dcvsupd.class file contains specifications of client classes with a
     syntax similar to other configuration files such as /etc/printcap and
     /etc/login.conf.  Comment lines beginning with `#' are ignored, as are
     empty lines.  All other lines are considered to contain class specifica-
     tions.  Each line contains a single class specification.  Long lines can
     be broken up by using the backslash (`\') as a continuation character at
     the end of the line.

     A class specification consists of fields separated by colons (`:').  The
     first field of each entry contains the name of the class.  The remaining
     fields contain attribute-value pairs in the form `attribute=value'.
     Empty fields and fields containing only white space are ignored.


PATTERNS

     Many of the values consist of comma-separated lists of patterns.  Pat-
     terns are by default shell-style patterns as described in sh(1), using
     the wild card constructs `*', `'?, and `[...]'.  Unlike sh(1), however,
     there is no special treatment for `/' or for leading `.' characters.
     That is, these characters are matched by wild cards just the same as
     other characters.

     If a pattern begins with `+' then it is instead interpreted as a regular
     expression.  The leading `+' is removed and the regular expression is
     anchored implicitly, as if it began with `^' and ended with `$'.  To
     begin a shell-style pattern with `+', use `[+]'.

     If a pattern is preceded by `'!  then it is negated.  A negated pattern
     selects whatever the pattern does not match.  When negating a regular
     expression pattern, the `'!  should come first, followed by the `+'.

     For more complex matching, patterns can be combined into comma-separated
     lists.  The patterns in a list are applied in order from left to right.
     Later patterns override the earlier ones; i.e., the last match wins.  For
     example, the pattern list `f*,!fu*' would match all strings beginning
     with `f' except for those beginning with `fu'.


ATTRIBUTES

     The following attributes apply to all collections:

     collections=patternlist
                 Clients in this class will only be able to access collections
                 that are matched by the pattern list.  Other collections will
                 be treated as if they did not exist.

     collection-dirs=patternlist
                 Clients in this class will only be able to access collections
                 in subdirectories matched by the pattern list.  Other collec-
                 tions will be treated as if they did not exist.

                 These subdirectories are relative to the server's base direc-
                 tory.  By default the server looks for collections in a sin-
                 gle subdirectory sup, but a list of subdirectories can be
                 specified on the command line with the -c option.  The
                 collection-dirs specification is applied to that list.  In
                 other words, collection-dirs can be used to eliminate certain
                 subdirectories for a given class, but it cannot be used to
                 add new subdirectories which were not specified on the com-
                 mand line.

     The remaining attributes apply only to collections containing RCS files:

     branches=patternlist
                 Only branches matched by the pattern list will be visible to
                 clients in this class.  Valid branch names are all special
                 CVS branch tags and the literal `'.  which specifies the main
                 branch of the revision tree.

     branches/collection=patternlist
                 This attribute can be used to further refine the branches
                 specification for a specific collection.  The given pattern
                 list is appended to the end of the branches pattern list, and
                 the result is used to control which branches are visible in
                 the specified collection.  Note: collection must be the exact
                 name of a collection; it is not a pattern.

     tags=patternlist
                 Only tags matched by the pattern list will be visible to
                 clients in this class.

     tags/collection=patternlist
                 This attribute can be used to further refine the tags speci-
                 fication for a specific collection.  The given pattern list
                 is appended to the end of the tags pattern list, and the
                 result is used to control which tags are visible in the spec-
                 ified collection.  Note: collection must be the exact name of
                 a collection; it is not a pattern.

     opaque-collections=patternlist
                 All collections matched by the pattern list will be treated
                 as opaque.  In an opaque collection, certain branches and
                 tags are hidden from the client.

                 Normally the opaque collections are determined automatically,
                 based on the values of other attributes.  The
                 opaque-collections attribute is provided for completeness,
                 but it is not expected to be needed.

     Finally, each class specification may contain this attribute:

     default=class
                 Any attributes not specified for the current class will be
                 copied from the class named by the default attribute.  The
                 named class must have already been defined earlier in the
                 cvsupd.class file; forward references are not allowed.

                 If a class has no default attribute specification, its
                 defaults are taken from the class named `default'.  The
                 `default' class may be defined in cvsupd.class as the first
                 entry in the file.  If it is missing, the server provides a
                 `default' class which gives free access to all collections,
                 equivalent to the following:

                 default:\
                   :collections=*:\
                   :collection-dirs=*:\
                   :branches=*:\
                   :tags=*:\
                   :opaque-collections=!*:


IMPLEMENTATION NOTES

     The implementation of the class concept is currently contained completely
     in the CVSup server dcvsupd.  Information about hidden collections and
     non-visible branches of partially hidden collections is never communi-
     cated to the client.  For partially hidden RCS files, the server pretends
     not to know anything about deltas, tags, and branches that are not visi-
     ble for the client.

     Due to the structure of RCS files, it is only possible to hide parts of
     branches from the branch point on the main trunk to the tip of the branch
     onwards, and the top part of the main trunk (on which no other exported
     branches may reside).

     When the export status of a collection changes, the client will not get
     any new deltas that weren't visible to it before by default, because the
     file attributes (including the modification time) will probably not have
     changed. Thus in these cases it is necessary to force the server to per-
     form a complete detailed comparison of all RCS files. As currently no
     meta-information about the export status of collections is kept at the
     client, there is no way to automate this procedure. As a workaround, both
     the client and the server have been extended to recognize the -x command
     line option, which enforces the complete compare. The option only needs
     to be given to the server or the client, not to both.

     If the dcvsupd.class file changes, the server needs not to be restarted
     or informed via a signal; the new information will automatically be used
     for the next client connection.


FILES

     /usr/local/etc/cvsup                Default base directory.
     /usr/local/etc/cvsup/cvsupd.class   Client class based access
                                         rights/restrictions
     /usr/local/etc/cvsup/cvsupd.access  Network/host based access
                                         rights/restrictions
     /usr/local/etc/cvsup/cvsupd.passwd  CVSup password database


EXAMPLES

     The following example grants default access to all collections containing
     the string `pub' in their names as well as to the `src-base' collection:

     default:\
       :collections=*pub*,src-base:\
       :branches=*:\
       :tags=*:

     In the next example, all collections except those whose names begin with
     ``pr_'' and ``ex_'' are exported by default:

     default:\
       :collections=!pr_*,!ex_*:

     Here is a specification for a guest class that exports all collections
     whose names contain only letters.  Access to these collections is unre-
     stricted, except for the collection `flash', from which only the stable
     release branches and corresponding tags are exported:

     guest:\
       :collections=+[A-Za-z]*:\
       :branches=*:\
       :tags=*:\
       :branches/flash=!*,release_flash_?_?_stable:


SEE ALSO

     co(1), cvpasswd(1), cvs(1), cvsup(1), cvsupd(8), cvsupd.passwd(5).

     http://www.cvsup.org/


AUTHORS

     John Polstra <jdp@polstra.com>,
     Olaf Wagner <wagner@elego.de>.


BUGS

     ·   Checkout mode for partially hidden collections is currently not
         implemented.

     ·   In exact mode (which is no more cleared by default for partially hid-
         den collections) the algorithm used for tags often leads to unneces-
         sary delete tag/add tag sequences when the export status of tags
         and/or branches changes.

     ·   Probably many more as the implementation has not been extensively
         tested yet.

FreeBSD                        December 10, 2000                       FreeBSD