[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2. The Repository

The CVS repository stores a complete copy of all the files and directories which are under version control.

Normally, you never access any of the files in the repository directly. Instead, you use CVS commands to get your own copy of the files into a working directory, and then work on that copy. When you've finished a set of changes, you check (or commit) them back into the repository. The repository then contains the changes which you have made, as well as recording exactly what you changed, when you changed it, and other such information. Note that the repository is not a subdirectory of the working directory, or vice versa; they should be in separate locations.

CVS can access a repository by a variety of means. It might be on the local computer, or it might be on a computer across the room or across the world. To distinguish various ways to access a repository, the repository name can start with an access method. For example, the access method :local: means to access a repository directory, so the repository :local:/usr/local/cvsroot means that the repository is in `/usr/local/cvsroot' on the computer running CVS. For information on other access methods, see 2.9 Remote repositories.

If the access method is omitted, then if the repository does not contain `:', then :local: is assumed. If it does contain `:' then either :ext: or :server: is assumed. For example, if you have a local repository in `/usr/local/cvsroot', you can use /usr/local/cvsroot instead of :local:/usr/local/cvsroot. But if (under Windows NT, for example) your local repository is `c:\src\cvsroot', then you must specify the access method, as in :local:c:\src\cvsroot.

The repository is split in two parts. `$CVSROOT/CVSROOT' contains administrative files for CVS. The other directories contain the actual user-defined modules.

2.1 Telling CVS where your repository is  
2.2 How data is stored in the repository  The structure of the repository
2.3 How data is stored in the working directory  The structure of working directories
2.4 The administrative files  Defining modules
2.5 Multiple repositories  
2.6 Creating a repository  
2.7 Backing up a repository  
2.8 Moving a repository  
2.9 Remote repositories  Accessing repositories on remote machines
2.10 Read-only repository access  Granting read-only access to the repository
2.11 Temporary directories for the server  The server creates temporary directories

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1 Telling CVS where your repository is

There are several ways to tell CVS where to find the repository. You can name the repository on the command line explicitly, with the -d (for "directory") option:

 
cvs -d /usr/local/cvsroot checkout yoyodyne/tc

Or you can set the $CVSROOT environment variable to an absolute path to the root of the repository, `/usr/local/cvsroot' in this example. To set $CVSROOT, csh and tcsh users should have this line in their `.cshrc' or `.tcshrc' files:

 
setenv CVSROOT /usr/local/cvsroot

sh and bash users should instead have these lines in their `.profile' or `.bashrc':

 
CVSROOT=/usr/local/cvsroot
export CVSROOT

A repository specified with -d will override the $CVSROOT environment variable. Once you've checked a working copy out from the repository, it will remember where its repository is (the information is recorded in the `CVS/Root' file in the working copy).

The -d option and the `CVS/Root' file both override the $CVSROOT environment variable. If -d option differs from `CVS/Root', the former is used. Of course, for proper operation they should be two ways of referring to the same repository.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2 How data is stored in the repository

For most purposes it isn't important how CVS stores information in the repository. In fact, the format has changed in the past, and is likely to change in the future. Since in almost all cases one accesses the repository via CVS commands, such changes need not be disruptive.

However, in some cases it may be necessary to understand how CVS stores data in the repository, for example you might need to track down CVS locks (see section 10.5 Several developers simultaneously attempting to run CVS) or you might need to deal with the file permissions appropriate for the repository.

2.2.1 Where files are stored within the repository  What files are stored in the repository
2.2.2 File permissions  
2.2.3 File Permission issues specific to Windows  Issues specific to Windows
2.2.4 The attic  Some files are stored in the Attic
2.2.5 The CVS directory in the repository  Additional information in CVS directory
2.2.6 CVS locks in the repository  CVS locks control concurrent accesses
2.2.7 How files are stored in the CVSROOT directory  A few things about CVSROOT are different

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.1 Where files are stored within the repository

