home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  


  Previous section   Next section

6.9 Sandbox Structure

A CVS sandbox is composed of a sandbox root directory, the project files and directories, and a special CVS subdirectory in the root directory and in every project directory. The sandbox root directory usually has the same name as the module it was created for, or it takes the name of the project root directory in the repository.

Project files in a sandbox are in editable form, just as if they were exported from the repository for release. The CVS subdirectory in each project directory stores metadata for the files in the project directory it is part of. This metadata is contained in a number of files (and one directory). Each of the sandbox directories may also contain a .cvsignore file.

6.9.1 CVS Subdirectories

Each project directory in a sandbox contains a subdirectory named CVS. This CVS subdirectory contains the files that store the administrative data for the files in the project directory. The following list describes the files and directories you will most likely find in a CVS directory. Files that are rarely encountered or are temporary are not included in this list. The full list of files is available in Chapter 11.

If you need to edit any of these files manually, back the file up before you start.

Base

Stores the pre-editing revision of any files that are being edited with cvs edit. This is a directory, not a file.

Baserev

Contains the revision information for every file in the Base directory, in the format name/revision/. Later versions of CVS may add to this format.

Checkin.prog

Used if the modules file in CVSROOT has a -i option for the module in this sandbox. Checkin.prog stores the program used when the module is committed. This file is obsolete in CVS 1.11.5 and later.

Entries

Contains a line for each file and directory in the relevant sandbox directory. Lines for files have the format:

/name/revision/timestamp[+conflict]/options/tagdate

Lines for directories have the format:

D/name////

There may be text between or after the empty slashes in the directory form, but in the current version of CVS (1.11.5) this text is ignored. The space is reserved for future expansion.

Entries.Log

Used to record planned changes to the Entries file, one change per line. Lines to be added to the Entries file start with A; lines to be removed start with R. There must be a space after the A or R, followed by the line to be added or removed from Entries in the same format as in that file.

Programs that read Entries should also check for Entries.Log. If this file exists, the programs should read Entries, apply the changes from Entries.Log, then rewrite Entries and remove Entries.Log.

Entries.Static

If this file exists, CVS did not receive a complete set of files from the repository and this sandbox directory is static; CVS will not create new files in the parent directory. This file can be cleared by using update -d to download a full set of files and subdirectories for the parent directory.

Notify

Contains any cvs watch notifications that have not yet been sent to the server.

Repository

Usually contains the path from the repository root to the repository directory that the relevant sandbox directory is a reflection of. This file may contain the full path, including the path to the root of the sandbox's repository.

If the current sandbox directory does not have a related repository directory, this file contains CVSROOT/Emptydir.

Root

Contains the path to the root of the sandbox's repository.

Tag

Used to store a sticky tag or date that applies to the whole parent directory, if one exists. This sticky tag or date is usually used to add the relevant tag or date to new files in the directory, especially when using branch tags.

If the first character in the Tag file is T, the Tag file designates that the parent directory has a sticky branch tag. N is a nonbranch tag, and D is a date.

Template

In client/server mode, this file stores the login template specified in the rcsinfo file in the repository's CVSROOT directory.

Update.prog

Used if the modules file in CVSROOT has a -u option for this sandbox's module. The file stores the program used when the module is updated. This file is obsolete in 1.11.5 and later.

6.9.2 Dot Files in Sandbox Directories

The .cvsignore file can be used in any sandbox subdirectory or sandbox root directory. It contains a list of files CVS should not process from the directory. This file uses the same format as cvsignore in the repository's CVSROOT directory, but its list applies only to files in the directory it is contained in.

6.9.3 Dot Files in User Home Directories

CVS reads several files and one directory in the calling user's home directory. These files and the directory are described in the following list. All but the .rhosts file are read and used by the process that runs on the client computer. .rhosts is used with rsh and resides in the user's server-side home directory. Note that these files and the directory must be in the calling user's directory, so different users may cause different behavior.

.cvsrc

Contains a list of CVS commands and the options the user wants as default options for those commands. See Chapter 3 for more details on command options.

.cvsignore

Contains a list of files CVS should not process. This file uses the same format as cvsignore in the repository's CVSROOT directory.

.cvswrappers

Contains a list of wrappers that affect how a file is stored, based on the filename. See Chapter 3 for more details.

.cvspass

Used in pserver remote-access mode. This file contains the user's password, stored in a simple form of encoding. Be aware that the file is human-readable and the password is easy to decrypt.

.rhosts

Used when connecting with rsh. This file should be in the user's home directory on the server machine, and it should contain the client's computer hostname and the username on the client machine. See Chapter 8.

.ssh

Used when connecting with SSH. This directory should be in the user's home directory on both client and server machines. See your SSH documentation for details.


  Previous section   Next section
Top