The overall structure of the repository is a directory tree corresponding to the directories in the working directory. For example, supposing the repository is in

 
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few ways from the standard format. The biggest difference is magic branches; for more information see 5.5 Magic branch numbers. Also in CVS the valid tag names are a subset of what RCS accepts; for CVS's rules see 4.4 Tags--Symbolic revisions.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 File permissions

All `,v' files are created read-only, and you should not change the permission of those files. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group (see group(5)) consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory.

This means that you can only control access to files on a per-directory basis.

Note that users must also have write access to check out files, because CVS needs to create lock files (see section 10.5 Several developers simultaneously attempting to run CVS).

Also note that users must have write access to the `CVSROOT/val-tags' file. CVS uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are created).

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.

CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the CVSUMASK environment variable that will control the file permissions which CVS uses in creating directories and/or files in the repository. CVSUMASK does not affect the file permissions in the working directory; such files have the permissions which are typical for newly created files, except that sometimes CVS creates them read-only (see the sections on watches, 10.6.1 Telling CVS to watch certain files; -r, A.4 Global options; or CVSREAD, D. All environment variables which affect CVS).

Note that using the client/server CVS (see section 2.9 Remote repositories), there is no good way to set CVSUMASK; the setting on the client machine has no effect. If you are connecting with rsh, you can set CVSUMASK in `.bashrc' or `.cshrc', as described in the documentation for your operating system. This behavior might change in future versions of CVS; do not rely on the setting of CVSUMASK on the client having no effect.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see 2.9.3.3 Security considerations with password authentication.

Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. For example, the set user ID (setuid) or set group ID (setgid) features of unix or the installed image feature of VMS. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS. You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option (2.9.3.3 Security considerations with password authentication).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 File Permission issues specific to Windows

Some file permission issues are specific to Windows operating systems (Windows 95, Windows NT, and presumably future operating systems in this family. Some of the following might apply to OS/2 but I'm not sure).

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. Enabling WRITE=YES in the samba configuration is said to fix/workaround it. Disclaimer: I haven't investigated enough to know the implications of enabling that option, nor do I know whether there is something which CVS could be doing differently in order to avoid the problem. If you find something out, please let us know as described in H. Dealing with bugs in CVS or this manual.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.4 The attic

You will notice that sometimes CVS stores an RCS file in the Attic. For example, if the CVSROOT is `/usr/local/cvsroot' and we are talking about the file `backend.c' in the directory `yoyodyne/tc', then the file normally would be in

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

but if it goes in the attic, it would be in

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

instead. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead. A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non-dead state.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.5 The CVS directory in the repository

The `CVS' directory in each repository directory contains information such as file attributes (in a file called `CVS/fileattr'. In the future additional files may be added to this directory, so implementations should silently ignore additional files.

This behavior is implemented only by CVS 1.7 and later; for details see 10.6.5 Using watches with old versions of CVS.

The format of the fileattr file is a series of entries of the following form (where `{' and `}' means the text between the braces can be repeated zero or more times):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type is `F' for a file, in which case the entry specifies the attributes for that file.

ent-type is `D', and filename empty, to specify default attributes to be used for newly added files.

Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them.

Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

There is currently no way of quoting tabs or linefeeds in the filename, `=' in attrname, `;' in attrval, etc. Note: some implementations also don't handle a NUL character in any of the fields, but implementations are encouraged to allow it.

By convention, attrname starting with `_' is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (or will be, once implementations start supporting user-defined attributes).

Builtin attributes:

_watched
Present means the file is watched and should be checked out read-only.

_watchers
Users with watches for this file. Value is watcher > type { , watcher > type } where watcher is a username, and type is zero or more of edit,unedit,commit separated by `+' (that is, nothing if none; there is no "none" or "all" keyword).

_editors
Users editing this file. Value is editor > val { , editor > val } where editor is a username, and val is time+hostname+pathname, where time is when the cvs edit command (or equivalent) happened, and hostname and pathname are for the working directory.

Example:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1nbsp;
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few ways from the standard format. The biggest difference is magic branches; for more information see 5.5 Magic branch numbers. Also in CVS the valid tag names are a subset of what RCS accepts; for CVS's rules see 4.4 Tags--Symbolic revisions.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 File permissions

All `,v' files are created read-only, and you should not change the permission of those files. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group (see group(5)) consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory.

This means that you can only control access to files on a per-directory basis.

Note that users must also have write access to check out files, because CVS needs to create lock files (see section 10.5 Several developers simultaneously attempting to run CVS).

Also note that users must have write access to the `CVSROOT/val-tags' file. CVS uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are created).

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.

CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the CVSUMASK environment variable that will control the file permissions which CVS uses in creating directories and/or files in the repository. CVSUMASK does not affect the file permissions in the working directory; such files have the permissions which are typical for newly created files, except that sometimes CVS creates them read-only (see the sections on watches, 10.6.1 Telling CVS to watch certain files; -r, A.4 Global options; or CVSREAD, D. All environment variables which affect CVS).

Note that using the client/server CVS (see section 2.9 Remote repositories), there is no good way to set CVSUMASK; the setting on the client machine has no effect. If you are connecting with rsh, you can set CVSUMASK in `.bashrc' or `.cshrc', as described in the documentation for your operating system. This behavior might change in future versions of CVS; do not rely on the setting of CVSUMASK on the client having no effect.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see 2.9.3.3 Security considerations with password authentication.

Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. For example, the set user ID (setuid) or set group ID (setgid) features of unix or the installed image feature of VMS. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS. You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option (2.9.3.3 Security considerations with password authentication).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 File Permission issues specific to Windows

Some file permission issues are specific to Windows operating systems (Windows 95, Windows NT, and presumably future operating systems in this family. Some of the following might apply to OS/2 but I'm not sure).

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. Enabling WRITE=YES in the samba configuration is said to fix/workaround it. Disclaimer: I haven't investigated enough to know the implications of enabling that option, nor do I know whether there is something which CVS could be doing differently in order to avoid the problem. If you find something out, please let us know as described in H. Dealing with bugs in CVS or this manual.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.4 The attic

You will notice that sometimes CVS stores an RCS file in the Attic. For example, if the CVSROOT is `/usr/local/cvsroot' and we are talking about the file `backend.c' in the directory `yoyodyne/tc', then the file normally would be in

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

but if it goes in the attic, it would be in

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

instead. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead. A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non-dead state.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.5 The CVS directory in the repository

The `CVS' directory in each repository directory contains information such as file attributes (in a file called `CVS/fileattr'. In the future additional files may be added to this directory, so implementations should silently ignore additional files.

This behavior is implemented only by CVS 1.7 and later; for details see 10.6.5 Using watches with old versions of CVS.

The format of the fileattr file is a series of entries of the following form (where `{' and `}' means the text between the braces can be repeated zero or more times):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type is `F' for a file, in which case the entry specifies the attributes for that file.

ent-type is `D', and filename empty, to specify default attributes to be used for newly added files.

Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them.

Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

There is currently no way of quoting tabs or linefeeds in the filename, `=' in attrname, `;' in attrval, etc. Note: some implementations also don't handle a NUL character in any of the fields, but implementations are encouraged to allow it.

By convention, attrname starting with `_' is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (or will be, once implementations start supporting user-defined attributes).

Builtin attributes:

_watched
Present means the file is watched and should be checked out read-only.

_watchers
Users with watches for this file. Value is watcher > type { , watcher > type } where watcher is a username, and type is zero or more of edit,unedit,commit separated by `+' (that is, nothing if none; there is no "none" or "all" keyword).

_editors
Users editing this file. Value is editor > val { , editor > val } where editor is a username, and val is time+hostname+pathname, where time is when the cvs edit command (or equivalent) happened, and hostname and pathname are for the working directory.

Example:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1nbsp;
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few ways from the standard format. The biggest difference is magic branches; for more information see 5.5 Magic branch numbers. Also in CVS the valid tag names are a subset of what RCS accepts; for CVS's rules see 4.4 Tags--Symbolic revisions.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 File permissions

All `,v' files are created read-only, and you should not change the permission of those files. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group (see group(5)) consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory.

This means that you can only control access to files on a per-directory basis.

Note that users must also have write access to check out files, because CVS needs to create lock files (see section 10.5 Several developers simultaneously attempting to run CVS).

Also note that users must have write access to the `CVSROOT/val-tags' file. CVS uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are created).

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.

CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the CVSUMASK environment variable that will control the file permissions which CVS uses in creating directories and/or files in the repository. CVSUMASK does not affect the file permissions in the working directory; such files have the permissions which are typical for newly created files, except that sometimes CVS creates them read-only (see the sections on watches, 10.6.1 Telling CVS to watch certain files; -r, A.4 Global options; or CVSREAD, D. All environment variables which affect CVS).

Note that using the client/server CVS (see section 2.9 Remote repositories), there is no good way to set CVSUMASK; the setting on the client machine has no effect. If you are connecting with rsh, you can set CVSUMASK in `.bashrc' or `.cshrc', as described in the documentation for your operating system. This behavior might change in future versions of CVS; do not rely on the setting of CVSUMASK on the client having no effect.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see 2.9.3.3 Security considerations with password authentication.

Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. For example, the set user ID (setuid) or set group ID (setgid) features of unix or the installed image feature of VMS. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS. You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option (2.9.3.3 Security considerations with password authentication).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 File Permission issues specific to Windows

Some file permission issues are specific to Windows operating systems (Windows 95, Windows NT, and presumably future operating systems in this family. Some of the following might apply to OS/2 but I'm not sure).

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. Enabling WRITE=YES in the samba configuration is said to fix/workaround it. Disclaimer: I haven't investigated enough to know the implications of enabling that option, nor do I know whether there is something which CVS could be doing differently in order to avoid the problem. If you find something out, please let us know as described in H. Dealing with bugs in CVS or this manual.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.4 The attic

You will notice that sometimes CVS stores an RCS file in the Attic. For example, if the CVSROOT is `/usr/local/cvsroot' and we are talking about the file `backend.c' in the directory `yoyodyne/tc', then the file normally would be in

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

but if it goes in the attic, it would be in

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

instead. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead. A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non-dead state.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.5 The CVS directory in the repository

The `CVS' directory in each repository directory contains information such as file attributes (in a file called `CVS/fileattr'. In the future additional files may be added to this directory, so implementations should silently ignore additional files.

This behavior is implemented only by CVS 1.7 and later; for details see 10.6.5 Using watches with old versions of CVS.

The format of the fileattr file is a series of entries of the following form (where `{' and `}' means the text between the braces can be repeated zero or more times):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type is `F' for a file, in which case the entry specifies the attributes for that file.

ent-type is `D', and filename empty, to specify default attributes to be used for newly added files.

Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them.

Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

There is currently no way of quoting tabs or linefeeds in the filename, `=' in attrname, `;' in attrval, etc. Note: some implementations also don't handle a NUL character in any of the fields, but implementations are encouraged to allow it.

By convention, attrname starting with `_' is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (or will be, once implementations start supporting user-defined attributes).

Builtin attributes:

_watched
Present means the file is watched and should be checked out read-only.

_watchers
Users with watches for this file. Value is watcher > type { , watcher > type } where watcher is a username, and type is zero or more of edit,unedit,commit separated by `+' (that is, nothing if none; there is no "none" or "all" keyword).

_editors
Users editing this file. Value is editor > val { , editor > val } where editor is a username, and val is time+hostname+pathname, where time is when the cvs edit command (or equivalent) happened, and hostname and pathname are for the working directory.

Example:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1nbsp;
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few ways from the standard format. The biggest difference is magic branches; for more information see 5.5 Magic branch numbers. Also in CVS the valid tag names are a subset of what RCS accepts; for CVS's rules see 4.4 Tags--Symbolic revisions.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 File permissions

All `,v' files are created read-only, and you should not change the permission of those files. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group (see group(5)) consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory.

This means that you can only control access to files on a per-directory basis.

Note that users must also have write access to check out files, because CVS needs to create lock files (see section 10.5 Several developers simultaneously attempting to run CVS).

Also note that users must have write access to the `CVSROOT/val-tags' file. CVS uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are created).

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.

CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the CVSUMASK environment variable that will control the file permissions which CVS uses in creating directories and/or files in the repository. CVSUMASK does not affect the file permissions in the working directory; such files have the permissions which are typical for newly created files, except that sometimes CVS creates them read-only (see the sections on watches, 10.6.1 Telling CVS to watch certain files; -r, A.4 Global options; or CVSREAD, D. All environment variables which affect CVS).

Note that using the client/server CVS (see section 2.9 Remote repositories), there is no good way to set CVSUMASK; the setting on the client machine has no effect. If you are connecting with rsh, you can set CVSUMASK in `.bashrc' or `.cshrc', as described in the documentation for your operating system. This behavior might change in future versions of CVS; do not rely on the setting of CVSUMASK on the client having no effect.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see 2.9.3.3 Security considerations with password authentication.

Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. For example, the set user ID (setuid) or set group ID (setgid) features of unix or the installed image feature of VMS. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS. You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option (2.9.3.3 Security considerations with password authentication).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 File Permission issues specific to Windows

Some file permission issues are specific to Windows operating systems (Windows 95, Windows NT, and presumably future operating systems in this family. Some of the following might apply to OS/2 but I'm not sure).

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. Enabling WRITE=YES in the samba configuration is said to fix/workaround it. Disclaimer: I haven't investigated enough to know the implications of enabling that option, nor do I know whether there is something which CVS could be doing differently in order to avoid the problem. If you find something out, please let us know as described in H. Dealing with bugs in CVS or this manual.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.4 The attic

You will notice that sometimes CVS stores an RCS file in the Attic. For example, if the CVSROOT is `/usr/local/cvsroot' and we are talking about the file `backend.c' in the directory `yoyodyne/tc', then the file normally would be in

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

but if it goes in the attic, it would be in

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

instead. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead. A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non-dead state.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.5 The CVS directory in the repository

The `CVS' directory in each repository directory contains information such as file attributes (in a file called `CVS/fileattr'. In the future additional files may be added to this directory, so implementations should silently ignore additional files.

This behavior is implemented only by CVS 1.7 and later; for details see 10.6.5 Using watches with old versions of CVS.

The format of the fileattr file is a series of entries of the following form (where `{' and `}' means the text between the braces can be repeated zero or more times):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type is `F' for a file, in which case the entry specifies the attributes for that file.

ent-type is `D', and filename empty, to specify default attributes to be used for newly added files.

Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them.

Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

There is currently no way of quoting tabs or linefeeds in the filename, `=' in attrname, `;' in attrval, etc. Note: some implementations also don't handle a NUL character in any of the fields, but implementations are encouraged to allow it.

By convention, attrname starting with `_' is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (or will be, once implementations start supporting user-defined attributes).

Builtin attributes:

_watched
Present means the file is watched and should be checked out read-only.

_watchers
Users with watches for this file. Value is watcher > type { , watcher > type } where watcher is a username, and type is zero or more of edit,unedit,commit separated by `+' (that is, nothing if none; there is no "none" or "all" keyword).

_editors
Users editing this file. Value is editor > val { , editor > val } where editor is a username, and val is time+hostname+pathname, where time is when the cvs edit command (or equivalent) happened, and hostname and pathname are for the working directory.

Example:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1nbsp;
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few ways from the standard format. The biggest difference is magic branches; for more information see 5.5 Magic branch numbers. Also in CVS the valid tag names are a subset of what RCS accepts; for CVS's rules see 4.4 Tags--Symbolic revisions.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 File permissions

All `,v' files are created read-only, and you should not change the permission of those files. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group (see group(5)) consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory.

This means that you can only control access to files on a per-directory basis.

Note that users must also have write access to check out files, because CVS needs to create lock files (see section 10.5 Several developers simultaneously attempting to run CVS).

Also note that users must have write access to the `CVSROOT/val-tags' file. CVS uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are created).

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.

CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the CVSUMASK environment variable that will control the file permissions which CVS uses in creating directories and/or files in the repository. CVSUMASK does not affect the file permissions in the working directory; such files have the permissions which are typical for newly created files, except that sometimes CVS creates them read-only (see the sections on watches, 10.6.1 Telling CVS to watch certain files; -r, A.4 Global options; or CVSREAD, D. All environment variables which affect CVS).

Note that using the client/server CVS (see section 2.9 Remote repositories), there is no good way to set CVSUMASK; the setting on the client machine has no effect. If you are connecting with rsh, you can set CVSUMASK in `.bashrc' or `.cshrc', as described in the documentation for your operating system. This behavior might change in future versions of CVS; do not rely on the setting of CVSUMASK on the client having no effect.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see 2.9.3.3 Security considerations with password authentication.

Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. For example, the set user ID (setuid) or set group ID (setgid) features of unix or the installed image feature of VMS. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS. You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option (2.9.3.3 Security considerations with password authentication).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 File Permission issues specific to Windows

Some file permission issues are specific to Windows operating systems (Windows 95, Windows NT, and presumably future operating systems in this family. Some of the following might apply to OS/2 but I'm not sure).

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. Enabling WRITE=YES in the samba configuration is said to fix/workaround it. Disclaimer: I haven't investigated enough to know the implications of enabling that option, nor do I know whether there is something which CVS could be doing differently in order to avoid the problem. If you find something out, please let us know as described in H. Dealing with bugs in CVS or this manual.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.4 The attic

You will notice that sometimes CVS stores an RCS file in the Attic. For example, if the CVSROOT is `/usr/local/cvsroot' and we are talking about the file `backend.c' in the directory `yoyodyne/tc', then the file normally would be in

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

but if it goes in the attic, it would be in

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

instead. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead. A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non-dead state.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.5 The CVS directory in the repository

The `CVS' directory in each repository directory contains information such as file attributes (in a file called `CVS/fileattr'. In the future additional files may be added to this directory, so implementations should silently ignore additional files.

This behavior is implemented only by CVS 1.7 and later; for details see 10.6.5 Using watches with old versions of CVS.

The format of the fileattr file is a series of entries of the following form (where `{' and `}' means the text between the braces can be repeated zero or more times):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type is `F' for a file, in which case the entry specifies the attributes for that file.

ent-type is `D', and filename empty, to specify default attributes to be used for newly added files.

Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them.

Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

There is currently no way of quoting tabs or linefeeds in the filename, `=' in attrname, `;' in attrval, etc. Note: some implementations also don't handle a NUL character in any of the fields, but implementations are encouraged to allow it.

By convention, attrname starting with `_' is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (or will be, once implementations start supporting user-defined attributes).

Builtin attributes:

_watched
Present means the file is watched and should be checked out read-only.

_watchers
Users with watches for this file. Value is watcher > type { , watcher > type } where watcher is a username, and type is zero or more of edit,unedit,commit separated by `+' (that is, nothing if none; there is no "none" or "all" keyword).

_editors
Users editing this file. Value is editor > val { , editor > val } where editor is a username, and val is time+hostname+pathname, where time is when the cvs edit command (or equivalent) happened, and hostname and pathname are for the working directory.

Example:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1nbsp;
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few ways from the standard format. The biggest difference is magic branches; for more information see 5.5 Magic branch numbers. Also in CVS the valid tag names are a subset of what RCS accepts; for CVS's rules see 4.4 Tags--Symbolic revisions.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 File permissions

All `,v' files are created read-only, and you should not change the permission of those files. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group (see group(5)) consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory.

This means that you can only control access to files on a per-directory basis.

Note that users must also have write access to check out files, because CVS needs to create lock files (see section 10.5 Several developers simultaneously attempting to run CVS).

Also note that users must have write access to the `CVSROOT/val-tags' file. CVS uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are created).

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.

CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the CVSUMASK environment variable that will control the file permissions which CVS uses in creating directories and/or files in the repository. CVSUMASK does not affect the file permissions in the working directory; such files have the permissions which are typical for newly created files, except that sometimes CVS creates them read-only (see the sections on watches, 10.6.1 Telling CVS to watch certain files; -r, A.4 Global options; or CVSREAD, D. All environment variables which affect CVS).

Note that using the client/server CVS (see section 2.9 Remote repositories), there is no good way to set CVSUMASK; the setting on the client machine has no effect. If you are connecting with rsh, you can set CVSUMASK in `.bashrc' or `.cshrc', as described in the documentation for your operating system. This behavior might change in future versions of CVS; do not rely on the setting of CVSUMASK on the client having no effect.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see 2.9.3.3 Security considerations with password authentication.

Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. For example, the set user ID (setuid) or set group ID (setgid) features of unix or the installed image feature of VMS. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS. You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option (2.9.3.3 Security considerations with password authentication).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 File Permission issues specific to Windows

Some file permission issues are specific to Windows operating systems (Windows 95, Windows NT, and presumably future operating systems in this family. Some of the following might apply to OS/2 but I'm not sure).

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. Enabling WRITE=YES in the samba configuration is said to fix/workaround it. Disclaimer: I haven't investigated enough to know the implications of enabling that option, nor do I know whether there is something which CVS could be doing differently in order to avoid the problem. If you find something out, please let us know as described in H. Dealing with bugs in CVS or this manual.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.4 The attic

You will notice that sometimes CVS stores an RCS file in the Attic. For example, if the CVSROOT is `/usr/local/cvsroot' and we are talking about the file `backend.c' in the directory `yoyodyne/tc', then the file normally would be in

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

but if it goes in the attic, it would be in

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

instead. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead. A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non-dead state.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.5 The CVS directory in the repository

The `CVS' directory in each repository directory contains information such as file attributes (in a file called `CVS/fileattr'. In the future additional files may be added to this directory, so implementations should silently ignore additional files.

This behavior is implemented only by CVS 1.7 and later; for details see 10.6.5 Using watches with old versions of CVS.

The format of the fileattr file is a series of entries of the following form (where `{' and `}' means the text between the braces can be repeated zero or more times):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type is `F' for a file, in which case the entry specifies the attributes for that file.

ent-type is `D', and filename empty, to specify default attributes to be used for newly added files.

Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them.

Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

There is currently no way of quoting tabs or linefeeds in the filename, `=' in attrname, `;' in attrval, etc. Note: some implementations also don't handle a NUL character in any of the fields, but implementations are encouraged to allow it.

By convention, attrname starting with `_' is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (or will be, once implementations start supporting user-defined attributes).

Builtin attributes:

_watched
Present means the file is watched and should be checked out read-only.

_watchers
Users with watches for this file. Value is watcher > type { , watcher > type } where watcher is a username, and type is zero or more of edit,unedit,commit separated by `+' (that is, nothing if none; there is no "none" or "all" keyword).

_editors
Users editing this file. Value is editor > val { , editor > val } where editor is a username, and val is time+hostname+pathname, where time is when the cvs edit command (or equivalent) happened, and hostname and pathname are for the working directory.

Example:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1nbsp;
/usr/local/cvsroot

here is a possible directory tree (showing only the directories):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    |
 |   |    +--CVSROOT
          |      (administrative files)
          |
          +--gnu
          |   |
          |   +--diff
          |   |   (source code to GNU diff)
          |   |
          |   +--rcs
          |   |   (source code to RCS)
          |   |
          |   +--cvs
          |       (source code to CVS)
          |
          +--yoyodyne
              |
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              |
              +--(other Yoyodyne software)

With the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with `,v' appended to the end. Here is what the repository for the `yoyodyne/tc' directory might look like:
 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files, because the first program to store files in that format was a version control system known as RCS. For a full description of the file format, see the man page rcsfile(5), distributed with RCS, or the file `doc/RCSFILES' in the CVS source distribution. This file format has become very common--many systems other than CVS or RCS can at least import history files in this format.

The RCS files used in CVS differ in a few