{ "content": [ { "type": "text", "text": "# cvs (info)\n\n## Sections\n\n- **File: cvs.info, Node: Top, Next: Overview, Up: (dir)**\n- **CVS--Concurrent Versions System v1.12.13**\n- **This info manual describes how to use and administer CVS version**\n- **Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,**\n- **Portions**\n- **File: cvs.info, Node: Overview, Next: Repository, Prev: Top, Up: Top**\n- **1 Overview**\n- **This chapter is for people who have never used CVS, and perhaps have** (1 subsections)\n- **Unfortunately, if someone is using another editor, that safeguard will**\n- **July, 1986. While no actual code from these shell scripts is present in** (2 subsections)\n- **As a way of introducing CVS, we'll go through a typical work-session**\n- **File: cvs.info, Node: Getting the source, Next: Committing your changes, Up: A sample session**\n- **The first thing you must do is to get your own working copy of the**\n- **This will create a new directory called 'tc' and populate it with the**\n- **File: cvs.info, Node: Committing your changes, Next: Cleaning up, Prev: Getting the source, Up: A sample session**\n- **When you have checked that the compiler is still compilable you decide**\n- **File: cvs.info, Node: Cleaning up, Next: Viewing differences, Prev: Committing your changes, Up: A sample session**\n- **Before you turn to other tasks you decide to remove your working copy of**\n- **File: cvs.info, Node: Viewing differences, Prev: Cleaning up, Up: A sample session**\n- **You do not remember modifying 'driver.c', so you want to see what has**\n- **File: cvs.info, Node: Repository, Next: Starting a new project, Prev: Overview, Up: Top**\n- **2 The Repository**\n- **File: cvs.info, Node: Specifying a repository, Next: Repository storage, Up: Repository** (1 subsections)\n- **There are several ways to tell CVS where to find the repository. You**\n- **File: cvs.info, Node: Repository storage, Next: Working directory storage, Prev: Specifying a repository, Up: Repository** (1 subsections)\n- **For most purposes it isn't important how CVS stores information in the**\n- **File: cvs.info, Node: Repository files, Next: File permissions, Up: Repository storage**\n- **The overall structure of the repository is a directory tree**\n- **File: cvs.info, Node: File permissions, Next: Windows permissions, Prev: Repository files, Up: Repository storage**\n- **All ',v' files are created read-only, and you should not change the**\n- **File: cvs.info, Node: Windows permissions, Next: Attic, Prev: File permissions, Up: Repository storage**\n- **Some file permission issues are specific to Windows operating systems**\n- **File: cvs.info, Node: Attic, Next: CVS in repository, Prev: Windows permissions, Up: Repository storage**\n- **For example, if the CVSROOT is '/usr/local/cvsroot' and we are talking**\n- **File: cvs.info, Node: CVS in repository, Next: Locks, Prev: Attic, Up: Repository storage**\n- **The 'CVS' directory in each repository directory contains information**\n- **The file 'file2' should be checked out read-only; sue started editing it**\n- **File: cvs.info, Node: Locks, Next: CVSROOT storage, Prev: CVS in repository, Up: Repository storage**\n- **For an introduction to CVS locks focusing on user-visible behavior, see**\n- **File: cvs.info, Node: CVSROOT storage, Prev: Locks, Up: Repository storage**\n- **File: cvs.info, Node: Working directory storage, Next: Intro administrative files, Prev: Repository storage, Up: Repository** (1 subsections)\n- **While we are discussing CVS internals which may become visible from time**\n- **But in some cases it may be useful to look at it, and other programs,**\n- **File: cvs.info, Node: Intro administrative files, Next: Multiple repositories, Prev: Working directory storage, Up: Repository** (1 subsections)\n- **You edit the administrative files in the same way that you would edit**\n- **File: cvs.info, Node: Multiple repositories, Next: Creating a repository, Prev: Intro administrative files, Up: Repository** (1 subsections)\n- **In some situations it is a good idea to have more than one repository,**\n- **File: cvs.info, Node: Creating a repository, Next: Backing up, Prev: Multiple repositories, Up: Repository** (1 subsections)\n- **This section describes how to set up a CVS repository for any sort of**\n- **Repository::). For example,**\n- **File: cvs.info, Node: Backing up, Next: Moving a repository, Prev: Creating a repository, Up: Repository** (1 subsections)\n- **There is nothing particularly magical about the files in the repository;**\n- **The details would depend on your operating system and how you have CVS**\n- **Having said all this, if you just back up without any of these**\n- **Restoring from backup, the repository might be in an inconsistent state,**\n- **File: cvs.info, Node: Moving a repository, Next: Remote repositories, Prev: Backing up, Up: Repository** (1 subsections)\n- **Just as backing up the files in the repository is pretty much like**\n- **File: cvs.info, Node: Remote repositories, Next: Read-only access, Prev: Moving a repository, Up: Repository** (1 subsections)\n- **Your working copy of the sources can be on a different machine than the**\n- **Generally, using a remote repository is just like using a local one,**\n- **File: cvs.info, Node: Server requirements, Next: The connection method, Up: Remote repositories**\n- **The quick answer to what sort of machine is suitable as a server is that**\n- **This can be swap space rather than physical memory. Because the memory**\n- **File: cvs.info, Node: The connection method, Next: Connecting via rsh, Prev: Server requirements, Up: Remote repositories**\n- **Remote repositories::) may be one of 'ext', 'fork', 'gserver',**\n- **File: cvs.info, Node: Connecting via rsh, Next: Password authenticated, Prev: The connection method, Up: Remote repositories**\n- **Then test that 'rsh' is working with**\n- **File: cvs.info, Node: Password authenticated, Next: GSSAPI authenticated, Prev: Connecting via rsh, Up: Remote repositories**\n- **This is particularly useful if using 'rsh' is not feasible (for example,**\n- **File: cvs.info, Node: Password authentication server, Next: Password authentication client, Up: Password authenticated**\n- **First of all, you probably want to tighten the permissions on the**\n- **Clients which attempt to use a different CVSROOT directory will not be**\n- **Unix '/etc/passwd' files.)**\n- **When the password field is omitted or empty, then the client's**\n- **Modules) and your CVS server executable was configured to use it at**\n- **File: cvs.info, Node: Password authentication client, Next: Password authentication security, Prev: Password authentication server, Up: Password authenticated**\n- **To run a CVS command on a remote repository via the**\n- **That file's format is human-readable, and to a degree human-editable,**\n- **File: cvs.info, Node: Password authentication security, Prev: Password authentication client, Up: Password authenticated**\n- **The passwords are stored on the client side in a trivial encoding of the**\n- **File: cvs.info, Node: GSSAPI authenticated, Next: Kerberos authenticated, Prev: Password authenticated, Up: Remote repositories**\n- **Kerberos 5. If you have a working GSSAPI library, you can have CVS**\n- **Kerberos version 5 are present. You can also use the '--with-gssapi'**\n- **Kerberos which provides for strong authentication, you will probably**\n- **File: cvs.info, Node: Kerberos authenticated, Next: Connecting via fork, Prev: GSSAPI authenticated, Up: Remote repositories**\n- **The easiest way to use Kerberos is to use the Kerberos 'rsh', as**\n- **File: cvs.info, Node: Connecting via fork, Next: Write proxies, Prev: Kerberos authenticated, Up: Remote repositories**\n- **This access method allows you to connect to a repository on your local**\n- **File: cvs.info, Node: Write proxies, Prev: Connecting via fork, Up: Remote repositories**\n- **File: cvs.info, Node: Read-only access, Next: Server temporary directory, Prev: Remote repositories, Up: Repository** (1 subsections)\n- **It is possible to grant read-only repository access to people using the**\n- **That is, the 'readers' and 'writers' files contain cvs usernames, which**\n- **This is resolved in the more conservative way, it being better to**\n- **File: cvs.info, Node: Server temporary directory, Prev: Read-only access, Up: Repository** (1 subsections)\n- **While running, the CVS server creates temporary directories. They are**\n- **File: cvs.info, Node: Starting a new project, Next: Revisions, Prev: Repository, Up: Top**\n- **3 Starting a project with CVS**\n- **Because renaming files and moving them between directories is somewhat**\n- **File: cvs.info, Node: Setting up the files, Next: Defining the module, Up: Starting a new project** (1 subsections)\n- **The first step is to create the files inside the repository. This can**\n- **File: cvs.info, Node: From files, Next: From other version control systems, Up: Setting up the files**\n- **When you begin using CVS, you will probably already have several**\n- **Erasing the original sources is a good idea, to make sure that you do**\n- **File: cvs.info, Node: From other version control systems, Next: From scratch, Prev: From files, Up: Setting up the files**\n- **If you have a project which you are maintaining with another version**\n- **From another version control system**\n- **File: cvs.info, Node: From scratch, Prev: From other version control systems, Up: Setting up the files**\n- **For a new project, the easiest thing to do is probably to create an**\n- **File: cvs.info, Node: Defining the module, Prev: Setting up the files, Up: Starting a new project** (1 subsections)\n- **The next step is to define the module in the 'modules' file. This is**\n- **File: cvs.info, Node: Revisions, Next: Branching and merging, Prev: Starting a new project, Up: Top**\n- **4 Revisions**\n- **For many uses of CVS, one doesn't need to worry too much about revision**\n- **File: cvs.info, Node: Revision numbers, Next: Versions revisions releases, Up: Revisions** (1 subsections)\n- **By default revision 1.1 is the first revision of a file. Each**\n- **File: cvs.info, Node: Versions revisions releases, Next: Assigning revisions, Prev: Revision numbers, Up: Revisions** (1 subsections)\n- **File: cvs.info, Node: Assigning revisions, Next: Tags, Prev: Versions revisions releases, Up: Revisions** (1 subsections)\n- **By default, CVS will assign numeric revisions by leaving the first**\n- **File: cvs.info, Node: Tags, Next: Tagging the working directory, Prev: Assigning revisions, Up: Revisions** (1 subsections)\n- **The revision numbers live a life of their own. They need not have**\n- **Depending on how you use CVS the revision numbers might change several**\n- **The two tag names 'BASE' and 'HEAD' are reserved for use by CVS. It is** (1 subsections)\n- **This is useful, for instance, if someone claims that there is a bug in**\n- **File: cvs.info, Node: Tagging the working directory, Next: Tagging by date/tag, Prev: Tags, Up: Revisions** (1 subsections)\n- **The example in the previous section demonstrates one of the most common**\n- **If you want to avoid doing this by mistake, specify the '-c' option to**\n- **File: cvs.info, Node: Tagging by date/tag, Next: Modifying tags, Prev: Tagging the working directory, Up: Revisions** (1 subsections)\n- **The 'cvs rtag' command tags the repository as of a certain date or time**\n- **Therefore, you are generally better off using 'cvs rtag'. The**\n- **File: cvs.info, Node: Modifying tags, Next: Tagging add/remove, Prev: Tagging by date/tag, Up: Revisions** (1 subsections)\n- **Normally one does not modify tags. They exist in order to record the**\n- **If any branch tags are encountered in the repository with the given**\n- **File: cvs.info, Node: Tagging add/remove, Next: Sticky tags, Prev: Modifying tags, Up: Revisions** (1 subsections)\n- **The subject of exactly how tagging interacts with adding and removing**\n- **File: cvs.info, Node: Sticky tags, Prev: Tagging add/remove, Up: Revisions** (1 subsections)\n- **Sometimes a working copy's revision has extra data associated with it,** (2 subsections)\n- **VERS: 1.1**\n- **File: cvs.info, Node: Branching and merging, Next: Recursive behavior, Prev: Revisions, Up: Top**\n- **5 Branching and merging**\n- **File: cvs.info, Node: Branches motivation, Next: Creating a branch, Up: Branching and merging** (1 subsections)\n- **Suppose that release 1.0 of tc has been made. You are continuing to**\n- **You can then make modifications to the branch without disturbing the**\n- **File: cvs.info, Node: Creating a branch, Next: Accessing branches, Prev: Branches motivation, Up: Branching and merging** (1 subsections)\n- **You can create a branch with 'tag -b'; for example, assuming you're in a**\n- **File: cvs.info, Node: Accessing branches, Next: Branches and revisions, Prev: Creating a branch, Up: Branching and merging** (1 subsections)\n- **You can retrieve a branch in one of two ways: by checking it out fresh** (1 subsections)\n- **The numbers simply reflect the point in each file's revision history at**\n- **File: cvs.info, Node: Branches and revisions, Next: Magic branch numbers, Prev: Accessing branches, Up: Branching and merging** (1 subsections)\n- **Ordinarily, a file's revision history is a linear series of increments**\n- **File: cvs.info, Node: Magic branch numbers, Next: Merging a branch, Prev: Branches and revisions, Up: Branching and merging** (1 subsections)\n- **File: cvs.info, Node: Merging a branch, Next: Merging more than once, Prev: Magic branch numbers, Up: Branching and merging** (1 subsections)\n- **You can merge changes made on a branch into your working copy by giving**\n- **The branch 1.2.2 has been given the tag (symbolic name) 'R1fix'. The**\n- **File: cvs.info, Node: Merging more than once, Next: Merging two revisions, Prev: Merging a branch, Up: Branching and merging** (1 subsections)\n- **File: cvs.info, Node: Merging two revisions, Next: Merging adds and removals, Prev: Merging more than once, Up: Branching and merging** (1 subsections)\n- **With two '-j REVISION' flags, the 'update' (and 'checkout') command can**\n- **For example, suppose you have a file named 'file1' which existed as**\n- **Now suppose you want to add it again, with the same contents it had**\n- **File: cvs.info, Node: Merging adds and removals, Next: Merging and keywords, Prev: Merging two revisions, Up: Branching and merging** (1 subsections)\n- **If the changes which you are merging involve removing or adding some**\n- **File: cvs.info, Node: Merging and keywords, Prev: Merging adds and removals, Up: Branching and merging** (1 subsections)\n- **Substitution modes::) switch to the merge command line. By substituting** (1 subsections)\n- **File: cvs.info, Node: Recursive behavior, Next: Adding and removing, Prev: Branching and merging, Up: Top**\n- **6 Recursive behavior**\n- **Almost all of the subcommands of CVS work recursively when you specify a**\n- **File: cvs.info, Node: Adding and removing, Next: History browsing, Prev: Recursive behavior, Up: Top**\n- **7 Adding, removing, and renaming files and directories**\n- **In the course of a project, one will often add new files. Likewise with**\n- **File: cvs.info, Node: Adding files, Next: Removing files, Up: Adding and removing** (1 subsections)\n- **File: cvs.info, Node: Removing files, Next: Removing directories, Prev: Adding files, Up: Adding and removing** (1 subsections)\n- **File: cvs.info, Node: Removing directories, Next: Moving files, Prev: Removing files, Up: Adding and removing** (1 subsections)\n- **In concept, removing directories is somewhat similar to removing**\n- **Instead you specify the '-P' option to 'cvs update' or 'cvs checkout',**\n- **Probably the best way to do this is to always specify '-P'; if you want**\n- **This way, CVS will be able to correctly create the directory or not**\n- **File: cvs.info, Node: Moving files, Next: Moving directories, Prev: Removing directories, Up: Adding and removing** (1 subsections)\n- **Moving files to a different directory or renaming them is not difficult,**\n- **File: cvs.info, Node: Outside, Next: Inside, Up: Moving files**\n- **The normal way to move a file is to copy OLD to NEW, and then issue the**\n- **File: cvs.info, Node: Inside, Next: Rename by copying, Prev: Outside, Up: Moving files**\n- **This method is more dangerous, since it involves moving files inside the**\n- **File: cvs.info, Node: Rename by copying, Prev: Inside, Up: Moving files**\n- **This way also involves direct modifications to the repository. It is**\n- **File: cvs.info, Node: Moving directories, Prev: Moving files, Up: Adding and removing** (1 subsections)\n- **The normal way to rename or move a directory is to rename or move each**\n- **File: cvs.info, Node: History browsing, Next: Binary files, Prev: Adding and removing, Up: Top**\n- **8 History browsing**\n- **Once you have used CVS to store a version control history--what files**\n- **File: cvs.info, Node: log messages, Next: history database, Up: History browsing** (1 subsections)\n- **File: cvs.info, Node: history database, Next: user-defined logging, Prev: log messages, Up: History browsing** (1 subsections)\n- **File: cvs.info, Node: user-defined logging, Prev: history database, Up: History browsing** (1 subsections)\n- **You can customise CVS to log various kinds of actions, in whatever**\n- **For a more flexible way of giving notifications to various users, which**\n- **File: cvs.info, Node: Binary files, Next: Multiple developers, Prev: History browsing, Up: Top**\n- **9 Handling binary files**\n- **The most common use for CVS is to store text files. With text files,**\n- **For example, one might store a web site in CVS including both text files**\n- **File: cvs.info, Node: Binary why, Next: Binary howto, Up: Binary files** (1 subsections)\n- **While the need to manage binary files may seem obvious if the files that**\n- **File: cvs.info, Node: Binary howto, Prev: Binary why, Up: Binary files** (1 subsections)\n- **There are two issues with using CVS to store binary files. The first is**\n- **If you need to cope with line endings (that is, you are using CVS on a**\n- **File: cvs.info, Node: Multiple developers, Next: Revision management, Prev: Binary files, Up: Top**\n- **10 Multiple developers**\n- **When more than one person works on a software project things often get**\n- **This is the only solution with some version control systems, including**\n- **File: cvs.info, Node: File status, Next: Updating a file, Up: Multiple developers** (1 subsections)\n- **Based on what operations you have performed on a checked out file, and**\n- **Up-to-date**\n- **Locally Modified**\n- **Locally Added**\n- **Locally Removed**\n- **Needs Checkout**\n- **Needs Patch**\n- **Needs Merge**\n- **Unresolved Conflict**\n- **File had conflicts on merge**\n- **Unknown**\n- **Sticky tags::. For information on its 'Sticky options' output, see the**\n- **File: cvs.info, Node: Updating a file, Next: Conflicts example, Prev: File status, Up: Multiple developers** (1 subsections)\n- **When you want to update or merge a file, use the 'cvs update -d'**\n- **If no newer revision exists, running 'update' has no effect. If you**\n- **File: cvs.info, Node: Conflicts example, Next: Informing others, Prev: Updating a file, Up: Multiple developers** (1 subsections)\n- **Your working copy of 'driver.c', based on revision 1.4, contains this** (1 subsections)\n- **File: cvs.info, Node: Informing others, Next: Concurrency, Prev: Conflicts example, Up: Multiple developers** (1 subsections)\n- **It is often useful to inform others when you commit a new revision of a**\n- **You can use these features of CVS to, for instance, instruct CVS to mail**\n- **File: cvs.info, Node: Concurrency, Next: Watches, Prev: Informing others, Up: Multiple developers** (1 subsections)\n- **If several developers try to run CVS at the same time, one may get the**\n- **If they aren't running a cvs command, look in the repository directory**\n- **File: cvs.info, Node: Watches, Next: Choosing a model, Prev: Concurrency, Up: Multiple developers** (1 subsections)\n- **For many groups, use of CVS in its default mode is perfectly**\n- **File: cvs.info, Node: Setting a watch, Next: Getting Notified, Up: Watches**\n- **To enable the watch features, you first specify that certain files are**\n- **File: cvs.info, Node: Getting Notified, Next: Editing files, Prev: Setting a watch, Up: Watches**\n- **You can tell CVS that you want to receive notifications about various**\n- **File: cvs.info, Node: Editing files, Next: Watch information, Prev: Getting Notified, Up: Watches**\n- **Since a file which is being watched is checked out read-only, you cannot**\n- **File: cvs.info, Node: Watch information, Next: Watches Compatibility, Prev: Editing files, Up: Watches**\n- **File: cvs.info, Node: Watches Compatibility, Prev: Watch information, Up: Watches**\n- **If you use the watch features on a repository, it creates 'CVS'**\n- **File: cvs.info, Node: Choosing a model, Prev: Watches, Up: Multiple developers** (1 subsections)\n- **Reserved and unreserved checkouts each have pros and cons. Let it be**\n- **File: cvs.info, Node: Revision management, Next: Keyword substitution, Prev: Multiple developers, Up: Top**\n- **11 Revision management**\n- **If you have read this far, you probably have a pretty good grasp on what**\n- **File: cvs.info, Node: When to commit, Up: Revision management** (1 subsections)\n- **Your group should decide which policy to use regarding commits. Several**\n- **File: cvs.info, Node: Keyword substitution, Next: Tracking sources, Prev: Revision management, Up: Top**\n- **12 Keyword substitution**\n- **As long as you edit source files inside a working directory you can**\n- **But as soon as you export the files from your development environment it**\n- **File: cvs.info, Node: Keyword list, Next: Using keywords, Up: Keyword substitution** (1 subsections)\n- **File: cvs.info, Node: Using keywords, Next: Avoiding substitution, Prev: Keyword list, Up: Keyword substitution** (1 subsections)\n- **To include a keyword string you simply include the relevant text string,**\n- **Many sites without RCS have SCCS. Since 'what' looks for the character**\n- **File: cvs.info, Node: Avoiding substitution, Next: Substitution modes, Prev: Using keywords, Up: Keyword substitution** (1 subsections)\n- **Keyword substitution has its disadvantages. Sometimes you might want**\n- **File: cvs.info, Node: Substitution modes, Next: Configuring keyword expansion, Prev: Avoiding substitution, Up: Keyword substitution** (1 subsections)\n- **Each file has a stored default substitution mode, and each working**\n- **File: cvs.info, Node: Configuring keyword expansion, Next: Log keyword, Prev: Substitution modes, Up: Keyword substitution** (1 subsections)\n- **In a repository that includes third-party software on vendor branches,**\n- **File: cvs.info, Node: Log keyword, Prev: Configuring keyword expansion, Up: Keyword substitution** (1 subsections)\n- **File: cvs.info, Node: Tracking sources, Next: Builds, Prev: Keyword substitution, Up: Top**\n- **13 Tracking third-party sources**\n- **If you modify a program to better fit your site, you probably want to**\n- **When you import a new file, (usually) the vendor branch is made the**\n- **File: cvs.info, Node: First import, Next: Update imports, Up: Tracking sources** (1 subsections)\n- **When you use the 'import' command to track third-party sources, the**\n- **File: cvs.info, Node: Update imports, Next: Reverting local changes, Prev: First import, Up: Tracking sources** (1 subsections)\n- **When a new release of the source arrives, you import it into the**\n- **The above command will check out the latest revision of 'wdiff', merging**\n- **The reason this is better is that using a date, as suggested above,**\n- **File: cvs.info, Node: Reverting local changes, Next: Binary files in imports, Prev: Update imports, Up: Tracking sources** (1 subsections)\n- **You can also revert local changes completely and return to the latest**\n- **File: cvs.info, Node: Binary files in imports, Next: Keywords in imports, Prev: Reverting local changes, Up: Tracking sources** (1 subsections)\n- **File: cvs.info, Node: Keywords in imports, Next: Multiple vendor branches, Prev: Binary files in imports, Up: Tracking sources** (1 subsections)\n- **File: cvs.info, Node: Multiple vendor branches, Prev: Keywords in imports, Up: Tracking sources** (1 subsections)\n- **All the examples so far assume that there is only one vendor from which**\n- **Be careful; this kind of mismatch is sure to sow confusion or worse. I**\n- **File: cvs.info, Node: Builds, Next: Special Files, Prev: Tracking sources, Up: Top**\n- **14 How your build system interacts with CVS**\n- **As mentioned in the introduction, CVS does not contain software for**\n- **The answer to this with CVS is two-fold. First of all, since CVS itself**\n- **One suggested approach is to first update your sources, then implement,**\n- **File: cvs.info, Node: Special Files, Next: CVS commands, Prev: Builds, Up: Top**\n- **15 Special Files**\n- **In normal circumstances, CVS works only with regular files. Every file**\n- **File: cvs.info, Node: CVS commands, Next: Invoking CVS, Prev: Special Files, Up: Top**\n- **Appendix A Guide to CVS commands**\n- **This appendix describes the overall structure of CVS commands, and**\n- **File: cvs.info, Node: Structure, Next: Exit status, Up: CVS commands** (3 subsections)\n- **There are some 'commandoptions' that are used so often that you might** (1 subsections)\n- **The available 'cvsoptions' (that are given to the left of**\n- **File: cvs.info, Node: Common options, Next: Date input formats, Prev: Global options, Up: CVS commands** (1 subsections)\n- **This section describes the 'commandoptions' that are available across**\n- **File: cvs.info, Node: Date input formats, Next: admin, Prev: Common options, Up: CVS commands** (1 subsections)\n- **File: cvs.info, Node: General date syntax, Next: Calendar date items, Up: Date input formats**\n- **The empty string means the beginning of today (i.e., midnight). Order**\n- **This is most useful for specifying day of the week items or relative**\n- **File: cvs.info, Node: Calendar date items, Next: Time of day items, Prev: General date syntax, Up: Date input formats**\n- **File: cvs.info, Node: Time of day items, Next: Time zone items, Prev: Calendar date items, Up: Date input formats**\n- **File: cvs.info, Node: Time zone items, Next: Day of week items, Prev: Time of day items, Up: Date input formats**\n- **Any included periods are ignored. By following a non-daylight-saving**\n- **File: cvs.info, Node: Day of week items, Next: Relative items in date strings, Prev: Time zone items, Up: Date input formats**\n- **The explicit mention of a day of the week will forward the date (only if**\n- **In this context, 'last DAY' or 'next DAY' is also acceptable; they move**\n- **File: cvs.info, Node: Relative items in date strings, Next: Pure numbers in date strings, Prev: Day of week items, Up: Date input formats**\n- **File: cvs.info, Node: Pure numbers in date strings, Next: Seconds since the Epoch, Prev: Relative items in date strings, Up: Date input formats**\n- **The precise interpretation of a pure decimal number depends on the**\n- **File: cvs.info, Node: Seconds since the Epoch, Next: Authors of getdate, Prev: Pure numbers in date strings, Up: Date input formats**\n- **Epoch and times far in the future. GNU and traditional Unix systems**\n- **Systems with 64-bit signed 'timet' can represent all the times in the**\n- **File: cvs.info, Node: Authors of getdate, Prev: Seconds since the Epoch, Up: Date input formats**\n- **Chapel Hill. The code was later tweaked by a couple of people on**\n- **File: cvs.info, Node: admin, Next: annotate, Prev: Date input formats, Up: CVS commands** (1 subsections)\n- **Some of them have questionable usefulness for CVS but exist for**\n- **Options specified using 'UserAdminOptions' can be run by any user. See**\n- **File: cvs.info, Node: admin options, Up: admin**\n- **Some of these options have questionable usefulness for CVS but exist for**\n- **File: cvs.info, Node: annotate, Next: checkout, Prev: admin, Up: CVS commands** (1 subsections)\n- **File: cvs.info, Node: annotate options, Next: annotate example, Up: annotate**\n- **File: cvs.info, Node: annotate example, Prev: annotate options, Up: annotate**\n- **Annotations for ssfile**\n- **File: cvs.info, Node: checkout, Next: commit, Prev: annotate, Up: CVS commands** (1 subsections)\n- **You can then edit these source files at any time (regardless of whether**\n- **However, 'checkout' takes a module name whereas 'update' takes a**\n- **File: cvs.info, Node: checkout options, Next: checkout examples, Up: checkout**\n- **File: cvs.info, Node: checkout examples, Prev: checkout options, Up: checkout**\n- **File: cvs.info, Node: commit, Next: diff, Prev: checkout, Up: CVS commands** (1 subsections)\n- **By default (or if you explicitly specify the '-R' option), files in**\n- **Debian and MirBSD CVS). FSF GNU CVS 1.11 and OpenBSD OpenCVS do not**\n- **File: cvs.info, Node: commit options, Next: commit examples, Up: commit**\n- **File: cvs.info, Node: commit examples, Prev: commit options, Up: commit**\n- **You can commit to a branch revision (one that has an even number of**\n- **Then, either 'checkout' or 'update' can be used to base your sources on**\n- **Say you have been working on some extremely experimental software, based**\n- **File: cvs.info, Node: diff, Next: export, Prev: commit, Up: CVS commands** (1 subsections)\n- **The default action is to compare your working files with the revisions**\n- **File: cvs.info, Node: diff options, Next: diff examples, Up: diff**\n- **File: cvs.info, Node: Line group formats, Next: Line formats, Up: diff options**\n- **Line group formats let you specify formats suitable for many**\n- **You can specify up to four line group formats, one for each kind of line**\n- **File: cvs.info, Node: Line formats, Prev: Line group formats, Up: diff options**\n- **Line formats control how each line taken from an input file is output as**\n- **File: cvs.info, Node: diff examples, Prev: diff options, Up: diff**\n- **The following line produces a Unidiff ('-u' flag) between revision 1.14**\n- **All local modifications that have not yet been committed will be**\n- **File: cvs.info, Node: export, Next: history, Prev: diff, Up: CVS commands** (1 subsections)\n- **For example, you might use 'export' to prepare source for shipment**\n- **File: cvs.info, Node: export options, Up: export**\n- **File: cvs.info, Node: history, Next: import, Prev: export, Up: CVS commands** (1 subsections)\n- **File: cvs.info, Node: history options, Up: history**\n- **Several options (shown above as '-report') control what kind of report**\n- **File: cvs.info, Node: import, Next: log, Prev: history, Up: CVS commands** (1 subsections)\n- **File: cvs.info, Node: import options, Next: import output, Up: import**\n- **File: cvs.info, Node: import output, Next: import examples, Prev: import options, Up: import**\n- **File: cvs.info, Node: import examples, Prev: import output, Up: import** (1 subsections)\n- **File: cvs.info, Node: log options, Next: log examples, Up: log**\n- **By default, 'log' prints all information that is available. All other**\n- **File: cvs.info, Node: log examples, Prev: log options, Up: log**\n- **Since 'log' shows dates in local time, you might want to see them in**\n- **Coordinated Universal Time (UTC) or some other timezone. To do this you** (2 subsections)\n- **File: cvs.info, Node: rdiff options, Next: rdiff examples, Up: rdiff**\n- **File: cvs.info, Node: rdiff examples, Prev: rdiff options, Up: rdiff** (1 subsections)\n- **Since CVS doesn't lock files, it isn't strictly necessary to use this**\n- **File: cvs.info, Node: release options, Next: release output, Up: release**\n- **File: cvs.info, Node: release output, Next: release examples, Prev: release options, Up: release**\n- **Before 'release' releases your sources it will print a one-line message**\n- **File: cvs.info, Node: release examples, Prev: release output, Up: release**\n- **Release the 'tc' directory, and delete your local working copy of the** (2 subsections)\n- **File: cvs.info, Node: update, Prev: suck, Up: CVS commands** (1 subsections)\n- **File: cvs.info, Node: update options, Next: update output, Up: update**\n- **File: cvs.info, Node: update output, Prev: update options, Up: update**\n- **File: cvs.info, Node: Invoking CVS, Next: Administrative files, Prev: CVS commands, Up: Top**\n- **Appendix B Quick reference to CVS commands**\n- **This appendix describes how to invoke CVS, with references to where each**\n- **File: cvs.info, Node: Administrative files, Next: Environment variables, Prev: Invoking CVS, Up: Top**\n- **Appendix C Reference manual for Administrative files**\n- **File: cvs.info, Node: modules, Next: Wrappers, Up: Administrative files** (1 subsections)\n- **The 'modules' file records your definitions of names for collections of**\n- **In all of the following examples, the top-level repository contains a**\n- **File: cvs.info, Node: Alias modules, Next: Regular modules, Up: modules**\n- **File: cvs.info, Node: Regular modules, Next: Ampersand modules, Prev: Alias modules, Up: modules**\n- **With this definition, getting the regfiles module will create a single**\n- **File: cvs.info, Node: Ampersand modules, Next: Excluding directories, Prev: Regular modules, Up: modules**\n- **File: cvs.info, Node: Excluding directories, Next: Module options, Prev: Ampersand modules, Up: modules**\n- **An alias module may exclude particular directories from other modules by**\n- **File: cvs.info, Node: Module options, Next: Module program options, Prev: Excluding directories, Up: modules**\n- **Either regular modules or ampersand modules can contain options, which**\n- **File: cvs.info, Node: Module program options, Prev: Module options, Up: modules**\n- **For checkout, rtag, and export, the program is server-based, and as such**\n- **File: cvs.info, Node: Wrappers, Next: Trigger Scripts, Prev: modules, Up: Administrative files** (1 subsections)\n- **Wrappers refers to a CVS feature which lets you control certain settings**\n- **File: cvs.info, Node: Trigger Scripts, Next: rcsinfo, Prev: Wrappers, Up: Administrative files** (1 subsections)\n- **Several of the administrative files support triggers, or the launching**\n- **File: cvs.info, Node: syntax, Next: Trigger Script Security, Up: Trigger Scripts**\n- **The administrative files such as 'commitinfo', 'loginfo', 'rcsinfo',**\n- **Note: The following information on format strings is valid as long as**\n- **File: cvs.info, Node: Trigger Script Security, Next: commit files, Prev: syntax, Up: Trigger Scripts**\n- **Security is a huge subject, and implementing a secure system is a**\n- **File: cvs.info, Node: commit files, Next: commitinfo, Prev: Trigger Script Security, Up: Trigger Scripts**\n- **The '-i' flag in the 'modules' file can be used to run a certain program**\n- **File: cvs.info, Node: Updating Commit Files, Up: commit files**\n- **New repositories are created set to use the new format strings by**\n- **File: cvs.info, Node: commitinfo, Next: verifymsg, Prev: commit files, Up: Trigger Scripts**\n- **The 'commitinfo' file defines programs to execute whenever 'cvs commit'**\n- **Trigger Scripts::), where each line is a regular expression followed by**\n- **If a file is being removed, there will be no copy of the file under the**\n- **File: cvs.info, Node: verifymsg, Next: loginfo, Prev: commitinfo, Up: Trigger Scripts**\n- **Once you have entered a log message, you can evaluate that message to**\n- **File: cvs.info, Node: verifymsg example, Up: verifymsg**\n- **The following is a little silly example of a 'verifymsg' file, together**\n- **The rest of log message is free text. The following template is found**\n- **File: cvs.info, Node: loginfo, Next: postadmin, Prev: verifymsg, Up: Trigger Scripts**\n- **The 'loginfo' file is used to control where log information is sent**\n- **File: cvs.info, Node: loginfo example, Next: Keeping a checked out copy, Up: loginfo**\n- **The following 'loginfo' file, together with the tiny shell-script below,**\n- **File: cvs.info, Node: Keeping a checked out copy, Prev: loginfo example, Up: loginfo**\n- **It is often useful to maintain a directory tree which contains files**\n- **File: cvs.info, Node: postadmin, Next: taginfo, Prev: loginfo, Up: Trigger Scripts**\n- **The 'postadmin' file defines programs to execute after an 'admin'**\n- **File: cvs.info, Node: taginfo, Next: posttag, Prev: postadmin, Up: Trigger Scripts**\n- **The 'taginfo' file defines programs to execute when someone executes a**\n- **File: cvs.info, Node: posttag, Next: postwatch, Prev: taginfo, Up: Trigger Scripts**\n- **The 'posttag' file defines programs to execute after a 'tag' or 'rtag'**\n- **File: cvs.info, Node: postwatch, Next: preproxy, Prev: posttag, Up: Trigger Scripts**\n- **The 'postwatch' file defines programs to execute after any command (for**\n- **Scripts::), where each line is a regular expression followed by a**\n- **File: cvs.info, Node: preproxy, Next: postproxy, Prev: postwatch, Up: Trigger Scripts**\n- **The 'preproxy' file defines programs to execute after a secondary server**\n- **File: cvs.info, Node: postproxy, Prev: preproxy, Up: Trigger Scripts**\n- **The 'postproxy' file defines programs to execute after a secondary**\n- **File: cvs.info, Node: rcsinfo, Next: cvsignore, Prev: Trigger Scripts, Up: Administrative files** (1 subsections)\n- **The 'rcsinfo' file can be used to specify a form to edit when filling**\n- **Instead, the part after the regular expression should be a full pathname**\n- **This template will be updated on all 'cvs update' commands. It will**\n- **File: cvs.info, Node: cvsignore, Next: checkoutlist, Prev: rcsinfo, Up: Administrative files** (1 subsections)\n- **There are certain file names that frequently occur inside your working**\n- **Normally, when you run 'cvs update', it prints a line for each file it**\n- **File: cvs.info, Node: checkoutlist, Next: history file, Prev: cvsignore, Up: Administrative files** (1 subsections)\n- **It may be helpful to use CVS to maintain your own files in the 'CVSROOT'**\n- **File: cvs.info, Node: history file, Next: Variables, Prev: checkoutlist, Up: Administrative files** (1 subsections)\n- **File: cvs.info, Node: Variables, Next: config, Prev: history file, Up: Administrative files** (1 subsections)\n- **Sometimes in writing an administrative file, you might want the file to**\n- **File: cvs.info, Node: config, Prev: Variables, Up: Administrative files** (1 subsections)\n- **Extraneous spaces or tabs, other than the leading white space, are not**\n- **File: cvs.info, Node: Environment variables, Next: Compatibility, Prev: Administrative files, Up: Top**\n- **Appendix D All environment variables which affect CVS**\n- **This is a complete list of all environment variables that affect CVS**\n- **File: cvs.info, Node: Compatibility, Next: Troubleshooting, Prev: Environment variables, Up: Top**\n- **Appendix E Compatibility between CVS Versions**\n- **The repository format is compatible going back to CVS 1.3. But see**\n- **File: cvs.info, Node: Troubleshooting, Next: Credits, Prev: Compatibility, Up: Top**\n- **Appendix F Troubleshooting**\n- **If you are having trouble with CVS, this appendix may help. If there is**\n- **File: cvs.info, Node: Error messages, Next: Connection, Up: Troubleshooting** (1 subsections)\n- **Here is a partial list of error messages that you may see from CVS. It**\n- **File: cvs.info, Node: Connection, Next: Other problems, Prev: Error messages, Up: Troubleshooting** (1 subsections)\n- **This section concerns what to do if you are having trouble making a**\n- **File: cvs.info, Node: Other problems, Prev: Connection, Up: Troubleshooting** (1 subsections)\n- **File: cvs.info, Node: Credits, Next: BUGS, Prev: Troubleshooting, Up: Top**\n- **Appendix G Credits**\n- **File: cvs.info, Node: BUGS, Next: CVS command list, Prev: Credits, Up: Top**\n- **Appendix H Dealing with bugs in CVS or this manual**\n- **If you are having trouble using CVS, or think you have found a bug,**\n- **File: cvs.info, Node: CVS command list, Next: Index, Prev: BUGS, Up: Top**\n- **Appendix I Alphabetical list of all CVS commands**\n- **File: cvs.info, Node: Index, Prev: CVS command list, Up: Top**\n- **Index**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "cvs", "section": "", "mode": "info", "summary": null, "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "File: cvs.info, Node: Top, Next: Overview, Up: (dir)", "lines": 1, "subsections": [] }, { "name": "CVS--Concurrent Versions System v1.12.13", "lines": 1, "subsections": [] }, { "name": "This info manual describes how to use and administer CVS version", "lines": 2, "subsections": [] }, { "name": "Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,", "lines": 2, "subsections": [] }, { "name": "Portions", "lines": 53, "subsections": [] }, { "name": "File: cvs.info, Node: Overview, Next: Repository, Prev: Top, Up: Top", "lines": 1, "subsections": [] }, { "name": "1 Overview", "lines": 1, "subsections": [] }, { "name": "This chapter is for people who have never used CVS, and perhaps have", "lines": 14, "subsections": [ { "name": "1.1 What is CVS?", "lines": 17 } ] }, { "name": "Unfortunately, if someone is using another editor, that safeguard will", "lines": 6, "subsections": [] }, { "name": "July, 1986. While no actual code from these shell scripts is present in", "lines": 33, "subsections": [ { "name": "1.2 What is CVS not?", "lines": 117 }, { "name": "1.3 A sample session", "lines": 1 } ] }, { "name": "As a way of introducing CVS, we'll go through a typical work-session", "lines": 16, "subsections": [] }, { "name": "File: cvs.info, Node: Getting the source, Next: Committing your changes, Up: A sample session", "lines": 1, "subsections": [] }, { "name": "The first thing you must do is to get your own working copy of the", "lines": 4, "subsections": [] }, { "name": "This will create a new directory called 'tc' and populate it with the", "lines": 15, "subsections": [] }, { "name": "File: cvs.info, Node: Committing your changes, Next: Cleaning up, Prev: Getting the source, Up: A sample session", "lines": 1, "subsections": [] }, { "name": "When you have checked that the compiler is still compilable you decide", "lines": 39, "subsections": [] }, { "name": "File: cvs.info, Node: Cleaning up, Next: Viewing differences, Prev: Committing your changes, Up: A sample session", "lines": 1, "subsections": [] }, { "name": "Before you turn to other tasks you decide to remove your working copy of", "lines": 40, "subsections": [] }, { "name": "File: cvs.info, Node: Viewing differences, Prev: Cleaning up, Up: A sample session", "lines": 1, "subsections": [] }, { "name": "You do not remember modifying 'driver.c', so you want to see what has", "lines": 21, "subsections": [] }, { "name": "File: cvs.info, Node: Repository, Next: Starting a new project, Prev: Overview, Up: Top", "lines": 1, "subsections": [] }, { "name": "2 The Repository", "lines": 49, "subsections": [] }, { "name": "File: cvs.info, Node: Specifying a repository, Next: Repository storage, Up: Repository", "lines": 1, "subsections": [ { "name": "2.1 Telling CVS where your repository is", "lines": 1 } ] }, { "name": "There are several ways to tell CVS where to find the repository. You", "lines": 28, "subsections": [] }, { "name": "File: cvs.info, Node: Repository storage, Next: Working directory storage, Prev: Specifying a repository, Up: Repository", "lines": 1, "subsections": [ { "name": "2.2 How data is stored in the repository", "lines": 1 } ] }, { "name": "For most purposes it isn't important how CVS stores information in the", "lines": 19, "subsections": [] }, { "name": "File: cvs.info, Node: Repository files, Next: File permissions, Up: Repository storage", "lines": 1, "subsections": [] }, { "name": "The overall structure of the repository is a directory tree", "lines": 76, "subsections": [] }, { "name": "File: cvs.info, Node: File permissions, Next: Windows permissions, Prev: Repository files, Up: Repository storage", "lines": 1, "subsections": [] }, { "name": "All ',v' files are created read-only, and you should not change the", "lines": 66, "subsections": [] }, { "name": "File: cvs.info, Node: Windows permissions, Next: Attic, Prev: File permissions, Up: Repository storage", "lines": 1, "subsections": [] }, { "name": "Some file permission issues are specific to Windows operating systems", "lines": 12, "subsections": [] }, { "name": "File: cvs.info, Node: Attic, Next: CVS in repository, Prev: Windows permissions, Up: Repository storage", "lines": 1, "subsections": [] }, { "name": "For example, if the CVSROOT is '/usr/local/cvsroot' and we are talking", "lines": 18, "subsections": [] }, { "name": "File: cvs.info, Node: CVS in repository, Next: Locks, Prev: Attic, Up: Repository storage", "lines": 1, "subsections": [] }, { "name": "The 'CVS' directory in each repository directory contains information", "lines": 63, "subsections": [] }, { "name": "The file 'file2' should be checked out read-only; sue started editing it", "lines": 6, "subsections": [] }, { "name": "File: cvs.info, Node: Locks, Next: CVSROOT storage, Prev: CVS in repository, Up: Repository storage", "lines": 1, "subsections": [] }, { "name": "For an introduction to CVS locks focusing on user-visible behavior, see", "lines": 79, "subsections": [] }, { "name": "File: cvs.info, Node: CVSROOT storage, Prev: Locks, Up: Repository storage", "lines": 32, "subsections": [] }, { "name": "File: cvs.info, Node: Working directory storage, Next: Intro administrative files, Prev: Repository storage, Up: Repository", "lines": 1, "subsections": [ { "name": "2.3 How data is stored in the working directory", "lines": 1 } ] }, { "name": "While we are discussing CVS internals which may become visible from time", "lines": 3, "subsections": [] }, { "name": "But in some cases it may be useful to look at it, and other programs,", "lines": 190, "subsections": [] }, { "name": "File: cvs.info, Node: Intro administrative files, Next: Multiple repositories, Prev: Working directory storage, Up: Repository", "lines": 1, "subsections": [ { "name": "2.4 The administrative files", "lines": 25 } ] }, { "name": "You edit the administrative files in the same way that you would edit", "lines": 8, "subsections": [] }, { "name": "File: cvs.info, Node: Multiple repositories, Next: Creating a repository, Prev: Intro administrative files, Up: Repository", "lines": 1, "subsections": [ { "name": "2.5 Multiple repositories", "lines": 1 } ] }, { "name": "In some situations it is a good idea to have more than one repository,", "lines": 26, "subsections": [] }, { "name": "File: cvs.info, Node: Creating a repository, Next: Backing up, Prev: Multiple repositories, Up: Repository", "lines": 1, "subsections": [ { "name": "2.6 Creating a repository", "lines": 1 } ] }, { "name": "This section describes how to set up a CVS repository for any sort of", "lines": 38, "subsections": [] }, { "name": "Repository::). For example,", "lines": 17, "subsections": [] }, { "name": "File: cvs.info, Node: Backing up, Next: Moving a repository, Prev: Creating a repository, Up: Repository", "lines": 1, "subsections": [ { "name": "2.7 Backing up a repository", "lines": 1 } ] }, { "name": "There is nothing particularly magical about the files in the repository;", "lines": 7, "subsections": [] }, { "name": "The details would depend on your operating system and how you have CVS", "lines": 2, "subsections": [] }, { "name": "Having said all this, if you just back up without any of these", "lines": 1, "subsections": [] }, { "name": "Restoring from backup, the repository might be in an inconsistent state,", "lines": 19, "subsections": [] }, { "name": "File: cvs.info, Node: Moving a repository, Next: Remote repositories, Prev: Backing up, Up: Repository", "lines": 1, "subsections": [ { "name": "2.8 Moving a repository", "lines": 1 } ] }, { "name": "Just as backing up the files in the repository is pretty much like", "lines": 15, "subsections": [] }, { "name": "File: cvs.info, Node: Remote repositories, Next: Read-only access, Prev: Moving a repository, Up: Repository", "lines": 1, "subsections": [ { "name": "2.9 Remote repositories", "lines": 1 } ] }, { "name": "Your working copy of the sources can be on a different machine than the", "lines": 4, "subsections": [] }, { "name": "Generally, using a remote repository is just like using a local one,", "lines": 26, "subsections": [] }, { "name": "File: cvs.info, Node: Server requirements, Next: The connection method, Up: Remote repositories", "lines": 1, "subsections": [] }, { "name": "The quick answer to what sort of machine is suitable as a server is that", "lines": 31, "subsections": [] }, { "name": "This can be swap space rather than physical memory. Because the memory", "lines": 10, "subsections": [] }, { "name": "File: cvs.info, Node: The connection method, Next: Connecting via rsh, Prev: Server requirements, Up: Remote repositories", "lines": 1, "subsections": [] }, { "name": "Remote repositories::) may be one of 'ext', 'fork', 'gserver',", "lines": 105, "subsections": [] }, { "name": "File: cvs.info, Node: Connecting via rsh, Next: Password authenticated, Prev: The connection method, Up: Remote repositories", "lines": 12, "subsections": [] }, { "name": "Then test that 'rsh' is working with", "lines": 55, "subsections": [] }, { "name": "File: cvs.info, Node: Password authenticated, Next: GSSAPI authenticated, Prev: Connecting via rsh, Up: Remote repositories", "lines": 1, "subsections": [] }, { "name": "This is particularly useful if using 'rsh' is not feasible (for example,", "lines": 11, "subsections": [] }, { "name": "File: cvs.info, Node: Password authentication server, Next: Password authentication client, Up: Password authenticated", "lines": 3, "subsections": [] }, { "name": "First of all, you probably want to tighten the permissions on the", "lines": 21, "subsections": [] }, { "name": "Clients which attempt to use a different CVSROOT directory will not be", "lines": 59, "subsections": [] }, { "name": "Unix '/etc/passwd' files.)", "lines": 44, "subsections": [] }, { "name": "When the password field is omitted or empty, then the client's", "lines": 15, "subsections": [] }, { "name": "Modules) and your CVS server executable was configured to use it at", "lines": 88, "subsections": [] }, { "name": "File: cvs.info, Node: Password authentication client, Next: Password authentication security, Prev: Password authentication server, Up: Password authenticated", "lines": 3, "subsections": [] }, { "name": "To run a CVS command on a remote repository via the", "lines": 33, "subsections": [] }, { "name": "That file's format is human-readable, and to a degree human-editable,", "lines": 32, "subsections": [] }, { "name": "File: cvs.info, Node: Password authentication security, Prev: Password authentication client, Up: Password authenticated", "lines": 3, "subsections": [] }, { "name": "The passwords are stored on the client side in a trivial encoding of the", "lines": 28, "subsections": [] }, { "name": "File: cvs.info, Node: GSSAPI authenticated, Next: Kerberos authenticated, Prev: Password authenticated, Up: Remote repositories", "lines": 1, "subsections": [] }, { "name": "Kerberos 5. If you have a working GSSAPI library, you can have CVS", "lines": 4, "subsections": [] }, { "name": "Kerberos version 5 are present. You can also use the '--with-gssapi'", "lines": 14, "subsections": [] }, { "name": "Kerberos which provides for strong authentication, you will probably", "lines": 12, "subsections": [] }, { "name": "File: cvs.info, Node: Kerberos authenticated, Next: Connecting via fork, Prev: GSSAPI authenticated, Up: Remote repositories", "lines": 1, "subsections": [] }, { "name": "The easiest way to use Kerberos is to use the Kerberos 'rsh', as", "lines": 29, "subsections": [] }, { "name": "File: cvs.info, Node: Connecting via fork, Next: Write proxies, Prev: Kerberos authenticated, Up: Remote repositories", "lines": 1, "subsections": [] }, { "name": "This access method allows you to connect to a repository on your local", "lines": 20, "subsections": [] }, { "name": "File: cvs.info, Node: Write proxies, Prev: Connecting via fork, Up: Remote repositories", "lines": 62, "subsections": [] }, { "name": "File: cvs.info, Node: Read-only access, Next: Server temporary directory, Prev: Remote repositories, Up: Repository", "lines": 1, "subsections": [ { "name": "2.10 Read-only repository access", "lines": 1 } ] }, { "name": "It is possible to grant read-only repository access to people using the", "lines": 46, "subsections": [] }, { "name": "That is, the 'readers' and 'writers' files contain cvs usernames, which", "lines": 12, "subsections": [] }, { "name": "This is resolved in the more conservative way, it being better to", "lines": 3, "subsections": [] }, { "name": "File: cvs.info, Node: Server temporary directory, Prev: Read-only access, Up: Repository", "lines": 1, "subsections": [ { "name": "2.11 Temporary directories for the server", "lines": 1 } ] }, { "name": "While running, the CVS server creates temporary directories. They are", "lines": 27, "subsections": [] }, { "name": "File: cvs.info, Node: Starting a new project, Next: Revisions, Prev: Repository, Up: Top", "lines": 1, "subsections": [] }, { "name": "3 Starting a project with CVS", "lines": 1, "subsections": [] }, { "name": "Because renaming files and moving them between directories is somewhat", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: Setting up the files, Next: Defining the module, Up: Starting a new project", "lines": 1, "subsections": [ { "name": "3.1 Setting up the files", "lines": 1 } ] }, { "name": "The first step is to create the files inside the repository. This can", "lines": 10, "subsections": [] }, { "name": "File: cvs.info, Node: From files, Next: From other version control systems, Up: Setting up the files", "lines": 1, "subsections": [] }, { "name": "When you begin using CVS, you will probably already have several", "lines": 23, "subsections": [] }, { "name": "Erasing the original sources is a good idea, to make sure that you do", "lines": 16, "subsections": [] }, { "name": "File: cvs.info, Node: From other version control systems, Next: From scratch, Prev: From files, Up: Setting up the files", "lines": 1, "subsections": [] }, { "name": "If you have a project which you are maintaining with another version", "lines": 19, "subsections": [] }, { "name": "From another version control system", "lines": 25, "subsections": [] }, { "name": "File: cvs.info, Node: From scratch, Prev: From other version control systems, Up: Setting up the files", "lines": 1, "subsections": [] }, { "name": "For a new project, the easiest thing to do is probably to create an", "lines": 23, "subsections": [] }, { "name": "File: cvs.info, Node: Defining the module, Prev: Setting up the files, Up: Starting a new project", "lines": 1, "subsections": [ { "name": "3.2 Defining the module", "lines": 1 } ] }, { "name": "The next step is to define the module in the 'modules' file. This is", "lines": 26, "subsections": [] }, { "name": "File: cvs.info, Node: Revisions, Next: Branching and merging, Prev: Starting a new project, Up: Top", "lines": 1, "subsections": [] }, { "name": "4 Revisions", "lines": 1, "subsections": [] }, { "name": "For many uses of CVS, one doesn't need to worry too much about revision", "lines": 21, "subsections": [] }, { "name": "File: cvs.info, Node: Revision numbers, Next: Versions revisions releases, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.1 Revision numbers", "lines": 3 } ] }, { "name": "By default revision 1.1 is the first revision of a file. Each", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: Versions revisions releases, Next: Assigning revisions, Prev: Revision numbers, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.2 Versions, revisions and releases", "lines": 8 } ] }, { "name": "File: cvs.info, Node: Assigning revisions, Next: Tags, Prev: Versions revisions releases, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.3 Assigning revisions", "lines": 1 } ] }, { "name": "By default, CVS will assign numeric revisions by leaving the first", "lines": 29, "subsections": [] }, { "name": "File: cvs.info, Node: Tags, Next: Tagging the working directory, Prev: Assigning revisions, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.4 Tags-Symbolic revisions", "lines": 1 } ] }, { "name": "The revision numbers live a life of their own. They need not have", "lines": 1, "subsections": [] }, { "name": "Depending on how you use CVS the revision numbers might change several", "lines": 21, "subsections": [] }, { "name": "The two tag names 'BASE' and 'HEAD' are reserved for use by CVS. It is", "lines": 20, "subsections": [ { "name": "$ cvs status -v backend.c", "lines": 39 } ] }, { "name": "This is useful, for instance, if someone claims that there is a bug in", "lines": 37, "subsections": [] }, { "name": "File: cvs.info, Node: Tagging the working directory, Next: Tagging by date/tag, Prev: Tags, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.5 Specifying what to tag from the working directory", "lines": 1 } ] }, { "name": "The example in the previous section demonstrates one of the most common", "lines": 13, "subsections": [] }, { "name": "If you want to avoid doing this by mistake, specify the '-c' option to", "lines": 7, "subsections": [] }, { "name": "File: cvs.info, Node: Tagging by date/tag, Next: Modifying tags, Prev: Tagging the working directory, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.6 Specifying what to tag by date or revision", "lines": 1 } ] }, { "name": "The 'cvs rtag' command tags the repository as of a certain date or time", "lines": 25, "subsections": [] }, { "name": "Therefore, you are generally better off using 'cvs rtag'. The", "lines": 4, "subsections": [] }, { "name": "File: cvs.info, Node: Modifying tags, Next: Tagging add/remove, Prev: Tagging by date/tag, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.7 Deleting, moving, and renaming tags", "lines": 1 } ] }, { "name": "Normally one does not modify tags. They exist in order to record the", "lines": 39, "subsections": [] }, { "name": "If any branch tags are encountered in the repository with the given", "lines": 21, "subsections": [] }, { "name": "File: cvs.info, Node: Tagging add/remove, Next: Sticky tags, Prev: Modifying tags, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.8 Tagging and adding and removing files", "lines": 1 } ] }, { "name": "The subject of exactly how tagging interacts with adding and removing", "lines": 24, "subsections": [] }, { "name": "File: cvs.info, Node: Sticky tags, Prev: Tagging add/remove, Up: Revisions", "lines": 1, "subsections": [ { "name": "4.9 Sticky tags", "lines": 1 } ] }, { "name": "Sometimes a working copy's revision has extra data associated with it,", "lines": 13, "subsections": [ { "name": "$ cvs status driver.c", "lines": 32 }, { "name": "$ cvs update -p -r 1.1 file1 >file1", "lines": 2 } ] }, { "name": "VERS: 1.1", "lines": 7, "subsections": [] }, { "name": "File: cvs.info, Node: Branching and merging, Next: Recursive behavior, Prev: Revisions, Up: Top", "lines": 1, "subsections": [] }, { "name": "5 Branching and merging", "lines": 23, "subsections": [] }, { "name": "File: cvs.info, Node: Branches motivation, Next: Creating a branch, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.1 What branches are good for", "lines": 1 } ] }, { "name": "Suppose that release 1.0 of tc has been made. You are continuing to", "lines": 10, "subsections": [] }, { "name": "You can then make modifications to the branch without disturbing the", "lines": 3, "subsections": [] }, { "name": "File: cvs.info, Node: Creating a branch, Next: Accessing branches, Prev: Branches motivation, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.2 Creating a branch", "lines": 1 } ] }, { "name": "You can create a branch with 'tag -b'; for example, assuming you're in a", "lines": 33, "subsections": [] }, { "name": "File: cvs.info, Node: Accessing branches, Next: Branches and revisions, Prev: Creating a branch, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.3 Accessing branches", "lines": 1 } ] }, { "name": "You can retrieve a branch in one of two ways: by checking it out fresh", "lines": 35, "subsections": [ { "name": "$ cvs status -v driver.c backend.c", "lines": 30 } ] }, { "name": "The numbers simply reflect the point in each file's revision history at", "lines": 7, "subsections": [] }, { "name": "File: cvs.info, Node: Branches and revisions, Next: Magic branch numbers, Prev: Accessing branches, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.4 Branches and revisions", "lines": 1 } ] }, { "name": "Ordinarily, a file's revision history is a linear series of increments", "lines": 50, "subsections": [] }, { "name": "File: cvs.info, Node: Magic branch numbers, Next: Merging a branch, Prev: Branches and revisions, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.5 Magic branch numbers", "lines": 29 } ] }, { "name": "File: cvs.info, Node: Merging a branch, Next: Merging more than once, Prev: Magic branch numbers, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.6 Merging an entire branch", "lines": 1 } ] }, { "name": "You can merge changes made on a branch into your working copy by giving", "lines": 19, "subsections": [] }, { "name": "The branch 1.2.2 has been given the tag (symbolic name) 'R1fix'. The", "lines": 30, "subsections": [] }, { "name": "File: cvs.info, Node: Merging more than once, Next: Merging two revisions, Prev: Merging a branch, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.7 Merging from a branch several times", "lines": 50 } ] }, { "name": "File: cvs.info, Node: Merging two revisions, Next: Merging adds and removals, Prev: Merging more than once, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.8 Merging differences between any two revisions", "lines": 1 } ] }, { "name": "With two '-j REVISION' flags, the 'update' (and 'checkout') command can", "lines": 13, "subsections": [] }, { "name": "For example, suppose you have a file named 'file1' which existed as", "lines": 1, "subsections": [] }, { "name": "Now suppose you want to add it again, with the same contents it had", "lines": 11, "subsections": [] }, { "name": "File: cvs.info, Node: Merging adds and removals, Next: Merging and keywords, Prev: Merging two revisions, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.9 Merging can add or remove files", "lines": 1 } ] }, { "name": "If the changes which you are merging involve removing or adding some", "lines": 26, "subsections": [] }, { "name": "File: cvs.info, Node: Merging and keywords, Prev: Merging adds and removals, Up: Branching and merging", "lines": 1, "subsections": [ { "name": "5.10 Merging and keywords", "lines": 6 } ] }, { "name": "Substitution modes::) switch to the merge command line. By substituting", "lines": 30, "subsections": [ { "name": "key $Revision: 1.2 $", "lines": 45 } ] }, { "name": "File: cvs.info, Node: Recursive behavior, Next: Adding and removing, Prev: Branching and merging, Up: Top", "lines": 1, "subsections": [] }, { "name": "6 Recursive behavior", "lines": 1, "subsections": [] }, { "name": "Almost all of the subcommands of CVS work recursively when you specify a", "lines": 49, "subsections": [] }, { "name": "File: cvs.info, Node: Adding and removing, Next: History browsing, Prev: Recursive behavior, Up: Top", "lines": 1, "subsections": [] }, { "name": "7 Adding, removing, and renaming files and directories", "lines": 1, "subsections": [] }, { "name": "In the course of a project, one will often add new files. Likewise with", "lines": 14, "subsections": [] }, { "name": "File: cvs.info, Node: Adding files, Next: Removing files, Up: Adding and removing", "lines": 1, "subsections": [ { "name": "7.1 Adding files to a directory", "lines": 65 } ] }, { "name": "File: cvs.info, Node: Removing files, Next: Removing directories, Prev: Adding files, Up: Adding and removing", "lines": 1, "subsections": [ { "name": "7.2 Removing files", "lines": 88 } ] }, { "name": "File: cvs.info, Node: Removing directories, Next: Moving files, Prev: Removing files, Up: Adding and removing", "lines": 1, "subsections": [ { "name": "7.3 Removing directories", "lines": 1 } ] }, { "name": "In concept, removing directories is somewhat similar to removing", "lines": 6, "subsections": [] }, { "name": "Instead you specify the '-P' option to 'cvs update' or 'cvs checkout',", "lines": 2, "subsections": [] }, { "name": "Probably the best way to do this is to always specify '-P'; if you want", "lines": 4, "subsections": [] }, { "name": "This way, CVS will be able to correctly create the directory or not", "lines": 3, "subsections": [] }, { "name": "File: cvs.info, Node: Moving files, Next: Moving directories, Prev: Removing directories, Up: Adding and removing", "lines": 1, "subsections": [ { "name": "7.4 Moving and renaming files", "lines": 1 } ] }, { "name": "Moving files to a different directory or renaming them is not difficult,", "lines": 11, "subsections": [] }, { "name": "File: cvs.info, Node: Outside, Next: Inside, Up: Moving files", "lines": 1, "subsections": [] }, { "name": "The normal way to move a file is to copy OLD to NEW, and then issue the", "lines": 18, "subsections": [] }, { "name": "File: cvs.info, Node: Inside, Next: Rename by copying, Prev: Outside, Up: Moving files", "lines": 1, "subsections": [] }, { "name": "This method is more dangerous, since it involves moving files inside the", "lines": 23, "subsections": [] }, { "name": "File: cvs.info, Node: Rename by copying, Prev: Inside, Up: Moving files", "lines": 1, "subsections": [] }, { "name": "This way also involves direct modifications to the repository. It is", "lines": 32, "subsections": [] }, { "name": "File: cvs.info, Node: Moving directories, Prev: Moving files, Up: Adding and removing", "lines": 1, "subsections": [ { "name": "7.5 Moving and renaming directories", "lines": 1 } ] }, { "name": "The normal way to rename or move a directory is to rename or move each", "lines": 31, "subsections": [] }, { "name": "File: cvs.info, Node: History browsing, Next: Binary files, Prev: Adding and removing, Up: Top", "lines": 1, "subsections": [] }, { "name": "8 History browsing", "lines": 1, "subsections": [] }, { "name": "Once you have used CVS to store a version control history--what files", "lines": 9, "subsections": [] }, { "name": "File: cvs.info, Node: log messages, Next: history database, Up: History browsing", "lines": 1, "subsections": [ { "name": "8.1 Log messages", "lines": 6 } ] }, { "name": "File: cvs.info, Node: history database, Next: user-defined logging, Prev: log messages, Up: History browsing", "lines": 1, "subsections": [ { "name": "8.2 The history database", "lines": 7 } ] }, { "name": "File: cvs.info, Node: user-defined logging, Prev: history database, Up: History browsing", "lines": 1, "subsections": [ { "name": "8.3 User-defined logging", "lines": 1 } ] }, { "name": "You can customise CVS to log various kinds of actions, in whatever", "lines": 9, "subsections": [] }, { "name": "For a more flexible way of giving notifications to various users, which", "lines": 4, "subsections": [] }, { "name": "File: cvs.info, Node: Binary files, Next: Multiple developers, Prev: History browsing, Up: Top", "lines": 1, "subsections": [] }, { "name": "9 Handling binary files", "lines": 1, "subsections": [] }, { "name": "The most common use for CVS is to store text files. With text files,", "lines": 3, "subsections": [] }, { "name": "For example, one might store a web site in CVS including both text files", "lines": 7, "subsections": [] }, { "name": "File: cvs.info, Node: Binary why, Next: Binary howto, Up: Binary files", "lines": 1, "subsections": [ { "name": "9.1 The issues with binary files", "lines": 1 } ] }, { "name": "While the need to manage binary files may seem obvious if the files that", "lines": 36, "subsections": [] }, { "name": "File: cvs.info, Node: Binary howto, Prev: Binary why, Up: Binary files", "lines": 1, "subsections": [ { "name": "9.2 How to store binary files", "lines": 1 } ] }, { "name": "There are two issues with using CVS to store binary files. The first is", "lines": 35, "subsections": [] }, { "name": "If you need to cope with line endings (that is, you are using CVS on a", "lines": 23, "subsections": [] }, { "name": "File: cvs.info, Node: Multiple developers, Next: Revision management, Prev: Binary files, Up: Top", "lines": 1, "subsections": [] }, { "name": "10 Multiple developers", "lines": 1, "subsections": [] }, { "name": "When more than one person works on a software project things often get", "lines": 3, "subsections": [] }, { "name": "This is the only solution with some version control systems, including", "lines": 40, "subsections": [] }, { "name": "File: cvs.info, Node: File status, Next: Updating a file, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.1 File status", "lines": 1 } ] }, { "name": "Based on what operations you have performed on a checked out file, and", "lines": 4, "subsections": [] }, { "name": "Up-to-date", "lines": 3, "subsections": [] }, { "name": "Locally Modified", "lines": 2, "subsections": [] }, { "name": "Locally Added", "lines": 3, "subsections": [] }, { "name": "Locally Removed", "lines": 3, "subsections": [] }, { "name": "Needs Checkout", "lines": 4, "subsections": [] }, { "name": "Needs Patch", "lines": 4, "subsections": [] }, { "name": "Needs Merge", "lines": 3, "subsections": [] }, { "name": "Unresolved Conflict", "lines": 4, "subsections": [] }, { "name": "File had conflicts on merge", "lines": 4, "subsections": [] }, { "name": "Unknown", "lines": 11, "subsections": [] }, { "name": "Sticky tags::. For information on its 'Sticky options' output, see the", "lines": 17, "subsections": [] }, { "name": "File: cvs.info, Node: Updating a file, Next: Conflicts example, Prev: File status, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.2 Bringing a file up to date", "lines": 1 } ] }, { "name": "When you want to update or merge a file, use the 'cvs update -d'", "lines": 7, "subsections": [] }, { "name": "If no newer revision exists, running 'update' has no effect. If you", "lines": 15, "subsections": [] }, { "name": "File: cvs.info, Node: Conflicts example, Next: Informing others, Prev: Updating a file, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.3 Conflicts example", "lines": 34 } ] }, { "name": "Your working copy of 'driver.c', based on revision 1.4, contains this", "lines": 49, "subsections": [ { "name": "exit(nerr == 0 ? EXITSUCCESS : EXITFAILURE);", "lines": 51 } ] }, { "name": "File: cvs.info, Node: Informing others, Next: Concurrency, Prev: Conflicts example, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.4 Informing others about commits", "lines": 1 } ] }, { "name": "It is often useful to inform others when you commit a new revision of a", "lines": 2, "subsections": [] }, { "name": "You can use these features of CVS to, for instance, instruct CVS to mail", "lines": 2, "subsections": [] }, { "name": "File: cvs.info, Node: Concurrency, Next: Watches, Prev: Informing others, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.5 Several developers simultaneously attempting to run CVS", "lines": 1 } ] }, { "name": "If several developers try to run CVS at the same time, one may get the", "lines": 8, "subsections": [] }, { "name": "If they aren't running a cvs command, look in the repository directory", "lines": 31, "subsections": [] }, { "name": "File: cvs.info, Node: Watches, Next: Choosing a model, Prev: Concurrency, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.6 Mechanisms to track who is editing files", "lines": 1 } ] }, { "name": "For many groups, use of CVS in its default mode is perfectly", "lines": 31, "subsections": [] }, { "name": "File: cvs.info, Node: Setting a watch, Next: Getting Notified, Up: Watches", "lines": 1, "subsections": [] }, { "name": "To enable the watch features, you first specify that certain files are", "lines": 25, "subsections": [] }, { "name": "File: cvs.info, Node: Getting Notified, Next: Editing files, Prev: Setting a watch, Up: Watches", "lines": 1, "subsections": [] }, { "name": "You can tell CVS that you want to receive notifications about various", "lines": 83, "subsections": [] }, { "name": "File: cvs.info, Node: Editing files, Next: Watch information, Prev: Getting Notified, Up: Watches", "lines": 1, "subsections": [] }, { "name": "Since a file which is being watched is checked out read-only, you cannot", "lines": 57, "subsections": [] }, { "name": "File: cvs.info, Node: Watch information, Next: Watches Compatibility, Prev: Editing files, Up: Watches", "lines": 19, "subsections": [] }, { "name": "File: cvs.info, Node: Watches Compatibility, Prev: Watch information, Up: Watches", "lines": 1, "subsections": [] }, { "name": "If you use the watch features on a repository, it creates 'CVS'", "lines": 14, "subsections": [] }, { "name": "File: cvs.info, Node: Choosing a model, Prev: Watches, Up: Multiple developers", "lines": 1, "subsections": [ { "name": "10.7 Choosing between reserved or unreserved checkouts", "lines": 1 } ] }, { "name": "Reserved and unreserved checkouts each have pros and cons. Let it be", "lines": 53, "subsections": [] }, { "name": "File: cvs.info, Node: Revision management, Next: Keyword substitution, Prev: Multiple developers, Up: Top", "lines": 1, "subsections": [] }, { "name": "11 Revision management", "lines": 1, "subsections": [] }, { "name": "If you have read this far, you probably have a pretty good grasp on what", "lines": 11, "subsections": [] }, { "name": "File: cvs.info, Node: When to commit, Up: Revision management", "lines": 1, "subsections": [ { "name": "11.1 When to commit?", "lines": 1 } ] }, { "name": "Your group should decide which policy to use regarding commits. Several", "lines": 18, "subsections": [] }, { "name": "File: cvs.info, Node: Keyword substitution, Next: Tracking sources, Prev: Revision management, Up: Top", "lines": 1, "subsections": [] }, { "name": "12 Keyword substitution", "lines": 1, "subsections": [] }, { "name": "As long as you edit source files inside a working directory you can", "lines": 1, "subsections": [] }, { "name": "But as soon as you export the files from your development environment it", "lines": 17, "subsections": [] }, { "name": "File: cvs.info, Node: Keyword list, Next: Using keywords, Up: Keyword substitution", "lines": 1, "subsections": [ { "name": "12.1 Keyword List", "lines": 133 } ] }, { "name": "File: cvs.info, Node: Using keywords, Next: Avoiding substitution, Prev: Keyword list, Up: Keyword substitution", "lines": 1, "subsections": [ { "name": "12.2 Using keywords", "lines": 1 } ] }, { "name": "To include a keyword string you simply include the relevant text string,", "lines": 27, "subsections": [] }, { "name": "Many sites without RCS have SCCS. Since 'what' looks for the character", "lines": 6, "subsections": [] }, { "name": "File: cvs.info, Node: Avoiding substitution, Next: Substitution modes, Prev: Using keywords, Up: Keyword substitution", "lines": 1, "subsections": [ { "name": "12.3 Avoiding substitution", "lines": 1 } ] }, { "name": "Keyword substitution has its disadvantages. Sometimes you might want", "lines": 20, "subsections": [] }, { "name": "File: cvs.info, Node: Substitution modes, Next: Configuring keyword expansion, Prev: Avoiding substitution, Up: Keyword substitution", "lines": 1, "subsections": [ { "name": "12.4 Substitution modes", "lines": 1 } ] }, { "name": "Each file has a stored default substitution mode, and each working", "lines": 54, "subsections": [] }, { "name": "File: cvs.info, Node: Configuring keyword expansion, Next: Log keyword, Prev: Substitution modes, Up: Keyword substitution", "lines": 1, "subsections": [ { "name": "12.5 Configuring Keyword Expansion", "lines": 1 } ] }, { "name": "In a repository that includes third-party software on vendor branches,", "lines": 65, "subsections": [] }, { "name": "File: cvs.info, Node: Log keyword, Prev: Configuring keyword expansion, Up: Keyword substitution", "lines": 1, "subsections": [ { "name": "12.6 Problems with the $Log$ keyword.", "lines": 19 } ] }, { "name": "File: cvs.info, Node: Tracking sources, Next: Builds, Prev: Keyword substitution, Up: Top", "lines": 1, "subsections": [] }, { "name": "13 Tracking third-party sources", "lines": 1, "subsections": [] }, { "name": "If you modify a program to better fit your site, you probably want to", "lines": 13, "subsections": [] }, { "name": "When you import a new file, (usually) the vendor branch is made the", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: First import, Next: Update imports, Up: Tracking sources", "lines": 1, "subsections": [ { "name": "13.1 Importing for the first time", "lines": 1 } ] }, { "name": "When you use the 'import' command to track third-party sources, the", "lines": 22, "subsections": [] }, { "name": "File: cvs.info, Node: Update imports, Next: Reverting local changes, Prev: First import, Up: Tracking sources", "lines": 1, "subsections": [ { "name": "13.2 Updating with the import command", "lines": 1 } ] }, { "name": "When a new release of the source arrives, you import it into the", "lines": 18, "subsections": [] }, { "name": "The above command will check out the latest revision of 'wdiff', merging", "lines": 10, "subsections": [] }, { "name": "The reason this is better is that using a date, as suggested above,", "lines": 6, "subsections": [] }, { "name": "File: cvs.info, Node: Reverting local changes, Next: Binary files in imports, Prev: Update imports, Up: Tracking sources", "lines": 1, "subsections": [ { "name": "13.3 Reverting to the latest vendor release", "lines": 1 } ] }, { "name": "You can also revert local changes completely and return to the latest", "lines": 15, "subsections": [] }, { "name": "File: cvs.info, Node: Binary files in imports, Next: Keywords in imports, Prev: Reverting local changes, Up: Tracking sources", "lines": 1, "subsections": [ { "name": "13.4 How to handle binary files with cvs import", "lines": 3 } ] }, { "name": "File: cvs.info, Node: Keywords in imports, Next: Multiple vendor branches, Prev: Binary files in imports, Up: Tracking sources", "lines": 1, "subsections": [ { "name": "13.5 How to handle keyword substitution with cvs import", "lines": 15 } ] }, { "name": "File: cvs.info, Node: Multiple vendor branches, Prev: Keywords in imports, Up: Tracking sources", "lines": 1, "subsections": [ { "name": "13.6 Multiple vendor branches", "lines": 1 } ] }, { "name": "All the examples so far assume that there is only one vendor from which", "lines": 29, "subsections": [] }, { "name": "Be careful; this kind of mismatch is sure to sow confusion or worse. I", "lines": 4, "subsections": [] }, { "name": "File: cvs.info, Node: Builds, Next: Special Files, Prev: Tracking sources, Up: Top", "lines": 1, "subsections": [] }, { "name": "14 How your build system interacts with CVS", "lines": 1, "subsections": [] }, { "name": "As mentioned in the introduction, CVS does not contain software for", "lines": 5, "subsections": [] }, { "name": "The answer to this with CVS is two-fold. First of all, since CVS itself", "lines": 6, "subsections": [] }, { "name": "One suggested approach is to first update your sources, then implement,", "lines": 29, "subsections": [] }, { "name": "File: cvs.info, Node: Special Files, Next: CVS commands, Prev: Builds, Up: Top", "lines": 1, "subsections": [] }, { "name": "15 Special Files", "lines": 1, "subsections": [] }, { "name": "In normal circumstances, CVS works only with regular files. Every file", "lines": 8, "subsections": [] }, { "name": "File: cvs.info, Node: CVS commands, Next: Invoking CVS, Prev: Special Files, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix A Guide to CVS commands", "lines": 1, "subsections": [] }, { "name": "This appendix describes the overall structure of CVS commands, and", "lines": 28, "subsections": [] }, { "name": "File: cvs.info, Node: Structure, Next: Exit status, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.1 Overall structure of CVS commands", "lines": 34 }, { "name": "A.2 CVS's exit status", "lines": 17 }, { "name": "A.3 Default options and the ~/.cvsrc file", "lines": 1 } ] }, { "name": "There are some 'commandoptions' that are used so often that you might", "lines": 47, "subsections": [ { "name": "A.4 Global options", "lines": 1 } ] }, { "name": "The available 'cvsoptions' (that are given to the left of", "lines": 167, "subsections": [] }, { "name": "File: cvs.info, Node: Common options, Next: Date input formats, Prev: Global options, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.5 Common command options", "lines": 1 } ] }, { "name": "This section describes the 'commandoptions' that are available across", "lines": 164, "subsections": [] }, { "name": "File: cvs.info, Node: Date input formats, Next: admin, Prev: Common options, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.6 Date input formats", "lines": 43 } ] }, { "name": "File: cvs.info, Node: General date syntax, Next: Calendar date items, Up: Date input formats", "lines": 2, "subsections": [] }, { "name": "The empty string means the beginning of today (i.e., midnight). Order", "lines": 13, "subsections": [] }, { "name": "This is most useful for specifying day of the week items or relative", "lines": 47, "subsections": [] }, { "name": "File: cvs.info, Node: Calendar date items, Next: Time of day items, Prev: General date syntax, Up: Date input formats", "lines": 50, "subsections": [] }, { "name": "File: cvs.info, Node: Time of day items, Next: Time zone items, Prev: Calendar date items, Up: Date input formats", "lines": 37, "subsections": [] }, { "name": "File: cvs.info, Node: Time zone items, Next: Day of week items, Prev: Time of day items, Up: Date input formats", "lines": 2, "subsections": [] }, { "name": "Any included periods are ignored. By following a non-daylight-saving", "lines": 16, "subsections": [] }, { "name": "File: cvs.info, Node: Day of week items, Next: Relative items in date strings, Prev: Time zone items, Up: Date input formats", "lines": 1, "subsections": [] }, { "name": "The explicit mention of a day of the week will forward the date (only if", "lines": 10, "subsections": [] }, { "name": "In this context, 'last DAY' or 'next DAY' is also acceptable; they move", "lines": 4, "subsections": [] }, { "name": "File: cvs.info, Node: Relative items in date strings, Next: Pure numbers in date strings, Prev: Day of week items, Up: Date input formats", "lines": 58, "subsections": [] }, { "name": "File: cvs.info, Node: Pure numbers in date strings, Next: Seconds since the Epoch, Prev: Relative items in date strings, Up: Date input formats", "lines": 1, "subsections": [] }, { "name": "The precise interpretation of a pure decimal number depends on the", "lines": 16, "subsections": [] }, { "name": "File: cvs.info, Node: Seconds since the Epoch, Next: Authors of getdate, Prev: Pure numbers in date strings, Up: Date input formats", "lines": 13, "subsections": [] }, { "name": "Epoch and times far in the future. GNU and traditional Unix systems", "lines": 4, "subsections": [] }, { "name": "Systems with 64-bit signed 'timet' can represent all the times in the", "lines": 19, "subsections": [] }, { "name": "File: cvs.info, Node: Authors of getdate, Prev: Seconds since the Epoch, Up: Date input formats", "lines": 2, "subsections": [] }, { "name": "Chapel Hill. The code was later tweaked by a couple of people on", "lines": 15, "subsections": [] }, { "name": "File: cvs.info, Node: admin, Next: annotate, Prev: Date input formats, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.7 admin--Administration front-end for RCS", "lines": 5 } ] }, { "name": "Some of them have questionable usefulness for CVS but exist for", "lines": 7, "subsections": [] }, { "name": "Options specified using 'UserAdminOptions' can be run by any user. See", "lines": 11, "subsections": [] }, { "name": "File: cvs.info, Node: admin options, Up: admin", "lines": 1, "subsections": [] }, { "name": "Some of these options have questionable usefulness for CVS but exist for", "lines": 235, "subsections": [] }, { "name": "File: cvs.info, Node: annotate, Next: checkout, Prev: admin, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.8 annotate--What revision modified each line of a file?", "lines": 17 } ] }, { "name": "File: cvs.info, Node: annotate options, Next: annotate example, Up: annotate", "lines": 27, "subsections": [] }, { "name": "File: cvs.info, Node: annotate example, Prev: annotate options, Up: annotate", "lines": 3, "subsections": [] }, { "name": "Annotations for ssfile", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: checkout, Next: commit, Prev: annotate, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.9 checkout--Check out sources for editing", "lines": 17 } ] }, { "name": "You can then edit these source files at any time (regardless of whether", "lines": 23, "subsections": [] }, { "name": "However, 'checkout' takes a module name whereas 'update' takes a", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: checkout options, Next: checkout examples, Up: checkout", "lines": 109, "subsections": [] }, { "name": "File: cvs.info, Node: checkout examples, Prev: checkout options, Up: checkout", "lines": 8, "subsections": [] }, { "name": "File: cvs.info, Node: commit, Next: diff, Prev: checkout, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.10 commit--Check files into the repository", "lines": 12 } ] }, { "name": "By default (or if you explicitly specify the '-R' option), files in", "lines": 22, "subsections": [] }, { "name": "Debian and MirBSD CVS). FSF GNU CVS 1.11 and OpenBSD OpenCVS do not", "lines": 8, "subsections": [] }, { "name": "File: cvs.info, Node: commit options, Next: commit examples, Up: commit", "lines": 48, "subsections": [] }, { "name": "File: cvs.info, Node: commit examples, Prev: commit options, Up: commit", "lines": 3, "subsections": [] }, { "name": "You can commit to a branch revision (one that has an even number of", "lines": 2, "subsections": [] }, { "name": "Then, either 'checkout' or 'update' can be used to base your sources on", "lines": 17, "subsections": [] }, { "name": "Say you have been working on some extremely experimental software, based", "lines": 29, "subsections": [] }, { "name": "File: cvs.info, Node: diff, Next: export, Prev: commit, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.11 diff--Show differences between revisions", "lines": 6 } ] }, { "name": "The default action is to compare your working files with the revisions", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: diff options, Next: diff examples, Up: diff", "lines": 254, "subsections": [] }, { "name": "File: cvs.info, Node: Line group formats, Next: Line formats, Up: diff options", "lines": 3, "subsections": [] }, { "name": "Line group formats let you specify formats suitable for many", "lines": 52, "subsections": [] }, { "name": "You can specify up to four line group formats, one for each kind of line", "lines": 103, "subsections": [] }, { "name": "File: cvs.info, Node: Line formats, Prev: Line group formats, Up: diff options", "lines": 3, "subsections": [] }, { "name": "Line formats control how each line taken from an input file is output as", "lines": 93, "subsections": [] }, { "name": "File: cvs.info, Node: diff examples, Prev: diff options, Up: diff", "lines": 1, "subsections": [] }, { "name": "The following line produces a Unidiff ('-u' flag) between revision 1.14", "lines": 19, "subsections": [] }, { "name": "All local modifications that have not yet been committed will be", "lines": 4, "subsections": [] }, { "name": "File: cvs.info, Node: export, Next: history, Prev: diff, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.12 export--Export sources from CVS, similar to checkout", "lines": 7 } ] }, { "name": "For example, you might use 'export' to prepare source for shipment", "lines": 16, "subsections": [] }, { "name": "File: cvs.info, Node: export options, Up: export", "lines": 39, "subsections": [] }, { "name": "File: cvs.info, Node: history, Next: import, Prev: export, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.13 history--Show repository access history", "lines": 29 } ] }, { "name": "File: cvs.info, Node: history options, Up: history", "lines": 1, "subsections": [] }, { "name": "Several options (shown above as '-report') control what kind of report", "lines": 119, "subsections": [] }, { "name": "File: cvs.info, Node: import, Next: log, Prev: history, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.14 import--Import sources into CVS, using vendor branches", "lines": 52 } ] }, { "name": "File: cvs.info, Node: import options, Next: import output, Up: import", "lines": 47, "subsections": [] }, { "name": "File: cvs.info, Node: import output, Next: import examples, Prev: import options, Up: import", "lines": 25, "subsections": [] }, { "name": "File: cvs.info, Node: import examples, Prev: import output, Up: import", "lines": 4, "subsections": [ { "name": "A.15 log--Print out history information for files", "lines": 27 } ] }, { "name": "File: cvs.info, Node: log options, Next: log examples, Up: log", "lines": 1, "subsections": [] }, { "name": "By default, 'log' prints all information that is available. All other", "lines": 118, "subsections": [] }, { "name": "File: cvs.info, Node: log examples, Prev: log options, Up: log", "lines": 1, "subsections": [] }, { "name": "Since 'log' shows dates in local time, you might want to see them in", "lines": 1, "subsections": [] }, { "name": "Coordinated Universal Time (UTC) or some other timezone. To do this you", "lines": 10, "subsections": [ { "name": "A.16 ls & rls--List files in the repository", "lines": 80 }, { "name": "A.17 rdiff--Create 'patch' format diffs between revisions", "lines": 27 } ] }, { "name": "File: cvs.info, Node: rdiff options, Next: rdiff examples, Up: rdiff", "lines": 57, "subsections": [] }, { "name": "File: cvs.info, Node: rdiff examples, Prev: rdiff options, Up: rdiff", "lines": 20, "subsections": [ { "name": "A.18 release--Indicate that a directory is no longer in use", "lines": 5 } ] }, { "name": "Since CVS doesn't lock files, it isn't strictly necessary to use this", "lines": 21, "subsections": [] }, { "name": "File: cvs.info, Node: release options, Next: release output, Up: release", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: release output, Next: release examples, Prev: release options, Up: release", "lines": 1, "subsections": [] }, { "name": "Before 'release' releases your sources it will print a one-line message", "lines": 29, "subsections": [] }, { "name": "File: cvs.info, Node: release examples, Prev: release output, Up: release", "lines": 1, "subsections": [] }, { "name": "Release the 'tc' directory, and delete your local working copy of the", "lines": 11, "subsections": [ { "name": "A.19 server & pserver--Act as a server for a client on stdin/stdout", "lines": 26 }, { "name": "A.20 suck--Download RCS ,v file raw", "lines": 10 } ] }, { "name": "File: cvs.info, Node: update, Prev: suck, Up: CVS commands", "lines": 1, "subsections": [ { "name": "A.21 update--Bring work tree in sync with repository", "lines": 20 } ] }, { "name": "File: cvs.info, Node: update options, Next: update output, Up: update", "lines": 104, "subsections": [] }, { "name": "File: cvs.info, Node: update output, Prev: update options, Up: update", "lines": 61, "subsections": [] }, { "name": "File: cvs.info, Node: Invoking CVS, Next: Administrative files, Prev: CVS commands, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix B Quick reference to CVS commands", "lines": 1, "subsections": [] }, { "name": "This appendix describes how to invoke CVS, with references to where each", "lines": 911, "subsections": [] }, { "name": "File: cvs.info, Node: Administrative files, Next: Environment variables, Prev: Invoking CVS, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix C Reference manual for Administrative files", "lines": 21, "subsections": [] }, { "name": "File: cvs.info, Node: modules, Next: Wrappers, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.1 The modules file", "lines": 1 } ] }, { "name": "The 'modules' file records your definitions of names for collections of", "lines": 11, "subsections": [] }, { "name": "In all of the following examples, the top-level repository contains a", "lines": 14, "subsections": [] }, { "name": "File: cvs.info, Node: Alias modules, Next: Regular modules, Up: modules", "lines": 28, "subsections": [] }, { "name": "File: cvs.info, Node: Regular modules, Next: Ampersand modules, Prev: Alias modules, Up: modules", "lines": 28, "subsections": [] }, { "name": "With this definition, getting the regfiles module will create a single", "lines": 7, "subsections": [] }, { "name": "File: cvs.info, Node: Ampersand modules, Next: Excluding directories, Prev: Regular modules, Up: modules", "lines": 37, "subsections": [] }, { "name": "File: cvs.info, Node: Excluding directories, Next: Module options, Prev: Ampersand modules, Up: modules", "lines": 1, "subsections": [] }, { "name": "An alias module may exclude particular directories from other modules by", "lines": 10, "subsections": [] }, { "name": "File: cvs.info, Node: Module options, Next: Module program options, Prev: Excluding directories, Up: modules", "lines": 1, "subsections": [] }, { "name": "Either regular modules or ampersand modules can contain options, which", "lines": 33, "subsections": [] }, { "name": "File: cvs.info, Node: Module program options, Prev: Module options, Up: modules", "lines": 1, "subsections": [] }, { "name": "For checkout, rtag, and export, the program is server-based, and as such", "lines": 14, "subsections": [] }, { "name": "File: cvs.info, Node: Wrappers, Next: Trigger Scripts, Prev: modules, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.2 The cvswrappers file", "lines": 1 } ] }, { "name": "Wrappers refers to a CVS feature which lets you control certain settings", "lines": 33, "subsections": [] }, { "name": "File: cvs.info, Node: Trigger Scripts, Next: rcsinfo, Prev: Wrappers, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.3 The Trigger Scripts", "lines": 1 } ] }, { "name": "Several of the administrative files support triggers, or the launching", "lines": 32, "subsections": [] }, { "name": "File: cvs.info, Node: syntax, Next: Trigger Script Security, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The administrative files such as 'commitinfo', 'loginfo', 'rcsinfo',", "lines": 28, "subsections": [] }, { "name": "Note: The following information on format strings is valid as long as", "lines": 82, "subsections": [] }, { "name": "File: cvs.info, Node: Trigger Script Security, Next: commit files, Prev: syntax, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "Security is a huge subject, and implementing a secure system is a", "lines": 20, "subsections": [] }, { "name": "File: cvs.info, Node: commit files, Next: commitinfo, Prev: Trigger Script Security, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The '-i' flag in the 'modules' file can be used to run a certain program", "lines": 32, "subsections": [] }, { "name": "File: cvs.info, Node: Updating Commit Files, Up: commit files", "lines": 3, "subsections": [] }, { "name": "New repositories are created set to use the new format strings by", "lines": 80, "subsections": [] }, { "name": "File: cvs.info, Node: commitinfo, Next: verifymsg, Prev: commit files, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'commitinfo' file defines programs to execute whenever 'cvs commit'", "lines": 6, "subsections": [] }, { "name": "Trigger Scripts::), where each line is a regular expression followed by", "lines": 8, "subsections": [] }, { "name": "If a file is being removed, there will be no copy of the file under the", "lines": 11, "subsections": [] }, { "name": "File: cvs.info, Node: verifymsg, Next: loginfo, Prev: commitinfo, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "Once you have entered a log message, you can evaluate that message to", "lines": 10, "subsections": [] }, { "name": "File: cvs.info, Node: verifymsg example, Up: verifymsg", "lines": 3, "subsections": [] }, { "name": "The following is a little silly example of a 'verifymsg' file, together", "lines": 3, "subsections": [] }, { "name": "The rest of log message is free text. The following template is found", "lines": 39, "subsections": [] }, { "name": "File: cvs.info, Node: loginfo, Next: postadmin, Prev: verifymsg, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'loginfo' file is used to control where log information is sent", "lines": 6, "subsections": [] }, { "name": "File: cvs.info, Node: loginfo example, Next: Keeping a checked out copy, Up: loginfo", "lines": 3, "subsections": [] }, { "name": "The following 'loginfo' file, together with the tiny shell-script below,", "lines": 18, "subsections": [] }, { "name": "File: cvs.info, Node: Keeping a checked out copy, Prev: loginfo example, Up: loginfo", "lines": 3, "subsections": [] }, { "name": "It is often useful to maintain a directory tree which contains files", "lines": 18, "subsections": [] }, { "name": "File: cvs.info, Node: postadmin, Next: taginfo, Prev: loginfo, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'postadmin' file defines programs to execute after an 'admin'", "lines": 8, "subsections": [] }, { "name": "File: cvs.info, Node: taginfo, Next: posttag, Prev: postadmin, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'taginfo' file defines programs to execute when someone executes a", "lines": 51, "subsections": [] }, { "name": "File: cvs.info, Node: posttag, Next: postwatch, Prev: taginfo, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'posttag' file defines programs to execute after a 'tag' or 'rtag'", "lines": 8, "subsections": [] }, { "name": "File: cvs.info, Node: postwatch, Next: preproxy, Prev: posttag, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'postwatch' file defines programs to execute after any command (for", "lines": 3, "subsections": [] }, { "name": "Scripts::), where each line is a regular expression followed by a", "lines": 9, "subsections": [] }, { "name": "File: cvs.info, Node: preproxy, Next: postproxy, Prev: postwatch, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'preproxy' file defines programs to execute after a secondary server", "lines": 10, "subsections": [] }, { "name": "File: cvs.info, Node: postproxy, Prev: preproxy, Up: Trigger Scripts", "lines": 1, "subsections": [] }, { "name": "The 'postproxy' file defines programs to execute after a secondary", "lines": 13, "subsections": [] }, { "name": "File: cvs.info, Node: rcsinfo, Next: cvsignore, Prev: Trigger Scripts, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.4 Rcsinfo", "lines": 1 } ] }, { "name": "The 'rcsinfo' file can be used to specify a form to edit when filling", "lines": 3, "subsections": [] }, { "name": "Instead, the part after the regular expression should be a full pathname", "lines": 17, "subsections": [] }, { "name": "This template will be updated on all 'cvs update' commands. It will", "lines": 6, "subsections": [] }, { "name": "File: cvs.info, Node: cvsignore, Next: checkoutlist, Prev: rcsinfo, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.5 Ignoring files via cvsignore", "lines": 1 } ] }, { "name": "There are certain file names that frequently occur inside your working", "lines": 2, "subsections": [] }, { "name": "Normally, when you run 'cvs update', it prints a line for each file it", "lines": 61, "subsections": [] }, { "name": "File: cvs.info, Node: checkoutlist, Next: history file, Prev: cvsignore, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.6 The checkoutlist file", "lines": 1 } ] }, { "name": "It may be helpful to use CVS to maintain your own files in the 'CVSROOT'", "lines": 34, "subsections": [] }, { "name": "File: cvs.info, Node: history file, Next: Variables, Prev: checkoutlist, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.7 The history file", "lines": 10 } ] }, { "name": "File: cvs.info, Node: Variables, Next: config, Prev: history file, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.8 Expansions in administrative files", "lines": 1 } ] }, { "name": "Sometimes in writing an administrative file, you might want the file to", "lines": 89, "subsections": [] }, { "name": "File: cvs.info, Node: config, Prev: Variables, Up: Administrative files", "lines": 1, "subsections": [ { "name": "C.9 The CVSROOT/config configuration file", "lines": 16 } ] }, { "name": "Extraneous spaces or tabs, other than the leading white space, are not", "lines": 255, "subsections": [] }, { "name": "File: cvs.info, Node: Environment variables, Next: Compatibility, Prev: Administrative files, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix D All environment variables which affect CVS", "lines": 1, "subsections": [] }, { "name": "This is a complete list of all environment variables that affect CVS", "lines": 147, "subsections": [] }, { "name": "File: cvs.info, Node: Compatibility, Next: Troubleshooting, Prev: Environment variables, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix E Compatibility between CVS Versions", "lines": 1, "subsections": [] }, { "name": "The repository format is compatible going back to CVS 1.3. But see", "lines": 15, "subsections": [] }, { "name": "File: cvs.info, Node: Troubleshooting, Next: Credits, Prev: Compatibility, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix F Troubleshooting", "lines": 1, "subsections": [] }, { "name": "If you are having trouble with CVS, this appendix may help. If there is", "lines": 10, "subsections": [] }, { "name": "File: cvs.info, Node: Error messages, Next: Connection, Up: Troubleshooting", "lines": 1, "subsections": [ { "name": "F.1 Partial list of error messages", "lines": 1 } ] }, { "name": "Here is a partial list of error messages that you may see from CVS. It", "lines": 346, "subsections": [] }, { "name": "File: cvs.info, Node: Connection, Next: Other problems, Prev: Error messages, Up: Troubleshooting", "lines": 1, "subsections": [ { "name": "F.2 Trouble making a connection to a CVS server", "lines": 1 } ] }, { "name": "This section concerns what to do if you are having trouble making a", "lines": 101, "subsections": [] }, { "name": "File: cvs.info, Node: Other problems, Prev: Connection, Up: Troubleshooting", "lines": 1, "subsections": [ { "name": "F.3 Other common problems", "lines": 16 } ] }, { "name": "File: cvs.info, Node: Credits, Next: BUGS, Prev: Troubleshooting, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix G Credits", "lines": 39, "subsections": [] }, { "name": "File: cvs.info, Node: BUGS, Next: CVS command list, Prev: Credits, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix H Dealing with bugs in CVS or this manual", "lines": 1, "subsections": [] }, { "name": "If you are having trouble using CVS, or think you have found a bug,", "lines": 68, "subsections": [] }, { "name": "File: cvs.info, Node: CVS command list, Next: Index, Prev: BUGS, Up: Top", "lines": 1, "subsections": [] }, { "name": "Appendix I Alphabetical list of all CVS commands", "lines": 39, "subsections": [] }, { "name": "File: cvs.info, Node: Index, Prev: CVS command list, Up: Top", "lines": 1, "subsections": [] }, { "name": "Index", "lines": 1015, "subsections": [] } ], "sections": { "File: cvs.info, Node: Top, Next: Overview, Up: (dir)": { "content": "", "subsections": [] }, "CVS--Concurrent Versions System v1.12.13": { "content": "", "subsections": [] }, "This info manual describes how to use and administer CVS version": { "content": "1.12.13-MirOS-0AB9.1 and up.\n", "subsections": [] }, "Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,": { "content": "2003, 2004, 2005 Free Software Foundation, Inc.\n", "subsections": [] }, "Portions": { "content": "Copyright (C) 2003, 2004, 2005, 2007, 2009, 2010, 2011, 2013,\n2014, 2015, 2016, 2017, 2021 mirabilos, The MirOS Project\nCopyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007\nDerek R. Price,\nCopyright (C) 2002, 2003, 2004, 2005 Ximbiot\n,\nCopyright (C) 1992, 1993, 1999 Signum Support AB,\nand Copyright (C) others.\n\nPermission is granted to make and distribute verbatim copies of this\nmanual provided the copyright notice and this permission notice are\npreserved on all copies.\n\nPermission is granted to copy and distribute modified versions of\nthis manual under the conditions for verbatim copying, provided also\nthat the entire resulting derived work is distributed under the terms of\na permission notice identical to this one.\n\nPermission is granted to copy and distribute translations of this\nmanual into another language, under the above conditions for modified\nversions, except that this permission notice may be stated in a\ntranslation approved by the Free Software Foundation.\n\n* Menu:\n\n* Overview:: An introduction to CVS\n* Repository:: Where all your sources are stored\n* Starting a new project:: Starting a project with CVS\n* Revisions:: Numeric and symbolic names for revisions\n* Branching and merging:: Diverging/rejoining branches of development\n* Recursive behavior:: CVS descends directories\n* Adding and removing:: Adding/removing/renaming files/directories\n* History browsing:: Viewing the history of files in various ways\n\n* Binary files:: CVS can handle binary files\n* Multiple developers:: How CVS helps a group of developers\n* Revision management:: Policy questions for revision management\n* Keyword substitution:: CVS can include the revision inside the file\n* Tracking sources:: Tracking third-party sources\n* Builds:: Issues related to CVS and builds\n* Special Files::\t\tDevices, links and other non-regular files\n\n* CVS commands:: CVS commands share some things\n* Invoking CVS:: Quick reference to CVS commands\n* Administrative files:: Reference manual for the Administrative files\n* Environment variables:: All environment variables which affect CVS\n* Compatibility:: Upgrading CVS versions\n* Troubleshooting:: Some tips when nothing works\n* Credits:: Some of the contributors to this manual\n* BUGS:: Dealing with bugs in CVS or this manual\n* CVS command list:: Alphabetical list of all CVS commands\n* Index:: Index\n", "subsections": [] }, "File: cvs.info, Node: Overview, Next: Repository, Prev: Top, Up: Top": { "content": "", "subsections": [] }, "1 Overview": { "content": "", "subsections": [] }, "This chapter is for people who have never used CVS, and perhaps have": { "content": "never used version control software before.\n\nIf you are already familiar with CVS and are just trying to learn a\nparticular feature or remember a certain command, you can probably skip\neverything here.\n\n* Menu:\n\n* What is CVS?:: What you can do with CVS\n* What is CVS not?:: Problems CVS doesn't try to solve\n* A sample session:: A tour of basic CVS usage\n\nFile: cvs.info, Node: What is CVS?, Next: What is CVS not?, Up: Overview\n", "subsections": [ { "name": "1.1 What is CVS?", "content": "CVS is a version control system. Using it, you can record the history\nof your source files.\n\nFor example, bugs sometimes creep in when software is modified, and\nyou might not detect the bug until a long time after you make the\nmodification. With CVS, you can easily retrieve old versions to see\nexactly which change caused the bug. This can sometimes be a big help.\n\nYou could of course save every version of every file you have ever\ncreated. This would however waste an enormous amount of disk space.\nCVS stores all the versions of a file in a single file in a clever way\nthat only stores the differences between versions.\n\nCVS also helps you if you are part of a group of people working on\nthe same project. It is all too easy to overwrite each others' changes\nunless you are extremely careful. Some editors, like GNU Emacs, try to\nmake sure that two people never modify the same file at the same time." } ] }, "Unfortunately, if someone is using another editor, that safeguard will": { "content": "not work. CVS solves this problem by insulating the different\ndevelopers from each other. Every developer works in his own directory,\nand CVS merges the work when each developer is done.\n\nCVS started out as a bunch of shell scripts written by Dick Grune,\nposted to the newsgroup 'comp.sources.unix' in the volume 6 release of", "subsections": [] }, "July, 1986. While no actual code from these shell scripts is present in": { "content": "the current version of CVS much of the CVS conflict resolution\nalgorithms come from them.\n\nIn April, 1989, Brian Berliner designed and coded CVS. Jeff Polk\nlater helped Brian with the design of the CVS module and vendor branch\nsupport.\n\nYou can get CVS in a variety of ways, including free download from\nthe Internet. For more information on downloading CVS and other CVS\ntopics, see:\n\n\n\nThere is a mailing list, known as , devoted to\nCVS. To subscribe or unsubscribe write to\n. If you prefer a Usenet group, there is a\none-way mirror (posts to the email list are usually sent to the news\ngroup, but not visa versa) of at\n. The right Usenet group for posts is\n which is for CVS discussions (along\nwith other configuration management systems). In the future, it might\nbe possible to create a 'comp.software.config-mgmt.cvs', but probably\nonly if there is sufficient CVS traffic on\n.\n\nYou can also subscribe to the mailing list,\ndescribed in more detail in *note BUGS::. To subscribe send mail to\n. There is a two-way Usenet mirror (posts\nto the Usenet group are usually sent to the email list and visa versa)\nof named .\n\nFile: cvs.info, Node: What is CVS not?, Next: A sample session, Prev: What is CVS?, Up: Overview\n", "subsections": [ { "name": "1.2 What is CVS not?", "content": "CVS can do a lot of things for you, but it does not try to be everything\nfor everyone.\n\nCVS is not a build system.\n\nThough the structure of your repository and modules file interact\nwith your build system (e.g. 'Makefile's), they are essentially\nindependent.\n\nCVS does not dictate how you build anything. It merely stores\nfiles for retrieval in a tree structure you devise.\n\nCVS does not dictate how to use disk space in the checked out\nworking directories. If you write your 'Makefile's or scripts in\nevery directory so they have to know the relative positions of\neverything else, you wind up requiring the entire repository to be\nchecked out.\n\nIf you modularise your work, and construct a build system that will\nshare files (via links, mounts, 'VPATH' in 'Makefile's, etc.), you\ncan arrange your disk usage however you like.\n\nBut you have to remember that any such system is a lot of work to\nconstruct and maintain. CVS does not address the issues involved.\n\nOf course, you should place the tools created to support such a\nbuild system (scripts, 'Makefile's, etc) under CVS.\n\nFiguring out what files need to be rebuilt when something changes\nis, again, something to be handled outside the scope of CVS. One\ntraditional approach is to use 'make' for building, and use some\nautomated tool for generating the dependencies which 'make' uses.\n\nSee *note Builds::, for more information on doing builds in\nconjunction with CVS.\n\nCVS is not a substitute for management.\n\nYour managers and project leaders are expected to talk to you\nfrequently enough to make certain you are aware of schedules, merge\npoints, branch names and release dates. If they don't, CVS can't\nhelp.\n\nCVS is an instrument for making sources dance to your tune. But\nyou are the piper and the composer. No instrument plays itself or\nwrites its own music.\n\nCVS is not a substitute for developer communication.\n\nWhen faced with conflicts within a single file, most developers\nmanage to resolve them without too much effort. But a more general\ndefinition of \"conflict\" includes problems too difficult to solve\nwithout communication between developers.\n\nCVS cannot determine when simultaneous changes within a single\nfile, or across a whole collection of files, will logically\nconflict with one another. Its concept of a \"conflict\" is purely\ntextual, arising when two changes to the same base file are near\nenough to spook the merge (i.e. 'diff3') command.\n\nCVS does not claim to help at all in figuring out non-textual or\ndistributed conflicts in program logic.\n\nFor example: Say you change the arguments to function 'X' defined\nin file 'A'. At the same time, someone edits file 'B', adding new\ncalls to function 'X' using the old arguments. You are outside the\nrealm of CVS's competence.\n\nAcquire the habit of reading specs and talking to your peers.\n\nCVS does not have change control\n\nChange control refers to a number of things. First of all it can\nmean \"bug-tracking\", that is being able to keep a database of\nreported bugs and the status of each one (is it fixed? in what\nrelease? has the bug submitter agreed that it is fixed?). For\ninterfacing CVS to an external bug-tracking system, see the\n'rcsinfo' and 'verifymsg' files (*note Administrative files::).\n\nAnother aspect of change control is keeping track of the fact that\nchanges to several files were in fact changed together as one\nlogical change. If you check in several files in a single 'cvs\ncommit' operation, CVS then forgets that those files were checked\nin together, and the fact that they have the same log message is\nthe only thing tying them together. Keeping a GNU style\n'ChangeLog' can help somewhat.\n\nAnother aspect of change control, in some systems, is the ability\nto keep track of the status of each change. Some changes have been\nwritten by a developer, others have been reviewed by a second\ndeveloper, and so on. Generally, the way to do this with CVS is to\ngenerate a diff (using 'cvs diff' or 'diff') and email it to\nsomeone who can then apply it using the 'patch' utility. This is\nvery flexible, but depends on mechanisms outside CVS to make sure\nnothing falls through the cracks.\n\nCVS is not an automated testing program\n\nIt should be possible to enforce mandatory use of a test suite\nusing the 'commitinfo' file. I haven't heard a lot about projects\ntrying to do that or whether there are subtle gotchas, however.\n\nCVS does not have a built-in process model\n\nSome systems provide ways to ensure that changes or releases go\nthrough various steps, with various approvals as needed.\nGenerally, one can accomplish this with CVS but it might be a\nlittle more work. In some cases you'll want to use the\n'commitinfo', 'loginfo', 'rcsinfo', or 'verifymsg' files, to\nrequire that certain steps be performed before cvs will allow a\ncheckin. Also consider whether features such as branches and tags\ncan be used to perform tasks such as doing work in a development\ntree and then merging certain changes over to a stable tree only\nonce they have been proven.\n\nFile: cvs.info, Node: A sample session, Prev: What is CVS not?, Up: Overview\n" }, { "name": "1.3 A sample session", "content": "" } ] }, "As a way of introducing CVS, we'll go through a typical work-session": { "content": "using CVS. The first thing to understand is that CVS stores all files\nin a centralised \"repository\" (*note Repository::); this section assumes\nthat a repository is set up.\n\nSuppose you are working on a simple compiler. The source consists of\na handful of C files and a 'Makefile'. The compiler is called 'tc'\n(Trivial Compiler), and the repository is set up so that there is a\nmodule called 'tc'.\n\n* Menu:\n\n* Getting the source:: Creating a workspace\n* Committing your changes:: Making your work available to others\n* Cleaning up:: Cleaning up\n* Viewing differences:: Viewing differences\n", "subsections": [] }, "File: cvs.info, Node: Getting the source, Next: Committing your changes, Up: A sample session": { "content": "", "subsections": [] }, "The first thing you must do is to get your own working copy of the": { "content": "source for 'tc'. For this, you use the 'checkout' command:\n\n$ cvs checkout tc\n", "subsections": [] }, "This will create a new directory called 'tc' and populate it with the": { "content": "source files.\n\n$ cd tc\n$ ls\nCVS Makefile backend.c driver.c frontend.c parser.c\n\nThe 'CVS' directory is used internally by CVS. Normally, you should\nnot modify or remove any of the files in it.\n\nYou start your favorite editor, hack away at 'backend.c', and a\ncouple of hours later you have added an optimization pass to the\ncompiler. A note to RCS and SCCS users: There is no need to lock the\nfiles that you want to edit. *Note Multiple developers::, for an\nexplanation.\n", "subsections": [] }, "File: cvs.info, Node: Committing your changes, Next: Cleaning up, Prev: Getting the source, Up: A sample session": { "content": "", "subsections": [] }, "When you have checked that the compiler is still compilable you decide": { "content": "to make a new version of 'backend.c'. This will store your new\n'backend.c' in the repository and make it available to anyone else who\nis using that same repository.\n\n$ cvs commit backend.c\n\nCVS starts an editor, to allow you to enter a log message. You type in\n\"Added an optimization pass.\", save the temporary file, and exit the\neditor.\n\nThe environment variable '$CVSEDITOR' determines which editor is\nstarted. If '$CVSEDITOR' is not set, then if the environment variable\n'$EDITOR' is set, it will be used. If both '$CVSEDITOR' and '$EDITOR'\nare not set then there is a default which will vary with your operating\nsystem, for example 'vi' for unix or 'notepad' for Windows NT/95.\n\nIn addition, CVS checks the '$VISUAL' environment variable. Opinions\nvary on whether this behavior is desirable and whether future releases\nof CVS should check '$VISUAL' or ignore it. You will be OK either way\nif you make sure that '$VISUAL' is either unset or set to the same thing\nas '$EDITOR'.\n\nWhen CVS starts the editor, it includes a list of files which are\nmodified. For the CVS client, this list is based on comparing the\nmodification time of the file against the modification time that the\nfile had when it was last gotten or updated. Therefore, if a file's\nmodification time has changed but its contents have not, it will show up\nas modified. The simplest way to handle this is simply not to worry\nabout it--if you proceed with the commit CVS will detect that the\ncontents are not modified and treat it as an unmodified file. The next\n'update' will clue CVS in to the fact that the file is unmodified, and\nit will reset its stored timestamp so that the file will not show up in\nfuture editor sessions.\n\nIf you want to avoid starting an editor you can specify the log\nmessage on the command line using the '-m' flag instead, like this:\n\n$ cvs commit -m \"Added an optimization pass\" backend.c\n", "subsections": [] }, "File: cvs.info, Node: Cleaning up, Next: Viewing differences, Prev: Committing your changes, Up: A sample session": { "content": "", "subsections": [] }, "Before you turn to other tasks you decide to remove your working copy of": { "content": "tc. One acceptable way to do that is of course\n\n$ cd ..\n$ rm -r tc\n\nbut a better way is to use the 'release' command (*note release::):\n\n$ cd ..\n$ cvs release -d tc\nM driver.c\n? tc\nYou have [1] altered files in this repository.\nAre you sure you want to release (and delete) directory `tc': n\n`release' aborted by user choice.\n\nThe 'release' command checks that all your modifications have been\ncommitted. If history logging is enabled it also makes a note in the\nhistory file. *Note history file::.\n\nWhen you use the '-d' flag with 'release', it also removes your\nworking copy.\n\nIn the example above, the 'release' command wrote a couple of lines\nof output. '? tc' means that the file 'tc' is unknown to CVS. That is\nnothing to worry about: 'tc' is the executable compiler, and it should\nnot be stored in the repository. *Note cvsignore::, for information\nabout how to make that warning go away. *Note release output::, for a\ncomplete explanation of all possible output from 'release'.\n\n'M driver.c' is more serious. It means that the file 'driver.c' has\nbeen modified since it was checked out.\n\nThe 'release' command always finishes by telling you how many\nmodified files you have in your working copy of the sources, and then\nasks you for confirmation before deleting any files or making any note\nin the history file.\n\nYou decide to play it safe and answer 'n ' when 'release' asks\nfor confirmation.\n", "subsections": [] }, "File: cvs.info, Node: Viewing differences, Prev: Cleaning up, Up: A sample session": { "content": "", "subsections": [] }, "You do not remember modifying 'driver.c', so you want to see what has": { "content": "happened to that file.\n\n$ cd tc\n$ cvs diff driver.c\n\nThis command runs 'diff' to compare the version of 'driver.c' that\nyou checked out with your working copy. When you see the output you\nremember that you added a command line option that enabled the\noptimization pass. You check it in, and release the module.\n\n$ cvs commit -m \"Added an optimization pass\" driver.c\nChecking in driver.c;\n/usr/local/cvsroot/tc/driver.c,v <-- driver.c\nnew revision: 1.2; previous revision: 1.1\ndone\n$ cd ..\n$ cvs release -d tc\n? tc\nYou have [0] altered files in this repository.\nAre you sure you want to release (and delete) directory `tc': y\n", "subsections": [] }, "File: cvs.info, Node: Repository, Next: Starting a new project, Prev: Overview, Up: Top": { "content": "", "subsections": [] }, "2 The Repository": { "content": "The CVS \"repository\" stores a complete copy of all the files and\ndirectories which are under version control.\n\nNormally, you never access any of the files in the repository\ndirectly. Instead, you use CVS commands to get your own copy of the\nfiles into a \"working directory\", and then work on that copy. When\nyou've finished a set of changes, you check (or \"commit\") them back into\nthe repository. The repository then contains the changes which you have\nmade, as well as recording exactly what you changed, when you changed\nit, and other such information. Note that the repository is not a\nsubdirectory of the working directory, or vice versa; they should be in\nseparate locations.\n\nCVS can access a repository by a variety of means. It might be on\nthe local computer, or it might be on a computer across the room or\nacross the world. To distinguish various ways to access a repository,\nthe repository name can start with an \"access method\". For example, the\naccess method ':local:' means to access a repository directory, so the\nrepository ':local:/usr/local/cvsroot' means that the repository is in\n'/usr/local/cvsroot' on the computer running CVS. For information on\nother access methods, see *note Remote repositories::.\n\nIf the access method is omitted, then if the repository starts with\n'/', then ':local:' is assumed. If it does not start with '/' then\neither ':ext:' or ':server:' is assumed. For example, if you have a\nlocal repository in '/usr/local/cvsroot', you can use\n'/usr/local/cvsroot' instead of ':local:/usr/local/cvsroot'. But if\n(under Windows NT, for example) your local repository is\n'c:\\src\\cvsroot', then you must specify the access method, as in\n':local:c:/src/cvsroot'.\n\nThe repository is split in two parts. '$CVSROOT/CVSROOT' contains\nadministrative files for CVS. The other directories contain the actual\nuser-defined modules.\n\n* Menu:\n\n* Specifying a repository:: Telling CVS where your repository is\n* Repository storage:: The structure of the repository\n* Working directory storage:: The structure of working directories\n* Intro administrative files:: Defining modules\n* Multiple repositories:: Multiple repositories\n* Creating a repository:: Creating a repository\n* Backing up:: Backing up a repository\n* Moving a repository:: Moving a repository\n* Remote repositories:: Accessing repositories on remote machines\n* Read-only access:: Granting read-only access to the repository\n* Server temporary directory:: The server creates temporary directories\n", "subsections": [] }, "File: cvs.info, Node: Specifying a repository, Next: Repository storage, Up: Repository": { "content": "", "subsections": [ { "name": "2.1 Telling CVS where your repository is", "content": "" } ] }, "There are several ways to tell CVS where to find the repository. You": { "content": "can name the repository on the command line explicitly, with the '-d'\n(for \"directory\") option:\n\ncvs -d /usr/local/cvsroot checkout yoyodyne/tc\n\nOr you can set the '$CVSROOT' environment variable to an absolute\npath to the root of the repository, '/usr/local/cvsroot' in this\nexample. To set '$CVSROOT', 'csh' and 'tcsh' users should have this\nline in their '.cshrc' or '.tcshrc' files:\n\nsetenv CVSROOT /usr/local/cvsroot\n\n'sh' and 'bash' users should instead have these lines in their\n'.profile' or '.bashrc':\n\nCVSROOT=/usr/local/cvsroot\nexport CVSROOT\n\nA repository specified with '-d' will override the '$CVSROOT'\nenvironment variable. Once you've checked a working copy out from the\nrepository, it will remember where its repository is (the information is\nrecorded in the 'CVS/Root' file in the working copy).\n\nThe '-d' option and the 'CVS/Root' file both override the '$CVSROOT'\nenvironment variable. If '-d' option differs from 'CVS/Root', the\nformer is used. Of course, for proper operation they should be two ways\nof referring to the same repository.\n", "subsections": [] }, "File: cvs.info, Node: Repository storage, Next: Working directory storage, Prev: Specifying a repository, Up: Repository": { "content": "", "subsections": [ { "name": "2.2 How data is stored in the repository", "content": "" } ] }, "For most purposes it isn't important how CVS stores information in the": { "content": "repository. In fact, the format has changed in the past, and is likely\nto change in the future. Since in almost all cases one accesses the\nrepository via CVS commands, such changes need not be disruptive.\n\nHowever, in some cases it may be necessary to understand how CVS\nstores data in the repository, for example you might need to track down\nCVS locks (*note Concurrency::) or you might need to deal with the file\npermissions appropriate for the repository.\n\n* Menu:\n\n* Repository files:: What files are stored in the repository\n* File permissions:: File permissions\n* Windows permissions:: Issues specific to Windows\n* Attic:: Some files are stored in the Attic\n* CVS in repository:: Additional information in CVS directory\n* Locks:: CVS locks control concurrent accesses\n* CVSROOT storage:: A few things about CVSROOT are different\n", "subsections": [] }, "File: cvs.info, Node: Repository files, Next: File permissions, Up: Repository storage": { "content": "", "subsections": [] }, "The overall structure of the repository is a directory tree": { "content": "corresponding to the directories in the working directory. For example,\nsupposing the repository is in\n\n/usr/local/cvsroot\n\nhere is a possible directory tree (showing only the directories):\n\n/usr\n|\n+--local\n| |\n| +--cvsroot\n| | |\n| | +--CVSROOT\n| (administrative files)\n|\n+--gnu\n| |\n| +--diff\n| | (source code to GNU diff)\n| |\n| +--rcs\n| | (source code to RCS)\n| |\n| +--cvs\n| (source code to CVS)\n|\n+--yoyodyne\n|\n+--tc\n| |\n| +--man\n| |\n| +--testing\n|\n+--(other Yoyodyne software)\n\nWith the directories are \"history files\" for each file under version\ncontrol. The name of the history file is the name of the corresponding\nfile with ',v' appended to the end. Here is what the repository for the\n'yoyodyne/tc' directory might look like:\n$CVSROOT\n|\n+--yoyodyne\n| |\n| +--tc\n| | |\n+--Makefile,v\n+--backend.c,v\n+--driver.c,v\n+--frontend.c,v\n+--parser.c,v\n+--man\n| |\n| +--tc.1,v\n|\n+--testing\n|\n+--testpgm.t,v\n+--test2.t,v\n\nThe history files contain, among other things, enough information to\nrecreate any revision of the file, a log of all commit messages and the\nuser-name of the person who committed the revision. The history files\nare known as \"RCS files\", because the first program to store files in\nthat format was a version control system known as RCS. For a full\ndescription of the file format, see the 'man' page 'rcsfile(5)',\ndistributed with RCS, or the file 'doc/RCSFILES' in the CVS source\ndistribution. This file format has become very common--many systems\nother than CVS or RCS can at least import history files in this format.\n\nThe RCS files used in CVS differ in a few ways from the standard\nformat. The biggest difference is magic branches; for more information\nsee *note Magic branch numbers::. Also in CVS the valid tag names are a\nsubset of what RCS accepts; for CVS's rules see *note Tags::.\n", "subsections": [] }, "File: cvs.info, Node: File permissions, Next: Windows permissions, Prev: Repository files, Up: Repository storage": { "content": "", "subsections": [] }, "All ',v' files are created read-only, and you should not change the": { "content": "permission of those files. The directories inside the repository should\nbe writable by the persons that have permission to modify the files in\neach directory. This normally means that you must create a UNIX group\n(see group(5)) consisting of the persons that are to edit the files in a\nproject, and set up the repository so that it is that group that owns\nthe directory. (On some systems, you also need to set the\nset-group-ID-on-execution bit on the repository directories (see\nchmod(1)) so that newly-created files and directories get the group-ID\nof the parent directory rather than that of the current process.)\n\nThis means that you can only control access to files on a\nper-directory basis.\n\nNote that users must also have write access to check out files,\nbecause CVS needs to create lock files (*note Concurrency::). You can\nuse LockDir in CVSROOT/config to put the lock files somewhere other than\nin the repository if you want to allow read-only access to some\ndirectories (*note config::).\n\nAlso note that users must have write access to the 'CVSROOT/val-tags'\nfile. CVS uses it to keep track of what tags are valid tag names (it is\nsometimes updated when tags are used, as well as when they are created).\n\nEach RCS file will be owned by the user who last checked it in. This\nhas little significance; what really matters is who owns the\ndirectories.\n\nCVS tries to set up reasonable file permissions for new directories\nthat are added inside the tree, but you must fix the permissions\nmanually when a new directory should have different permissions than its\nparent directory. If you set the 'CVSUMASK' environment variable that\nwill control the file permissions which CVS uses in creating directories\nand/or files in the repository. 'CVSUMASK' does not affect the file\npermissions in the working directory; such files have the permissions\nwhich are typical for newly created files, except that sometimes CVS\ncreates them read-only (see the sections on watches, *note Setting a\nwatch::; -r, *note Global options::; or 'CVSREAD', *note Environment\nvariables::).\n\nNote that using the client/server CVS (*note Remote repositories::),\nthere is no good way to set 'CVSUMASK'; the setting on the client\nmachine has no effect. If you are connecting with 'rsh', you can set\n'CVSUMASK' in '.bashrc' or '.cshrc', as described in the documentation\nfor your operating system. This behavior might change in future\nversions of CVS; do not rely on the setting of 'CVSUMASK' on the client\nhaving no effect.\n\nUsing pserver, you will generally need stricter permissions on the\nCVSROOT directory and directories above it in the tree; see *note\nPassword authentication security::.\n\nSome operating systems have features which allow a particular program\nto run with the ability to perform operations which the caller of the\nprogram could not. For example, the set user ID (setuid) or set group\nID (setgid) features of unix or the installed image feature of VMS. CVS\nwas not written to use such features and therefore attempting to install\nCVS in this fashion will provide protection against only accidental\nlapses; anyone who is trying to circumvent the measure will be able to\ndo so, and depending on how you have set it up may gain access to more\nthan just CVS. You may wish to instead consider pserver. It shares\nsome of the same attributes, in terms of possibly providing a false\nsense of security or opening security holes wider than the ones you are\ntrying to fix, so read the documentation on pserver security carefully\nif you are considering this option (*note Password authentication\nsecurity::).\n", "subsections": [] }, "File: cvs.info, Node: Windows permissions, Next: Attic, Prev: File permissions, Up: Repository storage": { "content": "", "subsections": [] }, "Some file permission issues are specific to Windows operating systems": { "content": "(Windows 95, Windows NT, and presumably future operating systems in this\nfamily. Some of the following might apply to OS/2 but I'm not sure).\n\nIf you are using local CVS and the repository is on a networked\nfilesystem which is served by the Samba SMB server, some people have\nreported problems with permissions. Enabling WRITE=YES in the samba\nconfiguration is said to fix/workaround it. Disclaimer: I haven't\ninvestigated enough to know the implications of enabling that option,\nnor do I know whether there is something which CVS could be doing\ndifferently in order to avoid the problem. If you find something out,\nplease let us know as described in *note BUGS::.\n", "subsections": [] }, "File: cvs.info, Node: Attic, Next: CVS in repository, Prev: Windows permissions, Up: Repository storage": { "content": "You will notice that sometimes CVS stores an RCS file in the 'Attic'.", "subsections": [] }, "For example, if the CVSROOT is '/usr/local/cvsroot' and we are talking": { "content": "about the file 'backend.c' in the directory 'yoyodyne/tc', then the file\nnormally would be in\n\n/usr/local/cvsroot/yoyodyne/tc/backend.c,v\n\nbut if it goes in the attic, it would be in\n\n/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v\n\ninstead. It should not matter from a user point of view whether a file\nis in the attic; CVS keeps track of this and looks in the attic when it\nneeds to. But in case you want to know, the rule is that the RCS file\nis stored in the attic if and only if the head revision on the trunk has\nstate 'dead'. A 'dead' state means that file has been removed, or never\nadded, for that revision. For example, if you add a file on a branch,\nit will have a trunk revision in 'dead' state, and a branch revision in\na non-'dead' state.\n", "subsections": [] }, "File: cvs.info, Node: CVS in repository, Next: Locks, Prev: Attic, Up: Repository storage": { "content": "", "subsections": [] }, "The 'CVS' directory in each repository directory contains information": { "content": "such as file attributes (in a file called 'CVS/fileattr'. In the future\nadditional files may be added to this directory, so implementations\nshould silently ignore additional files.\n\nThis behavior is implemented only by CVS 1.7 and later; for details\nsee *note Watches Compatibility::.\n\nThe format of the 'fileattr' file is a series of entries of the\nfollowing form (where '{' and '}' means the text between the braces can\nbe repeated zero or more times):\n\nENT-TYPE FILENAME ATTRNAME = ATTRVAL {; ATTRNAME = ATTRVAL}\n\n\nENT-TYPE is 'F' for a file, in which case the entry specifies the\nattributes for that file.\n\nENT-TYPE is 'D', and FILENAME empty, to specify default attributes to\nbe used for newly added files.\n\nOther ENT-TYPE are reserved for future expansion. CVS 1.9 and older\nwill delete them any time it writes file attributes. CVS 1.10 and later\nwill preserve them.\n\nNote that the order of the lines is not significant; a program\nwriting the fileattr file may rearrange them at its convenience.\n\nThere is currently no way of quoting tabs or line feeds in the\nfilename, '=' in ATTRNAME, ';' in ATTRVAL, etc. Note: some\nimplementations also don't handle a NUL character in any of the fields,\nbut implementations are encouraged to allow it.\n\nBy convention, ATTRNAME starting with '' is for an attribute given\nspecial meaning by CVS; other ATTRNAMEs are for user-defined attributes\n(or will be, once implementations start supporting user-defined\nattributes).\n\nBuilt-in attributes:\n\n'watched'\nPresent means the file is watched and should be checked out\nread-only.\n\n'watchers'\nUsers with watches for this file. Value is WATCHER > TYPE { ,\nWATCHER > TYPE } where WATCHER is a username, and TYPE is zero or\nmore of edit,unedit,commit separated by '+' (that is, nothing if\nnone; there is no \"none\" or \"all\" keyword).\n\n'editors'\nUsers editing this file. Value is EDITOR > VAL { , EDITOR > VAL }\nwhere EDITOR is a username, and VAL is TIME+HOSTNAME+PATHNAME,\nwhere TIME is when the 'cvs edit' command (or equivalent) happened,\nand HOSTNAME and PATHNAME are for the working directory.\n\nExample:\n\nFfile1 watched=;watchers=joe>edit,mary>commit\nFfile2 watched=;editors=sue>8 Jan 1975+workstn1+/home/sue/cvs\nD watched=\n\nmeans that the file 'file1' should be checked out read-only.\nFurthermore, joe is watching for edits and mary is watching for commits.", "subsections": [] }, "The file 'file2' should be checked out read-only; sue started editing it": { "content": "on 8 Jan 1975 in the directory '/home/sue/cvs' on the machine\n'workstn1'. Future files which are added should be checked out\nread-only. To represent this example here, we have shown a space after\n'D', 'Ffile1', and 'Ffile2', but in fact there must be a single tab\ncharacter there and no spaces.\n", "subsections": [] }, "File: cvs.info, Node: Locks, Next: CVSROOT storage, Prev: CVS in repository, Up: Repository storage": { "content": "", "subsections": [] }, "For an introduction to CVS locks focusing on user-visible behavior, see": { "content": "*note Concurrency::. The following section is aimed at people who are\nwriting tools which want to access a CVS repository without interfering\nwith other tools accessing the same repository. If you find yourself\nconfused by concepts described here, like \"read lock\", \"write lock\", and\n\"deadlock\", you might consult the literature on operating systems or\ndatabases.\n\nAny file in the repository with a name starting with '#cvs.rfl.' is a\nread lock. Any file in the repository with a name starting with\n'#cvs.pfl' is a promotable read lock. Any file in the repository with a\nname starting with '#cvs.wfl' is a write lock. Old versions of CVS\n(before CVS 1.5) also created files with names starting with '#cvs.tfl',\nbut they are not discussed here. The directory '#cvs.lock' serves as a\nmaster lock. That is, one must obtain this lock first before creating\nany of the other locks.\n\nTo obtain a read lock, first create the '#cvs.lock' directory. This\noperation must be atomic (which should be true for creating a directory\nunder most operating systems). If it fails because the directory\nalready existed, wait for a while and try again. After obtaining the\n'#cvs.lock' lock, create a file whose name is '#cvs.rfl.' followed by\ninformation of your choice (for example, hostname and process\nidentification number). Then remove the '#cvs.lock' directory to\nrelease the master lock. Then proceed with reading the repository.\nWhen you are done, remove the '#cvs.rfl' file to release the read lock.\n\nPromotable read locks are a concept you may not find in other\nliterature on concurrency. They are used to allow a two (or more) pass\nprocess to only lock a file for read on the first (read) pass(es), then\nupgrade its read locks to write locks if necessary for a final pass,\nstill assured that the files have not changed since they were first\nread. CVS uses promotable read locks, for example, to prevent commit\nand tag verification passes from interfering with other reading\nprocesses. It can then lock only a single directory at a time for write\nduring the write pass.\n\nTo obtain a promotable read lock, first create the '#cvs.lock'\ndirectory, as with a non-promotable read lock. Then check that there\nare no files that start with '#cvs.pfl'. If there are, remove the\nmaster '#cvs.lock' directory, wait awhile (CVS waits 30 seconds between\nlock attempts), and try again. If there are no other promotable locks,\ngo ahead and create a file whose name is '#cvs.pfl' followed by\ninformation of your choice (for example, CVS uses its hostname and the\nprocess identification number of the CVS server process creating the\nlock). If versions of CVS older than version 1.12.4 access your\nrepository directly (not via a CVS server of version 1.12.4 or later),\nthen you should also create a read lock since older versions of CVS will\nignore the promotable lock when attempting to create their own write\nlock. Then remove the master '#cvs.lock' directory in order to allow\nother processes to obtain read locks.\n\nTo obtain a write lock, first create the '#cvs.lock' directory, as\nwith read locks. Then check that there are no files whose names start\nwith '#cvs.rfl.' and no files whose names start with '#cvs.pfl' that are\nnot owned by the process attempting to get the write lock. If either\nexist, remove '#cvs.lock', wait for a while, and try again. If there\nare no readers or promotable locks from other processes, then create a\nfile whose name is '#cvs.wfl' followed by information of your choice\n(again, CVS uses the hostname and server process identification number).\nRemove your '#cvs.pfl' file if present. Hang on to the '#cvs.lock'\nlock. Proceed with writing the repository. When you are done, first\nremove the '#cvs.wfl' file and then the '#cvs.lock' directory. Note\nthat unlike the '#cvs.rfl' file, the '#cvs.wfl' file is just\ninformational; it has no effect on the locking operation beyond what is\nprovided by holding on to the '#cvs.lock' lock itself.\n\nNote that each lock (write lock or read lock) only locks a single\ndirectory in the repository, including 'Attic' and 'CVS' but not\nincluding subdirectories which represent other directories under version\ncontrol. To lock an entire tree, you need to lock each directory (note\nthat if you fail to obtain any lock you need, you must release the whole\ntree before waiting and trying again, to avoid deadlocks).\n\nNote also that CVS expects write locks to control access to\nindividual 'foo,v' files. RCS has a scheme where the ',foo,' file\nserves as a lock, but CVS does not implement it and so taking out a CVS\nwrite lock is recommended. See the comments at rcsinternallockfile in\nthe CVS source code for further discussion/rationale.\n", "subsections": [] }, "File: cvs.info, Node: CVSROOT storage, Prev: Locks, Up: Repository storage": { "content": "The '$CVSROOT/CVSROOT' directory contains the various administrative\nfiles. In some ways this directory is just like any other directory in\nthe repository; it contains RCS files whose names end in ',v', and many\nof the CVS commands operate on it the same way. However, there are a\nfew differences.\n\nFor each administrative file, in addition to the RCS file, there is\nalso a checked out copy of the file. For example, there is an RCS file\n'loginfo,v' and a file 'loginfo' which contains the latest revision\ncontained in 'loginfo,v'. When you check in an administrative file, CVS\nshould print\n\ncvs commit: Rebuilding administrative file database\n\nand update the checked out copy in '$CVSROOT/CVSROOT'. If it does not,\nthere is something wrong (*note BUGS::). To add your own files to the\nfiles to be updated in this fashion, you can add them to the\n'checkoutlist' administrative file (*note checkoutlist::).\n\nBy default, the 'modules' file behaves as described above. If the\nmodules file is very large, storing it as a flat text file may make\nlooking up modules slow (I'm not sure whether this is as much of a\nconcern now as when CVS first evolved this feature; I haven't seen\nbenchmarks). Therefore, by making appropriate edits to the CVS source\ncode one can store the modules file in a database which implements the\n'ndbm' interface, such as Berkeley db or GDBM. If this option is in use,\nthen the modules database will be stored in the files 'modules.db',\n'modules.pag', and/or 'modules.dir'.\n\nFor information on the meaning of the various administrative files,\nsee *note Administrative files::.\n", "subsections": [] }, "File: cvs.info, Node: Working directory storage, Next: Intro administrative files, Prev: Repository storage, Up: Repository": { "content": "", "subsections": [ { "name": "2.3 How data is stored in the working directory", "content": "" } ] }, "While we are discussing CVS internals which may become visible from time": { "content": "to time, we might as well talk about what CVS puts in the 'CVS'\ndirectories in the working directories. As with the repository, CVS\nhandles this information and one can usually access it via CVS commands.", "subsections": [] }, "But in some cases it may be useful to look at it, and other programs,": { "content": "such as the 'jCVS' graphical user interface or the 'VC' package for\nemacs, may need to look at it. Such programs should follow the\nrecommendations in this section if they hope to be able to work with\nother programs which use those files, including future versions of the\nprograms just mentioned and the command-line CVS client.\n\nThe 'CVS' directory contains several files. Programs which are\nreading this directory should silently ignore files which are in the\ndirectory but which are not documented here, to allow for future\nexpansion.\n\nThe files are stored according to the text file convention for the\nsystem in question. This means that working directories are not\nportable between systems with differing conventions for storing text\nfiles. This is intentional, on the theory that the files being managed\nby CVS probably will not be portable between such systems either.\n\n'Root'\nThis file contains the current CVS root, as described in *note\nSpecifying a repository::.\n\n'Repository'\nThis file contains the directory within the repository which the\ncurrent directory corresponds with. It can be either an absolute\npathname or a relative pathname; CVS has had the ability to read\neither format since at least version 1.3 or so. The relative\npathname is relative to the root, and is the more sensible\napproach, but the absolute pathname is quite common and\nimplementations should accept either. For example, after the\ncommand\n\ncvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc\n\n'Root' will contain\n\n:local:/usr/local/cvsroot\n\nand 'Repository' will contain either\n\n/usr/local/cvsroot/yoyodyne/tc\n\nor\n\nyoyodyne/tc\n\nIf the particular working directory does not correspond to a\ndirectory in the repository, then 'Repository' should contain\n'CVSROOT/Emptydir'.\n\n'Entries'\nThis file lists the files and directories in the working directory.\nThe first character of each line indicates what sort of line it is.\nIf the character is unrecognised, programs reading the file should\nsilently skip that line, to allow for future expansion.\n\nIf the first character is '/', then the format is:\n\n/NAME/REVISION/TIMESTAMP[+CONFLICT]/OPTIONS/TAGDATE\n\nwhere '[' and ']' are not part of the entry, but instead indicate\nthat the '+' and conflict marker are optional. NAME is the name of\nthe file within the directory. REVISION is the revision that the\nfile in the working derives from, or '0' for an added file, or '-'\nfollowed by a revision for a removed file. TIMESTAMP is the\ntimestamp of the file at the time that CVS created it; if the\ntimestamp differs with the actual modification time of the file it\nmeans the file has been modified. It is stored in the format used\nby the ISO C asctime() function (for example, 'Sun Apr 7 01:29:26\n1996'). One may write a string which is not in that format, for\nexample, 'Result of merge', to indicate that the file should always\nbe considered to be modified. This is not a special case; to see\nwhether a file is modified a program should take the timestamp of\nthe file and simply do a string compare with TIMESTAMP. If there\nwas a conflict, CONFLICT can be set to the modification time of the\nfile after the file has been written with conflict markers (*note\nConflicts example::). Thus if CONFLICT is subsequently the same as\nthe actual modification time of the file it means that the user has\nobviously not resolved the conflict. OPTIONS contains sticky\noptions (for example '-kb' for a binary file). TAGDATE contains\n'T' followed by a tag name, or 'D' for a date, followed by a sticky\ntag or date. Note that if TIMESTAMP contains a pair of timestamps\nseparated by a space, rather than a single timestamp, you are\ndealing with a version of CVS earlier than CVS 1.5 (not documented\nhere).\n\nThe timezone on the timestamp in CVS/Entries (local or universal)\nshould be the same as the operating system stores for the timestamp\nof the file itself. For example, on Unix the file's timestamp is\nin universal time (UT), so the timestamp in CVS/Entries should be\ntoo. On VMS, the file's timestamp is in local time, so CVS on VMS\nshould use local time. This rule is so that files do not appear to\nbe modified merely because the timezone changed (for example, to or\nfrom summer time).\n\nIf the first character of a line in 'Entries' is 'D', then it\nindicates a subdirectory. 'D' on a line all by itself indicates\nthat the program which wrote the 'Entries' file does record\nsubdirectories (therefore, if there is such a line and no other\nlines beginning with 'D', one knows there are no subdirectories).\nOtherwise, the line looks like:\n\nD/NAME/FILLER1/FILLER2/FILLER3/FILLER4\n\nwhere NAME is the name of the subdirectory, and all the FILLER\nfields should be silently ignored, for future expansion. Programs\nwhich modify 'Entries' files should preserve these fields.\n\nThe lines in the 'Entries' file can be in any order.\n\n'Entries.Log'\nThis file does not record any information beyond that in 'Entries',\nbut it does provide a way to update the information without having\nto rewrite the entire 'Entries' file, including the ability to\npreserve the information even if the program writing 'Entries' and\n'Entries.Log' abruptly aborts. Programs which are reading the\n'Entries' file should also check for 'Entries.Log'. If the latter\nexists, they should read 'Entries' and then apply the changes\nmentioned in 'Entries.Log'. After applying the changes, the\nrecommended practice is to rewrite 'Entries' and then delete\n'Entries.Log'. The format of a line in 'Entries.Log' is a single\ncharacter command followed by a space followed by a line in the\nformat specified for a line in 'Entries'. The single character\ncommand is 'A' to indicate that the entry is being added, 'R' to\nindicate that the entry is being removed, or any other character to\nindicate that the entire line in 'Entries.Log' should be silently\nignored (for future expansion). If the second character of the\nline in 'Entries.Log' is not a space, then it was written by an\nolder version of CVS (not documented here).\n\nPrograms which are writing rather than reading can safely ignore\n'Entries.Log' if they so choose.\n\n'Entries.Backup'\nThis is a temporary file. Recommended usage is to write a new\nentries file to 'Entries.Backup', and then to rename it\n(atomically, where possible) to 'Entries'.\n\n'Entries.Static'\nThe only relevant thing about this file is whether it exists or\nnot. If it exists, then it means that only part of a directory was\ngotten and CVS will not create additional files in that directory.\nTo clear it, use the 'update' command with the '-d' option, which\nwill get the additional files and remove 'Entries.Static'.\n\n'Tag'\nThis file contains per-directory sticky tags or dates. The first\ncharacter is 'T' for a branch tag, 'N' for a non-branch tag, or 'D'\nfor a date, or another character to mean the file should be\nsilently ignored, for future expansion. This character is followed\nby the tag or date. Note that per-directory sticky tags or dates\nare used for things like applying to files which are newly added;\nthey might not be the same as the sticky tags or dates on\nindividual files. For general information on sticky tags and\ndates, see *note Sticky tags::.\n\n'Notify'\nThis file stores notifications (for example, for 'edit' or\n'unedit') which have not yet been sent to the server. Its format\nis not yet documented here.\n\n'Notify.tmp'\nThis file is to 'Notify' as 'Entries.Backup' is to 'Entries'. That\nis, to write 'Notify', first write the new contents to 'Notify.tmp'\nand then (atomically where possible), rename it to 'Notify'.\n\n'Base'\nIf watches are in use, then an 'edit' command stores the original\ncopy of the file in the 'Base' directory. This allows the 'unedit'\ncommand to operate even if it is unable to communicate with the\nserver.\n\n'Baserev'\nThe file lists the revision for each of the files in the 'Base'\ndirectory. The format is:\n\nBNAME/REV/EXPANSION\n\nwhere EXPANSION should be ignored, to allow for future expansion.\n\n'Baserev.tmp'\nThis file is to 'Baserev' as 'Entries.Backup' is to 'Entries'.\nThat is, to write 'Baserev', first write the new contents to\n'Baserev.tmp' and then (atomically where possible), rename it to\n'Baserev'.\n\n'Template'\nThis file contains the template specified by the 'rcsinfo' file\n(*note rcsinfo::). It is only used by the client; the\nnon-client/server CVS consults 'rcsinfo' directly.\n", "subsections": [] }, "File: cvs.info, Node: Intro administrative files, Next: Multiple repositories, Prev: Working directory storage, Up: Repository": { "content": "", "subsections": [ { "name": "2.4 The administrative files", "content": "The directory '$CVSROOT/CVSROOT' contains some \"administrative files\".\n*Note Administrative files::, for a complete description. You can use\nCVS without any of these files, but some commands work better when at\nleast the 'modules' file is properly set up.\n\nThe most important of these files is the 'modules' file. It defines\nall modules in the repository. This is a sample 'modules' file.\n\nCVSROOT CVSROOT\nmodules CVSROOT modules\ncvs gnu/cvs\nrcs gnu/rcs\ndiff gnu/diff\ntc yoyodyne/tc\n\nThe 'modules' file is line oriented. In its simplest form each line\ncontains the name of the module, whitespace, and the directory where the\nmodule resides. The directory is a path relative to '$CVSROOT'. The\nlast four lines in the example above are examples of such lines.\n\nThe line that defines the module called 'modules' uses features that\nare not explained here. *Note modules::, for a full explanation of all\nthe available features.\n\n" } ] }, "You edit the administrative files in the same way that you would edit": { "content": "any other module. Use 'cvs checkout CVSROOT' to get a working copy,\nedit it, and commit your changes in the normal way.\n\nIt is possible to commit an erroneous administrative file. You can\noften fix the error and check in a new revision, but sometimes a\nparticularly bad error in the administrative file makes it impossible to\ncommit new revisions.\n", "subsections": [] }, "File: cvs.info, Node: Multiple repositories, Next: Creating a repository, Prev: Intro administrative files, Up: Repository": { "content": "", "subsections": [ { "name": "2.5 Multiple repositories", "content": "" } ] }, "In some situations it is a good idea to have more than one repository,": { "content": "for instance if you have two development groups that work on separate\nprojects without sharing any code. All you have to do to have several\nrepositories is to specify the appropriate repository, using the\n'CVSROOT' environment variable, the '-d' option to CVS, or (once you\nhave checked out a working directory) by simply allowing CVS to use the\nrepository that was used to check out the working directory (*note\nSpecifying a repository::).\n\nThe big advantage of having multiple repositories is that they can\nreside on different servers. With CVS version 1.10, a single command\ncannot recurse into directories from different repositories. With\ndevelopment versions of CVS, you can check out code from multiple\nservers into your working directory. CVS will recurse and handle all\nthe details of making connections to as many server machines as\nnecessary to perform the requested command. Here is an example of how\nto set up a working directory:\n\ncvs -d server1:/cvs co dir1\ncd dir1\ncvs -d server2:/root co sdir\ncvs update\n\nThe 'cvs co' commands set up the working directory, and then the 'cvs\nupdate' command will contact server2, to update the dir1/sdir\nsubdirectory, and server1, to update everything else.\n", "subsections": [] }, "File: cvs.info, Node: Creating a repository, Next: Backing up, Prev: Multiple repositories, Up: Repository": { "content": "", "subsections": [ { "name": "2.6 Creating a repository", "content": "" } ] }, "This section describes how to set up a CVS repository for any sort of": { "content": "access method. After completing the setup described in this section,\nyou should be able to access your CVS repository immediately via the\nlocal access method and several remote access methods. For more\ninformation on setting up remote access to the repository you create in\nthis section, please read the section on *Note Remote repositories::.\n\nTo set up a CVS repository, first choose the machine and disk on\nwhich you want to store the revision history of the source files. CPU\nand memory requirements are modest, so most machines should be adequate.\nFor details see *note Server requirements::.\n\nTo estimate disk space requirements, if you are importing RCS files\nfrom another system, the size of those files is the approximate initial\nsize of your repository, or if you are starting without any version\nhistory, a rule of thumb is to allow for the server approximately three\ntimes the size of the code to be under CVS for the repository (you will\neventually outgrow this, but not for a while). On the machines on which\nthe developers will be working, you'll want disk space for approximately\none working directory for each developer (either the entire tree or a\nportion of it, depending on what each developer uses).\n\nThe repository should be accessible (directly or via a networked\nfilesystem) from all machines which want to use CVS in server or local\nmode; the client machines need not have any access to it other than via\nthe CVS protocol. It is not normally possible to use CVS to read from a\nrepository which one only has read access to; CVS needs to be able to\ncreate lock files (*note Concurrency::).\n\nIf the environment variable '$CVSREADONLYFS' is defined, however, CVS\nwill allow read-only access without creating any history entries or\nreader lock files. This allows doing most usual repository operations\nexcept checkin in a fast way, although if any other user is accessing\nthe same data at the same time, it may lead to corrupt data. This mode\nis best used for publicly accessible anonymous CVS mirrors, not the main\nworking repository.\n\nTo create a repository, run the 'cvs init' command. It will set up\nan empty repository in the CVS root specified in the usual way (*note", "subsections": [] }, "Repository::). For example,": { "content": "cvs -d /usr/local/cvsroot init\n\n'cvs init' is careful to never overwrite any existing files in the\nrepository, so no harm is done if you run 'cvs init' on an already\nset-up repository.\n\nThe repository is created honouring the '$CVSUMASK' setting (*note\nCVSUMASK::), even the 'history' and 'val-tags' files are not created\nworld-writable any more as in previous CVS versions. History logging\nis, accordingly, configured to log write operations only; if you don't\nwant that, edit or remove the 'LogHistory' entry in the 'config' file\n(*note config::) and make sure that all users who need to write that\nfile can do so, for example by using a '$CVSUMASK' of 002 (which is also\nthe default) and putting everyone into the same Unix group (consider the\nsecurity implications if you really want to enable world-writable\nlogging).\n", "subsections": [] }, "File: cvs.info, Node: Backing up, Next: Moving a repository, Prev: Creating a repository, Up: Repository": { "content": "", "subsections": [ { "name": "2.7 Backing up a repository", "content": "" } ] }, "There is nothing particularly magical about the files in the repository;": { "content": "for the most part it is possible to back them up just like any other\nfiles. However, there are a few issues to consider.\n\nThe first is that to be paranoid, one should either not use CVS\nduring the backup, or have the backup program lock CVS while doing the\nbackup. To not use CVS, you might forbid logins to machines which can\naccess the repository, turn off your CVS server, or similar mechanisms.", "subsections": [] }, "The details would depend on your operating system and how you have CVS": { "content": "set up. To lock CVS, you would create '#cvs.rfl' locks in each\nrepository directory. See *note Concurrency::, for more on CVS locks.", "subsections": [] }, "Having said all this, if you just back up without any of these": { "content": "precautions, the results are unlikely to be particularly dire.", "subsections": [] }, "Restoring from backup, the repository might be in an inconsistent state,": { "content": "but this would not be particularly hard to fix manually.\n\nWhen you restore a repository from backup, assuming that changes in\nthe repository were made after the time of the backup, working\ndirectories which were not affected by the failure may refer to\nrevisions which no longer exist in the repository. Trying to run CVS in\nsuch directories will typically produce an error message. One way to\nget those changes back into the repository is as follows:\n\n* Get a new working directory.\n\n* Copy the files from the working directory from before the failure\nover to the new working directory (do not copy the contents of the\n'CVS' directories, of course).\n\n* Working in the new working directory, use commands such as 'cvs\nupdate' and 'cvs diff' to figure out what has changed, and then\nwhen you are ready, commit the changes into the repository.\n", "subsections": [] }, "File: cvs.info, Node: Moving a repository, Next: Remote repositories, Prev: Backing up, Up: Repository": { "content": "", "subsections": [ { "name": "2.8 Moving a repository", "content": "" } ] }, "Just as backing up the files in the repository is pretty much like": { "content": "backing up any other files, if you need to move a repository from one\nplace to another it is also pretty much like just moving any other\ncollection of files.\n\nThe main thing to consider is that working directories point to the\nrepository. The simplest way to deal with a moved repository is to just\nget a fresh working directory after the move. Of course, you'll want to\nmake sure that the old working directory had been checked in before the\nmove, or you figured out some other way to make sure that you don't lose\nany changes. If you really do want to reuse the existing working\ndirectory, it should be possible with manual surgery on the\n'CVS/Repository' files. You can see *note Working directory storage::,\nfor information on the 'CVS/Repository' and 'CVS/Root' files, but unless\nyou are sure you want to bother, it probably isn't worth it.\n", "subsections": [] }, "File: cvs.info, Node: Remote repositories, Next: Read-only access, Prev: Moving a repository, Up: Repository": { "content": "", "subsections": [ { "name": "2.9 Remote repositories", "content": "" } ] }, "Your working copy of the sources can be on a different machine than the": { "content": "repository. Using CVS in this manner is known as \"client/server\"\noperation. You run CVS on a machine which can mount your working\ndirectory, known as the \"client\", and tell it to communicate to a\nmachine which can mount the repository, known as the \"server\".", "subsections": [] }, "Generally, using a remote repository is just like using a local one,": { "content": "except that the format of the repository name is:\n\n[:METHOD:][[USER][:PASSWORD]@]HOSTNAME[:[PORT]]/path/to/repository\n\nSpecifying a password in the repository name is not recommended\nduring checkout, since this will cause CVS to store a cleartext copy of\nthe password in each created directory. 'cvs login' first instead\n(*note Password authentication client::).\n\nThe details of exactly what needs to be set up depend on how you are\nconnecting to the server.\n\n* Menu:\n\n* Server requirements:: Memory and other resources for servers\n* The connection method:: Connection methods and method options\n* Connecting via rsh:: Using the 'rsh' program to connect\n* Password authenticated:: Direct connections using passwords\n* GSSAPI authenticated:: Direct connections using GSSAPI\n* Kerberos authenticated:: Direct connections with Kerberos\n* Connecting via fork:: Using a forked 'cvs server' to connect\n* Write proxies:: Distributing load across several CVS servers\n\nFor the protocol specification, *note the CVS client/server protocol:\n(cvsclient)Top.\n", "subsections": [] }, "File: cvs.info, Node: Server requirements, Next: The connection method, Up: Remote repositories": { "content": "", "subsections": [] }, "The quick answer to what sort of machine is suitable as a server is that": { "content": "requirements are modest--a server with 32M of memory or even less can\nhandle a fairly large source tree with a fair amount of activity.\n\nThe real answer, of course, is more complicated. Estimating the\nknown areas of large memory consumption should be sufficient to estimate\nmemory requirements. There are two such areas documented here; other\nmemory consumption should be small by comparison (if you find that is\nnot the case, let us know, as described in *note BUGS::, so we can\nupdate this documentation).\n\nThe first area of big memory consumption is large checkouts, when\nusing the CVS server. The server consists of two processes for each\nclient that it is serving. Memory consumption on the child process\nshould remain fairly small. Memory consumption on the parent process,\nparticularly if the network connection to the client is slow, can be\nexpected to grow to slightly more than the size of the sources in a\nsingle directory, or two megabytes, whichever is larger.\n\nMultiplying the size of each CVS server by the number of servers\nwhich you expect to have active at one time should give an idea of\nmemory requirements for the server. For the most part, the memory\nconsumed by the parent process probably can be swap space rather than\nphysical memory.\n\nThe second area of large memory consumption is 'diff', when checking\nin large files. This is required even for binary files. The rule of\nthumb is to allow about ten times the size of the largest file you will\nwant to check in, although five times may be adequate. For example, if\nyou want to check in a file which is 10 megabytes, you should have 100\nmegabytes of memory on the machine doing the checkin (the server machine\nfor client/server, or the machine running CVS for non-client/server).", "subsections": [] }, "This can be swap space rather than physical memory. Because the memory": { "content": "is only required briefly, there is no particular need to allow memory\nfor more than one such checkin at a time.\n\nResource consumption for the client is even more modest--any machine\nwith enough capacity to run the operating system in question should have\nlittle trouble.\n\nFor information on disk space requirements, see *note Creating a\nrepository::.\n", "subsections": [] }, "File: cvs.info, Node: The connection method, Next: Connecting via rsh, Prev: Server requirements, Up: Remote repositories": { "content": "In its simplest form, the METHOD portion of the repository string (*note", "subsections": [] }, "Remote repositories::) may be one of 'ext', 'fork', 'gserver',": { "content": "'kserver', 'local', 'pserver', and, on some platforms, 'server'.\n\nIf METHOD is not specified, and the repository name starts with a\n'/', then the default is 'local'. If METHOD is not specified, and the\nrepository name does not start with a '/', then the default is 'ext' or\n'server', depending on your platform; both the 'ext' and 'server'\nmethods are described in *note Connecting via rsh::.\n\nThe 'ext', 'fork', 'gserver', and 'pserver' connection methods all\naccept optional method options, specified as part of the METHOD string,\nlike so:\n\n:METHOD[;OPTION=ARG...]:OTHERCONNECTIONDATA\n\nCVS is not sensitive to the case of METHOD or OPTION, though it may\nsometimes be sensitive to the case of ARG. The possible method options\nare as follows:\n\n'proxy=HOSTNAME'\n'proxyport=PORT'\nThese two method options can be used to connect via an HTTP tunnel\nstyle web proxy. HOSTNAME should be the name of the HTTP proxy\nserver to connect through and PORT is the port number on the HTTP\nproxy server to connect via. PORT defaults to 8080.\n\nNOTE: An HTTP proxy server is not the same as a CVS write proxy\nserver - please see *note Write proxies:: for more on CVS write\nproxies.\n\nFor example, to connect pserver via a web proxy listening on port\n8000 of www.myproxy.net, you would use a method of:\n\n:pserver;proxy=www.myproxy.net;proxyport=8000:CONNSTR\n\nNOTE: In the above example, the pserver connection string CONNSTR\nis still required to connect and authenticate to the CVS server, as\nnoted in the upcoming sections on password authentication,\n'gserver', and 'kserver'. The example above only demonstrates a\nmodification to the METHOD portion of the repository name.\n\nThese options first appeared in CVS version 1.12.7 and are valid as\nmodifcations to the 'gserver' and 'pserver' connection methods.\n\n'CVSRSH=PATH'\nThis method option can be used with the 'ext' method to specify the\npath the CVS client will use to find the remote shell used to\ncontact the CVS server and takes precedence over any path specified\nin the '$CVSRSH' environment variable (*note Connecting via\nrsh::). For example, to connect to a CVS server via the local\n'/path/to/ssh/command' command, you could choose to specify the\nfollowing PATH via the 'CVSRSH' method option:\n\n:ext;CVSRSH=/path/to/ssh/command:EXTCONNECTIONSTRING\n\nThis method option first appeared in CVS version 1.12.11 and is\nvalid only as a modifcation to the 'ext' connection method.\n\n'CVSSERVER=PATH'\nThis method option can be used with the 'ext' and 'fork' methods to\nspecify the path CVS will use to find the CVS executable on the CVS\nserver and takes precedence over any path specified in the\n'$CVSSERVER' environment variable (*note Connecting via rsh::).\nFor example, to select the remote '/path/to/cvs/command' executable\nas your CVS server application on the CVS server machine, you could\nchoose to specify the following PATH via the 'CVSSERVER' method\noption:\n\n:ext;CVSSERVER=/path/to/cvs/command:EXTCONNECTIONSTRING\n\nor, to select an executable named 'cvs-1.12.11', assuming it is in\nyour '$PATH' on the CVS server:\n\n:ext;CVSSERVER=cvs-1.12.11:EXTCONNECTIONSTRING\n\nThis method option first appeared in CVS version 1.12.11 and is\nvalid as a modifcation to both the 'ext' and 'fork' connection\nmethods.\n\n'Redirect=BOOLEAN-STATE'\nThe 'Redirect' method option determines whether the CVS client will\nallow a CVS server to redirect it to a different CVS server,\nusually for write requests, as in a write proxy setup.\n\nA BOOLEAN-STATE of any value acceptable for boolean\n'CVSROOT/config' file options is acceptable here (*note config::).\nFor example, 'on', 'off', 'true', and 'false' are all valid values\nfor BOOLEAN-STATE. BOOLEAN-STATE for the 'Redirect' method option\ndefaults to 'on'.\n\nThis option will have no effect when talking to any non-secondary\nCVS server. For more on write proxies and secondary servers,\nplease see *note Write proxies::.\n\nThis method option first appeared in CVS version 1.12.11 and is\nvalid only as a modifcation to the 'ext' connection method.\n\nAs a further example, to combine both the 'CVSRSH' and 'CVSSERVER'\noptions, a method specification like the following would work:\n\n:ext;CVSRSH=/path/to/ssh/command;CVSSERVER=/path/to/cvs/command:\n\nThis means that you would not need to have the 'CVSSERVER' or\n'CVSRSH' environment variables set correctly. See *note Connecting via\nrsh::, for more details on these environment variables.\n", "subsections": [] }, "File: cvs.info, Node: Connecting via rsh, Next: Password authenticated, Prev: The connection method, Up: Remote repositories": { "content": "CVS uses the 'rsh' protocol to perform these operations, so the remote\nuser host needs to have a '.rhosts' file which grants access to the\nlocal user. Note that the program that CVS uses for this purpose may be\nspecified using the '--with-rsh' flag to configure.\n\nFor example, suppose you are the user 'mozart' on the local machine\n'toe.example.com', and the server machine is 'faun.example.org'. On\nfaun, put the following line into the file '.rhosts' in 'bach''s home\ndirectory:\n\ntoe.example.com mozart\n", "subsections": [] }, "Then test that 'rsh' is working with": { "content": "rsh -l bach faun.example.org 'echo $PATH'\n\nNext you have to make sure that 'rsh' will be able to find the\nserver. Make sure that the path which 'rsh' printed in the above\nexample includes the directory containing a program named 'cvs' which is\nthe server. You need to set the path in '.bashrc', '.cshrc', etc., not\n'.login' or '.profile'. Alternately, you can set the environment\nvariable 'CVSSERVER' on the client machine to the filename of the\nserver you want to use, for example '/usr/local/bin/cvs-1.6'. For the\n'ext' and 'fork' methods, you may also specify CVSSERVER as an option\nin the CVSROOT so that you may use different servers for differnt roots.\nSee *note Remote repositories:: for more details.\n\nThere is no need to edit 'inetd.conf' or start a CVS server daemon.\n\nThere are two access methods that you use in 'CVSROOT' for rsh.\n':server:' specifies an internal rsh client, which is supported only by\nsome CVS ports. This is not supported on most Unix-style systems.\n':ext:' specifies an external rsh program. By default this is 'rsh'\n(unless otherwise specified by the '--with-rsh' flag to configure) but\nyou may set the 'CVSRSH' environment variable to invoke another program\nwhich can access the remote server (for example, 'remsh' on HP-UX 9\nbecause 'rsh' is something different, or 'ssh' to allow the use of\nsecure and/or compressed connections). It must be a program which can\ntransmit data to and from the server without modifying it; for example\nthe Windows NT 'rsh' is not suitable since it by default translates\nbetween CRLF and LF. The OS/2 CVS port has a hack to pass '-b' to 'rsh'\nto get around this, but since this could potentially cause problems for\nprograms other than the standard 'rsh', it may change in the future. If\nyou set 'CVSRSH' to 'SSH' or some other rsh replacement, the\ninstructions in the rest of this section concerning '.rhosts' and so on\nare likely to be inapplicable; consult the documentation for your rsh\nreplacement.\n\nIn the Debian and MirBSD versions of CVS, you can also specify\n':extssh:' to force use of the Secure Shell, or ':ext=prog:' or\n':ext=/path/to/prog:' to specify the remote shell to use without needing\nto touch the 'CVSRSH' environment variable.\n\nYou may choose to specify the CVSRSH option as a method option in\nthe CVSROOT string to allow you to use different connection tools for\ndifferent roots (*note The connection method::). For example, allowing\nsome roots to use 'CVSRSH=remsh' and some to use 'CVSRSH=ssh' for the\n'ext' method. See also the *note Remote repositories:: for more\ndetails.\n\nContinuing our example, supposing you want to access the module 'foo'\nin the repository '/usr/local/cvsroot/', on machine 'faun.example.org',\nyou are ready to go:\n\ncvs -d :ext:bach@faun.example.org:/usr/local/cvsroot checkout foo\n\n(The 'bach@' can be omitted if the username is the same on both the\nlocal and remote hosts.)\n", "subsections": [] }, "File: cvs.info, Node: Password authenticated, Next: GSSAPI authenticated, Prev: Connecting via rsh, Up: Remote repositories": { "content": "The CVS client can also connect to the server using a password protocol.", "subsections": [] }, "This is particularly useful if using 'rsh' is not feasible (for example,": { "content": "the server is behind a firewall), and Kerberos also is not available.\n\nTo use this method, it is necessary to make some adjustments on both\nthe server and client sides.\n\n* Menu:\n\n* Password authentication server:: Setting up the server\n* Password authentication client:: Using the client\n* Password authentication security:: What this method does and does not do\n", "subsections": [] }, "File: cvs.info, Node: Password authentication server, Next: Password authentication client, Up: Password authenticated": { "content": "2.9.4.1 Setting up the server for password authentication\n.........................................................\n", "subsections": [] }, "First of all, you probably want to tighten the permissions on the": { "content": "'$CVSROOT' and '$CVSROOT/CVSROOT' directories. See *note Password\nauthentication security::, for more details.\n\nOn the server side, the file '/etc/inetd.conf' needs to be edited so\n'inetd' knows to run the command 'cvs pserver' when it receives a\nconnection on the right port. By default, the port number is 2401; it\nwould be different if your client were compiled with 'CVSAUTHPORT'\ndefined to something else, though. This can also be specified in the\nCVSROOT variable (*note Remote repositories::) or overridden with the\nCVSCLIENTPORT environment variable (*note Environment variables::).\n\nIf your 'inetd' allows raw port numbers in '/etc/inetd.conf', then\nthe following (all on a single line in 'inetd.conf') should be\nsufficient:\n\n2401 stream tcp nowait root /usr/local/bin/cvs\ncvs -f --allow-root=/usr/cvsroot pserver\n\n(You could also use the '-T' option to specify a temporary directory.)\n\nThe '--allow-root' option specifies the allowable CVSROOT directory.", "subsections": [] }, "Clients which attempt to use a different CVSROOT directory will not be": { "content": "allowed to connect. To allow a whole class of CVSROOT, specify a POSIX\nextended regular expression to match allowed directories with the\n'--allow-root-regexp' option. These options may be used in conjunction,\nand both options may be repeated to allow access to multiple CVSROOT\ndirectories and classes of directories. (Unfortunately, many versions\nof 'inetd' have very small limits on the number of arguments and/or the\ntotal length of the command. The usual solution to this problem is to\nhave 'inetd' run a shell script which then invokes CVS with the\nnecessary arguments.)\n\nIf your 'inetd' wants a symbolic service name instead of a raw port\nnumber, then put this in '/etc/services':\n\ncvspserver 2401/tcp\n\nand put 'cvspserver' instead of '2401' in 'inetd.conf'.\n\nIf your system uses 'xinetd' instead of 'inetd', the procedure is\nslightly different. Create a file called '/etc/xinetd.d/cvspserver'\ncontaining the following:\n\nservice cvspserver\n{\nport = 2401\nsockettype = stream\nprotocol = tcp\nwait = no\nuser = root\npassenv = PATH\nserver = /usr/local/bin/cvs\nserverargs = -f --allow-root=/usr/cvsroot pserver\n}\n\n(If 'cvspserver' is defined in '/etc/services', you can omit the 'port'\nline.)\n\nOnce the above is taken care of, restart your 'inetd', or do whatever\nis necessary to force it to reread its initialization files.\n\nIf you are having trouble setting this up, see *note Connection::.\n\nBecause the client stores and transmits passwords in cleartext\n(almost--see *note Password authentication security::, for details), a\nseparate CVS password file is generally used, so people don't compromise\ntheir regular passwords when they access the repository. This file is\n'$CVSROOT/CVSROOT/passwd' (*note Intro administrative files::). It uses\na colon-separated format, similar to '/etc/passwd' on Unix systems,\nexcept that it has fewer fields: CVS username, optional password, and an\noptional system username for CVS to run as if authentication succeeds.\nHere is an example 'passwd' file with five entries:\n\nanonymous:\nbach:ULtgRLXo7NRxs\nspwang:1sOp854gDF3DY\nmelissa:tGX1fS8sun6rY:pubcvs\nqproj:XR4EZcEs0szik:pubcvs\n\n(The passwords are encrypted according to the standard Unix 'crypt()'\nfunction, so it is possible to paste in passwords directly from regular", "subsections": [] }, "Unix '/etc/passwd' files.)": { "content": "The first line in the example will grant access to any CVS client\nattempting to authenticate as user 'anonymous', no matter what password\nthey use, including an empty password. (This is typical for sites\ngranting anonymous read-only access; for information on how to do the\n\"read-only\" part, see *note Read-only access::.)\n\nThe second and third lines will grant access to 'bach' and 'spwang'\nif they supply their respective plaintext passwords.\n\nThe fourth line will grant access to 'melissa', if she supplies the\ncorrect password, but her CVS operations will actually run on the server\nside under the system user 'pubcvs'. Thus, there need not be any system\nuser named 'melissa', but there must be one named 'pubcvs'.\n\nThe fifth line shows that system user identities can be shared: any\nclient who successfully authenticates as 'qproj' will actually run as\n'pubcvs', just as 'melissa' does. That way you could create a single,\nshared system user for each project in your repository, and give each\ndeveloper their own line in the '$CVSROOT/CVSROOT/passwd' file. The CVS\nusername on each line would be different, but the system username would\nbe the same. The reason to have different CVS usernames is that CVS\nwill log their actions under those names: when 'melissa' commits a\nchange to a project, the checkin is recorded in the project's history\nunder the name 'melissa', not 'pubcvs'. And the reason to have them\nshare a system username is so that you can arrange permissions in the\nrelevant area of the repository such that only that account has\nwrite-permission there.\n\nIf the system-user field is present, all password-authenticated CVS\ncommands run as that user; if no system user is specified, CVS simply\ntakes the CVS username as the system username and runs commands as that\nuser. In either case, if there is no such user on the system, then the\nCVS operation will fail (regardless of whether the client supplied a\nvalid password).\n\nThe password and system-user fields can both be omitted (and if the\nsystem-user field is omitted, then also omit the colon that would have\nseparated it from the encrypted password). For example, this would be a\nvalid '$CVSROOT/CVSROOT/passwd' file:\n\nanonymous::pubcvs\nfish:rKa5jzULzmhOo:kfogel\nsussman:1sOp854gDF3DY\n", "subsections": [] }, "When the password field is omitted or empty, then the client's": { "content": "authentication attempt will succeed with any password, including the\nempty string. However, the colon after the CVS username is always\nnecessary, even if the password is empty.\n\nCVS can also fall back to use system authentication. When\nauthenticating a password, the server first checks for the user in the\n'$CVSROOT/CVSROOT/passwd' file. If it finds the user, it will use that\nentry for authentication as described above. But if it does not find\nthe user, or if the CVS 'passwd' file does not exist, then the server\ncan try to authenticate the username and password using the operating\nsystem's user-lookup routines (this \"fallback\" behavior can be disabled\nby setting 'SystemAuth=no' in the CVS 'config' file, *note config::).\n\nThe default fallback behavior is to look in '/etc/passwd' for this\nsystem user unless your system has PAM (Pluggable Authentication", "subsections": [] }, "Modules) and your CVS server executable was configured to use it at": { "content": "compile time (using './configure --enable-pam' - see the INSTALL file\nfor more). In this case, PAM will be consulted instead. This means\nthat CVS can be configured to use any password authentication source PAM\ncan be configured to use (possibilities include a simple UNIX password,\nNIS, LDAP, and others) in its global configuration file (usually\n'/etc/pam.conf' or possibly '/etc/pam.d/cvs'). See your PAM\ndocumentation for more details on PAM configuration.\n\nNote that PAM is an experimental feature in CVS and feedback is\nencouraged. Please send a mail to one of the CVS mailing lists\n('info-cvs@nongnu.org' or 'bug-cvs@nongnu.org') if you use the CVS PAM\nsupport.\n\nWARNING: Using PAM gives the system administrator much more\nflexibility about how CVS users are authenticated but no more security\nthan other methods. See below for more.\n\nCVS needs an \"auth\", \"account\" and \"session\" module in the PAM\nconfiguration file. A typical PAM configuration would therefore have\nthe following lines in '/etc/pam.conf' to emulate the standard CVS\nsystem '/etc/passwd' authentication:\n\ncvs\tauth\t required\tpamunix.so\ncvs\taccount\t required\tpamunix.so\ncvs\tsession\t required\tpamunix.so\n\nThe the equivalent '/etc/pam.d/cvs' would contain\n\nauth\t required\tpamunix.so\naccount\t required\tpamunix.so\nsession\t required\tpamunix.so\n\nSome systems require a full path to the module so that 'pamunix.so'\n(Linux) would become something like\n'/usr/lib/security/$ISA/pamunix.so.1' (Sun Solaris). See the\n'contrib/pam' subdirectory of the CVS source distribution for further\nexample configurations.\n\nThe PAM service name given above as \"cvs\" is just the service name in\nthe default configuration and can be set using './configure\n--with-hardcoded-pam-service-name=' before compiling.\nCVS can also be configured to use whatever name it is invoked as as its\nPAM service name using './configure\n--without-hardcoded-pam-service-name', but this feature should not be\nused if you may not have control of the name CVS will be invoked as.\n\nBe aware, also, that falling back to system authentication might be a\nsecurity risk: CVS operations would then be authenticated with that\nuser's regular login password, and the password flies across the network\nin plaintext. See *note Password authentication security:: for more on\nthis. This may be more of a problem with PAM authentication because it\nis likely that the source of the system password is some central\nauthentication service like LDAP which is also used to authenticate\nother services.\n\nOn the other hand, PAM makes it very easy to change your password\nregularly. If they are given the option of a one-password system for\nall of their activities, users are often more willing to change their\npassword on a regular basis.\n\nIn the non-PAM configuration where the password is stored in the\n'CVSROOT/passwd' file, it is difficult to change passwords on a regular\nbasis since only administrative users (or in some cases processes that\nact as an administrative user) are typically given access to modify this\nfile. Either there needs to be some hand-crafted web page or set-uid\nprogram to update the file, or the update needs to be done by submitting\na request to an administrator to perform the duty by hand. In the first\ncase, having to remember to update a separate password on a periodic\nbasis can be difficult. In the second case, the manual nature of the\nchange will typically mean that the password will not be changed unless\nit is absolutely necessary.\n\nNote that PAM administrators should probably avoid configuring\none-time-passwords (OTP) for CVS authentication/authorization. If OTPs\nare desired, the administrator may wish to encourage the use of one of\nthe other Client/Server access methods. See the section on *note Remote\nrepositories:: for a list of other methods.\n\nRight now, the only way to put a password in the CVS 'passwd' file is\nto paste it there from somewhere else. Someday, there may be a 'cvs\npasswd' command.\n\nUnlike many of the files in '$CVSROOT/CVSROOT', it is normal to edit\nthe 'passwd' file in-place, rather than via CVS. This is because of the\npossible security risks of having the 'passwd' file checked out to\npeople's working copies. If you do want to include the 'passwd' file in\ncheckouts of '$CVSROOT/CVSROOT', see *note checkoutlist::.\n", "subsections": [] }, "File: cvs.info, Node: Password authentication client, Next: Password authentication security, Prev: Password authentication server, Up: Password authenticated": { "content": "2.9.4.2 Using the client with password authentication\n.....................................................\n", "subsections": [] }, "To run a CVS command on a remote repository via the": { "content": "password-authenticating server, one specifies the 'pserver' protocol,\noptional username, repository host, an optional port number, and path to\nthe repository. For example:\n\ncvs -d :pserver:faun.example.org:/usr/local/cvsroot checkout someproj\n\nor\n\nCVSROOT=:pserver:bach@faun.example.org:2401/usr/local/cvsroot\ncvs checkout someproj\n\nHowever, unless you're connecting to a public-access repository\n(i.e., one where that username doesn't require a password), you'll need\nto supply a password or \"log in\" first. Logging in verifies your\npassword with the repository and stores it in a file. It's done with\nthe 'login' command, which will prompt you interactively for the\npassword if you didn't supply one as part of $CVSROOT:\n\ncvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login\nCVS password:\n\nor\n\ncvs -d :pserver:bach:p4ss30rd@faun.example.org:/usr/local/cvsroot login\n\nAfter you enter the password, CVS verifies it with the server. If\nthe verification succeeds, then that combination of username, host,\nrepository, and password is permanently recorded, so future transactions\nwith that repository won't require you to run 'cvs login'. (If\nverification fails, CVS will exit complaining that the password was\nincorrect, and nothing will be recorded.)\n\nThe records are stored, by default, in the file '$HOME/.cvspass'.", "subsections": [] }, "That file's format is human-readable, and to a degree human-editable,": { "content": "but note that the passwords are not stored in cleartext--they are\ntrivially encoded to protect them from \"innocent\" compromise (i.e.,\ninadvertent viewing by a system administrator or other non-malicious\nperson).\n\nYou can change the default location of this file by setting the\n'CVSPASSFILE' environment variable. If you use this variable, make\nsure you set it before 'cvs login' is run. If you were to set it\nafter running 'cvs login', then later CVS commands would be unable to\nlook up the password for transmission to the server.\n\nOnce you have logged in, all CVS commands using that remote\nrepository and username will authenticate with the stored password. So,\nfor example\n\ncvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo\n\nshould just work (unless the password changes on the server side, in\nwhich case you'll have to re-run 'cvs login').\n\nNote that if the ':pserver:' were not present in the repository\nspecification, CVS would assume it should use 'rsh' to connect with the\nserver instead (*note Connecting via rsh::).\n\nOf course, once you have a working copy checked out and are running\nCVS commands from within it, there is no longer any need to specify the\nrepository explicitly, because CVS can deduce the repository from the\nworking copy's 'CVS' subdirectory.\n\nThe password for a given remote repository can be removed from the\n'CVSPASSFILE' by using the 'cvs logout' command.\n", "subsections": [] }, "File: cvs.info, Node: Password authentication security, Prev: Password authentication client, Up: Password authenticated": { "content": "2.9.4.3 Security considerations with password authentication\n............................................................\n", "subsections": [] }, "The passwords are stored on the client side in a trivial encoding of the": { "content": "cleartext, and transmitted in the same encoding. The encoding is done\nonly to prevent inadvertent password compromises (i.e., a system\nadministrator accidentally looking at the file), and will not prevent\neven a naive attacker from gaining the password.\n\nThe separate CVS password file (*note Password authentication\nserver::) allows people to use a different password for repository\naccess than for login access. On the other hand, once a user has\nnon-read-only access to the repository, she can execute programs on the\nserver system through a variety of means. Thus, repository access\nimplies fairly broad system access as well. It might be possible to\nmodify CVS to prevent that, but no one has done so as of this writing.\n\nNote that because the '$CVSROOT/CVSROOT' directory contains 'passwd'\nand other files which are used to check security, you must control the\npermissions on this directory as tightly as the permissions on '/etc'.\nThe same applies to the '$CVSROOT' directory itself and any directory\nabove it in the tree. Anyone who has write access to such a directory\nwill have the ability to become any user on the system. Note that these\npermissions are typically tighter than you would use if you are not\nusing pserver.\n\nIn summary, anyone who gets the password gets repository access\n(which may imply some measure of general system access as well). The\npassword is available to anyone who can sniff network packets or read a\nprotected (i.e., user read-only) file. If you want real security, get\nKerberos.\n", "subsections": [] }, "File: cvs.info, Node: GSSAPI authenticated, Next: Kerberos authenticated, Prev: Password authenticated, Up: Remote repositories": { "content": "GSSAPI is a generic interface to network security systems such as", "subsections": [] }, "Kerberos 5. If you have a working GSSAPI library, you can have CVS": { "content": "connect via a direct TCP connection, authenticating with GSSAPI.\n\nTo do this, CVS needs to be compiled with GSSAPI support; when\nconfiguring CVS it tries to detect whether GSSAPI libraries using", "subsections": [] }, "Kerberos version 5 are present. You can also use the '--with-gssapi'": { "content": "flag to configure.\n\nThe connection is authenticated using GSSAPI, but the message stream\nis not authenticated by default. You must use the '-a' global option\nto request stream authentication.\n\nThe data transmitted is not encrypted by default. Encryption\nsupport must be compiled into both the client and the server; use the\n'--enable-encrypt' configure option to turn it on. You must then use\nthe '-x' global option to request encryption.\n\nGSSAPI connections are handled on the server side by the same server\nwhich handles the password authentication server; see *note Password\nauthentication server::. If you are using a GSSAPI mechanism such as", "subsections": [] }, "Kerberos which provides for strong authentication, you will probably": { "content": "want to disable the ability to authenticate via cleartext passwords. To\ndo so, create an empty 'CVSROOT/passwd' password file, and set\n'SystemAuth=no' in the config file (*note config::).\n\nThe GSSAPI server uses a principal name of cvs/HOSTNAME, where\nHOSTNAME is the canonical name of the server host. You will have to set\nthis up as required by your GSSAPI mechanism.\n\nTo connect using GSSAPI, use the ':gserver:' method. For example,\n\ncvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo\n", "subsections": [] }, "File: cvs.info, Node: Kerberos authenticated, Next: Connecting via fork, Prev: GSSAPI authenticated, Up: Remote repositories": { "content": "", "subsections": [] }, "The easiest way to use Kerberos is to use the Kerberos 'rsh', as": { "content": "described in *note Connecting via rsh::. The main disadvantage of using\nrsh is that all the data needs to pass through additional programs, so\nit may be slower. So if you have Kerberos installed you can connect via\na direct TCP connection, authenticating with Kerberos.\n\nThis section concerns the Kerberos network security system, version\n4. Kerberos version 5 is supported via the GSSAPI generic network\nsecurity interface, as described in the previous section.\n\nTo do this, CVS needs to be compiled with Kerberos support; when\nconfiguring CVS it tries to detect whether Kerberos is present or you\ncan use the '--with-krb4' flag to configure.\n\nThe data transmitted is not encrypted by default. Encryption\nsupport must be compiled into both the client and server; use the\n'--enable-encryption' configure option to turn it on. You must then use\nthe '-x' global option to request encryption.\n\nThe CVS client will attempt to connect to port 1999 by default.\n\nWhen you want to use CVS, get a ticket in the usual way (generally\n'kinit'); it must be a ticket which allows you to log into the server\nmachine. Then you are ready to go:\n\ncvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo\n\nPrevious versions of CVS would fall back to a connection via rsh;\nthis version will not do so.\n", "subsections": [] }, "File: cvs.info, Node: Connecting via fork, Next: Write proxies, Prev: Kerberos authenticated, Up: Remote repositories": { "content": "", "subsections": [] }, "This access method allows you to connect to a repository on your local": { "content": "disk via the remote protocol. In other words it does pretty much the\nsame thing as ':local:', but various quirks, bugs and the like are those\nof the remote CVS rather than the local CVS.\n\nFor day-to-day operations you might prefer either ':local:' or\n':fork:', depending on your preferences. Of course ':fork:' comes in\nparticularly handy in testing or debugging 'cvs' and the remote\nprotocol. Specifically, we avoid all of the network-related\nsetup/configuration, timeouts, and authentication inherent in the other\nremote access methods but still create a connection which uses the\nremote protocol.\n\nTo connect using the 'fork' method, use ':fork:' and the pathname to\nyour local repository. For example:\n\ncvs -d :fork:/usr/local/cvsroot checkout foo\n\nAs with ':ext:', the server is called 'cvs' by default, or the value\nof the 'CVSSERVER' environment variable.\n", "subsections": [] }, "File: cvs.info, Node: Write proxies, Prev: Connecting via fork, Up: Remote repositories": { "content": "CVS can be configured to distribute usage across several CVS servers.\nThis is accomplished by means of one or more \"write proxies\", or\n\"secondary servers\", for a single \"primary server\".\n\nWhen a CVS client accesses a secondary server and only sends read\nrequests, then the secondary server handles the entire request. If the\nclient sends any write requests, however, the secondary server asks the\nclient to redirect its write request to the primary server, if the\nclient supports redirect requests, and otherwise becomes a transparent\nproxy for the primary server, which actually handles the write request.\n\nIn this manner, any number of read-only secondary servers may be\nconfigured as write proxies for the primary server, effectively\ndistributing the load from all read operations between the secondary\nservers and restricting the load on the primary server to write\noperations and pushing changes to the secondaries.\n\nPrimary servers will not automatically push changes to secondaries.\nThis must be configured via 'loginfo', 'postadmin', 'posttag', &\n'postwatch' scripts (*note Trigger Scripts::) like the following:\n\nALL\trsync -gopr -essh ./ secondary:/cvsroot/%p &\n\nYou would probably actually want to lock directories for write on the\nsecondary and for read on the primary before running the 'rsync' in the\nabove example, but describing such a setup is beyond the scope of this\ndocument.\n\nA secondary advantage of a write proxy setup is that users pointing\nat the secondary server can still execute fast read operations while on\na network that connects to the primary over a slow link or even one\nwhere the link to the primary is periodically broken. Only write\noperations will require the network link to the primary.\n\nTo configure write proxies, the primary must be specified with the\n'PrimaryServer' option in 'CVSROOT/config' (*note config::). For the\ntransparent proxy mode to work, all secondary servers must also be\nrunning the same version of the CVS server, or at least one that\nprovides the same list of supported requests to the client as the\nprimary server. This is not necessary for redirection.\n\nOnce a primary server is configured, secondary servers may be\nconfigured by:\n\n1. Duplicating the primary repository at the new location.\n2. Setting up the 'loginfo', 'postadmin', 'posttag', and 'postwatch'\nfiles on the primary to propagate writes to the new secondary.\n3. Configure remote access to the secondary(ies) as you would\nconfigure access to any other CVS server (*note Remote\nrepositories::).\n4. Ensuring that '--allow-root=SECONDARY-CVSROOT' is passed to *all*\nincovations of the secondary server if the path to the CVS\nrepository directory is different on the two servers and you wish\nto support clients that do not handle the 'Redirect' resopnse (CVS\n1.12.9 and earlier clients do not handle the 'Redirect' response).\n\nPlease note, again, that writethrough proxy suport requires\n'--allow-root=SECONDARY-CVSROOT' to be specified for *all*\nincovations of the secondary server, not just 'pserver'\ninvocations. This may require a wrapper script for the CVS\nexecutable on your server machine.\n", "subsections": [] }, "File: cvs.info, Node: Read-only access, Next: Server temporary directory, Prev: Remote repositories, Up: Repository": { "content": "", "subsections": [ { "name": "2.10 Read-only repository access", "content": "" } ] }, "It is possible to grant read-only repository access to people using the": { "content": "password-authenticated server (*note Password authenticated::). (The\nother access methods do not have explicit support for read-only users\nbecause those methods all assume login access to the repository machine\nanyway, and therefore the user can do whatever local file permissions\nallow her to do.)\n\nA user who has read-only access can do only those CVS operations\nwhich do not modify the repository, except for certain \"administrative\"\nfiles (such as lock files and the history file). It may be desirable to\nuse this feature in conjunction with user-aliasing (*note Password\nauthentication server::).\n\nUnlike with previous versions of CVS, read-only users should be able\nmerely to read the repository, and not to execute programs on the server\nor otherwise gain unexpected levels of access. Or to be more accurate,\nthe known holes have been plugged. Because this feature is new and\nhas not received a comprehensive security audit, you should use whatever\nlevel of caution seems warranted given your attitude concerning\nsecurity.\n\nThere are two ways to specify read-only access for a user: by\ninclusion, and by exclusion.\n\n\"Inclusion\" means listing that user specifically in the\n'$CVSROOT/CVSROOT/readers' file, which is simply a newline-separated\nlist of users. Here is a sample 'readers' file:\n\nmelissa\nsplotnik\njrandom\n\n(Don't forget the newline after the last user.)\n\n\"Exclusion\" means explicitly listing everyone who has write\naccess--if the file\n\n$CVSROOT/CVSROOT/writers\n\nexists, then only those users listed in it have write access, and\neveryone else has read-only access (of course, even the read-only users\nstill need to be listed in the CVS 'passwd' file). The 'writers' file\nhas the same format as the 'readers' file.\n\nNote: if your CVS 'passwd' file maps cvs users onto system users\n(*note Password authentication server::), make sure you deny or grant\nread-only access using the cvs usernames, not the system usernames.", "subsections": [] }, "That is, the 'readers' and 'writers' files contain cvs usernames, which": { "content": "may or may not be the same as system usernames.\n\nHere is a complete description of the server's behavior in deciding\nwhether to grant read-only or read-write access:\n\nIf 'readers' exists, and this user is listed in it, then she gets\nread-only access. Or if 'writers' exists, and this user is NOT listed\nin it, then she also gets read-only access (this is true even if\n'readers' exists but she is not listed there). Otherwise, she gets full\nread-write access.\n\nOf course there is a conflict if the user is listed in both files.", "subsections": [] }, "This is resolved in the more conservative way, it being better to": { "content": "protect the repository too much than too little: such a user gets\nread-only access.\n", "subsections": [] }, "File: cvs.info, Node: Server temporary directory, Prev: Read-only access, Up: Repository": { "content": "", "subsections": [ { "name": "2.11 Temporary directories for the server", "content": "" } ] }, "While running, the CVS server creates temporary directories. They are": { "content": "named\n\ncvs-servPID\n\nwhere PID is the process identification number of the server. They are\nlocated in the directory specified by the '-T' global option (*note\nGlobal options::), the 'TMPDIR' environment variable (*note Environment\nvariables::), or, failing that, '/tmp'.\n\nIn most cases the server will remove the temporary directory when it\nis done, whether it finishes normally or abnormally. However, there are\na few cases in which the server does not or cannot remove the temporary\ndirectory, for example:\n\n* If the server aborts due to an internal server error, it may\npreserve the directory to aid in debugging\n\n* If the server is killed in a way that it has no way of cleaning up\n(most notably, 'kill -KILL' on unix).\n\n* If the system shuts down without an orderly shutdown, which tells\nthe server to clean up.\n\nIn cases such as this, you will need to manually remove the\n'cvs-servPID' directories. As long as there is no server running with\nprocess identification number PID, it is safe to do so.\n", "subsections": [] }, "File: cvs.info, Node: Starting a new project, Next: Revisions, Prev: Repository, Up: Top": { "content": "", "subsections": [] }, "3 Starting a project with CVS": { "content": "", "subsections": [] }, "Because renaming files and moving them between directories is somewhat": { "content": "inconvenient, the first thing you do when you start a new project should\nbe to think through your file organization. It is not impossible to\nrename or move files, but it does increase the potential for confusion\nand CVS does have some quirks particularly in the area of renaming\ndirectories. *Note Moving files::.\n\nWhat to do next depends on the situation at hand.\n\n* Menu:\n\n* Setting up the files:: Getting the files into the repository\n* Defining the module:: How to make a module of the files\n", "subsections": [] }, "File: cvs.info, Node: Setting up the files, Next: Defining the module, Up: Starting a new project": { "content": "", "subsections": [ { "name": "3.1 Setting up the files", "content": "" } ] }, "The first step is to create the files inside the repository. This can": { "content": "be done in a couple of different ways.\n\n* Menu:\n\n* From files:: This method is useful with old projects\nwhere files already exists.\n* From other version control systems:: Old projects where you want to\npreserve history from another system.\n* From scratch:: Creating a directory tree from scratch.\n", "subsections": [] }, "File: cvs.info, Node: From files, Next: From other version control systems, Up: Setting up the files": { "content": "", "subsections": [] }, "When you begin using CVS, you will probably already have several": { "content": "projects that can be put under CVS control. In these cases the easiest\nway is to use the 'import' command. An example is probably the easiest\nway to explain how to use it. If the files you want to install in CVS\nreside in 'WDIR', and you want them to appear in the repository as\n'$CVSROOT/yoyodyne/RDIR', you can do this:\n\n$ cd WDIR\n$ cvs import -m \"Imported sources\" yoyodyne/RDIR yoyo start\n\nUnless you supply a log message with the '-m' flag, CVS starts an\neditor and prompts for a message. The string 'yoyo' is a \"vendor tag\",\nand 'start' is a \"release tag\". They may fill no purpose in this\ncontext, but since CVS requires them they must be present. *Note\nTracking sources::, for more information about them.\n\nYou can now verify that it worked, and remove your original source\ndirectory.\n\n$ cd ..\n$ cvs checkout yoyodyne/RDIR # Explanation below\n$ diff -r WDIR yoyodyne/RDIR\n$ rm -r WDIR\n", "subsections": [] }, "Erasing the original sources is a good idea, to make sure that you do": { "content": "not accidentally edit them in WDIR, bypassing CVS. Of course, it would\nbe wise to make sure that you have a backup of the sources before you\nremove them.\n\nThe 'checkout' command can either take a module name as argument (as\nit has done in all previous examples) or a path name relative to\n'$CVSROOT', as it did in the example above.\n\nIt is a good idea to check that the permissions CVS sets on the\ndirectories inside '$CVSROOT' are reasonable, and that they belong to\nthe proper groups. *Note File permissions::.\n\nIf some of the files you want to import are binary, you may want to\nuse the wrappers features to specify which files are binary and which\nare not. *Note Wrappers::.\n", "subsections": [] }, "File: cvs.info, Node: From other version control systems, Next: From scratch, Prev: From files, Up: Setting up the files": { "content": "", "subsections": [] }, "If you have a project which you are maintaining with another version": { "content": "control system, such as RCS, you may wish to put the files from that\nproject into CVS, and preserve the revision history of the files.\n\nFrom RCS\nIf you have been using RCS, find the RCS files--usually a file\nnamed 'foo.c' will have its RCS file in 'RCS/foo.c,v' (but it could\nbe other places; consult the RCS documentation for details). Then\ncreate the appropriate directories in CVS if they do not already\nexist. Then copy the files into the appropriate directories in the\nCVS repository (the name in the repository must be the name of the\nsource file with ',v' added; the files go directly in the\nappropriate directory of the repository, not in an 'RCS'\nsubdirectory). This is one of the few times when it is a good idea\nto access the CVS repository directly, rather than using CVS\ncommands. Then you are ready to check out a new working directory.\n\nThe RCS file should not be locked when you move it into CVS; if it\nis, CVS will have trouble letting you operate on it.\n", "subsections": [] }, "From another version control system": { "content": "Many version control systems have the ability to export RCS files\nin the standard format. If yours does, export the RCS files and\nthen follow the above instructions.\n\nFailing that, probably your best bet is to write a script that will\ncheck out the files one revision at a time using the command line\ninterface to the other system, and then check the revisions into\nCVS. The 'sccs2rcs' script mentioned below may be a useful example\nto follow.\n\nFrom SCCS\nThere is a script in the 'contrib' directory of the CVS source\ndistribution called 'sccs2rcs' which converts SCCS files to RCS\nfiles. Note: you must run it on a machine which has both SCCS and\nRCS installed, and like everything else in contrib it is\nunsupported (your mileage may vary).\n\nFrom PVCS\nThere is a script in the 'contrib' directory of the CVS source\ndistribution called 'pvcstorcs' which converts PVCS archives to\nRCS files. You must run it on a machine which has both PVCS and\nRCS installed, and like everything else in contrib it is\nunsupported (your mileage may vary). See the comments in the\nscript for details.\n", "subsections": [] }, "File: cvs.info, Node: From scratch, Prev: From other version control systems, Up: Setting up the files": { "content": "", "subsections": [] }, "For a new project, the easiest thing to do is probably to create an": { "content": "empty directory structure, like this:\n\n$ mkdir tc\n$ mkdir tc/man\n$ mkdir tc/testing\n\nAfter that, you use the 'import' command to create the corresponding\n(empty) directory structure inside the repository:\n\n$ cd tc\n$ cvs import -m \"Created directory structure\" yoyodyne/DIR yoyo start\n\nThis will add yoyodyne/DIR as a directory under '$CVSROOT'.\n\nUse 'checkout' to get the new project. Then, use 'add' to add files\n(and new directories) as needed.\n\n$ cd ..\n$ cvs co yoyodyne/DIR\n\nCheck that the permissions CVS sets on the directories inside\n'$CVSROOT' are reasonable.\n", "subsections": [] }, "File: cvs.info, Node: Defining the module, Prev: Setting up the files, Up: Starting a new project": { "content": "", "subsections": [ { "name": "3.2 Defining the module", "content": "" } ] }, "The next step is to define the module in the 'modules' file. This is": { "content": "not strictly necessary, but modules can be convenient in grouping\ntogether related files and directories.\n\nIn simple cases these steps are sufficient to define a module.\n\n1. Get a working copy of the modules file.\n\n$ cvs checkout CVSROOT/modules\n$ cd CVSROOT\n\n2. Edit the file and insert a line that defines the module. *Note\nIntro administrative files::, for an introduction. *Note\nmodules::, for a full description of the modules file. You can use\nthe following line to define the module 'tc':\n\ntc yoyodyne/tc\n\n3. Commit your changes to the modules file.\n\n$ cvs commit -m \"Added the tc module.\" modules\n\n4. Release the modules module.\n\n$ cd ..\n$ cvs release -d CVSROOT\n", "subsections": [] }, "File: cvs.info, Node: Revisions, Next: Branching and merging, Prev: Starting a new project, Up: Top": { "content": "", "subsections": [] }, "4 Revisions": { "content": "", "subsections": [] }, "For many uses of CVS, one doesn't need to worry too much about revision": { "content": "numbers; CVS assigns numbers such as '1.1', '1.2', and so on, and that\nis all one needs to know. However, some people prefer to have more\nknowledge and control concerning how CVS assigns revision numbers.\n\nIf one wants to keep track of a set of revisions involving more than\none file, such as which revisions went into a particular release, one\nuses a \"tag\", which is a symbolic revision which can be assigned to a\nnumeric revision in each file.\n\n* Menu:\n\n* Revision numbers:: The meaning of a revision number\n* Versions revisions releases:: Terminology used in this manual\n* Assigning revisions:: Assigning revisions\n* Tags:: Tags-Symbolic revisions\n* Tagging the working directory:: The cvs tag command\n* Tagging by date/tag:: The cvs rtag command\n* Modifying tags:: Adding, renaming, and deleting tags\n* Tagging add/remove:: Tags with adding and removing files\n* Sticky tags:: Certain tags are persistent\n", "subsections": [] }, "File: cvs.info, Node: Revision numbers, Next: Versions revisions releases, Up: Revisions": { "content": "", "subsections": [ { "name": "4.1 Revision numbers", "content": "Each version of a file has a unique \"revision number\". Revision numbers\nlook like '1.1', '1.2', '1.3.2.2' or even '1.3.2.2.4.5'. A revision\nnumber always has an even number of period-separated decimal integers." } ] }, "By default revision 1.1 is the first revision of a file. Each": { "content": "successive revision is given a new number by increasing the rightmost\nnumber by one. The following figure displays a few revisions, with\nnewer revisions to the right.\n\n+-----+ +-----+ +-----+ +-----+ +-----+\n! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !\n+-----+ +-----+ +-----+ +-----+ +-----+\n\nIt is also possible to end up with numbers containing more than one\nperiod, for example '1.3.2.2'. Such revisions represent revisions on\nbranches (*note Branching and merging::); such revision numbers are\nexplained in detail in *note Branches and revisions::.\n", "subsections": [] }, "File: cvs.info, Node: Versions revisions releases, Next: Assigning revisions, Prev: Revision numbers, Up: Revisions": { "content": "", "subsections": [ { "name": "4.2 Versions, revisions and releases", "content": "A file can have several versions, as described above. Likewise, a\nsoftware product can have several versions. A software product is often\ngiven a version number such as '4.1.1'.\n\nVersions in the first sense are called \"revisions\" in this document,\nand versions in the second sense are called \"releases\". To avoid\nconfusion, the word \"version\" is almost never used in this document.\n" } ] }, "File: cvs.info, Node: Assigning revisions, Next: Tags, Prev: Versions revisions releases, Up: Revisions": { "content": "", "subsections": [ { "name": "4.3 Assigning revisions", "content": "" } ] }, "By default, CVS will assign numeric revisions by leaving the first": { "content": "number the same and incrementing the second number. For example, '1.1',\n'1.2', '1.3', etc.\n\nWhen adding a new file, the second number will always be one and the\nfirst number will equal the highest first number of any file in that\ndirectory. For example, the current directory contains files whose\nhighest numbered revisions are '1.7', '3.1', and '4.12', then an added\nfile will be given the numeric revision '4.1'. (When using\nclient/server CVS, only files that are actually sent to the server are\nconsidered.)\n\nNormally there is no reason to care about the revision numbers--it is\neasier to treat them as internal numbers that CVS maintains, and tags\nprovide a better way to distinguish between things like release 1 versus\nrelease 2 of your product (*note Tags::). However, if you want to set\nthe numeric revisions, the '-r' option to 'cvs commit' can do that. The\n'-r' option implies the '-f' option, in the sense that it causes the\nfiles to be committed even if they are not modified.\n\nFor example, to bring all your files up to revision 3.0 (including\nthose that haven't changed), you might invoke:\n\n$ cvs commit -r 3.0\n\nNote that the number you specify with '-r' must be larger than any\nexisting revision number. That is, if revision 3.0 exists, you cannot\n'cvs commit -r 1.3'. If you want to maintain several releases in\nparallel, you need to use a branch (*note Branching and merging::).\n", "subsections": [] }, "File: cvs.info, Node: Tags, Next: Tagging the working directory, Prev: Assigning revisions, Up: Revisions": { "content": "", "subsections": [ { "name": "4.4 Tags-Symbolic revisions", "content": "" } ] }, "The revision numbers live a life of their own. They need not have": { "content": "anything at all to do with the release numbers of your software product.", "subsections": [] }, "Depending on how you use CVS the revision numbers might change several": { "content": "times between two releases. As an example, some of the source files\nthat make up RCS 5.6 have the following revision numbers:\n\nci.c 5.21\nco.c 5.9\nident.c 5.3\nrcs.c 5.12\nrcsbase.h 5.11\nrcsdiff.c 5.10\nrcsedit.c 5.11\nrcsfcmp.c 5.9\nrcsgen.c 5.10\nrcslex.c 5.11\nrcsmap.c 5.2\nrcsutil.c 5.10\n\nYou can use the 'tag' command to give a symbolic name to a certain\nrevision of a file. You can use the '-v' flag to the 'status' command\nto see all tags that a file has, and which revision numbers they\nrepresent. Tag names must start with an uppercase or lowercase letter\nand can contain uppercase and lowercase letters, digits, '-', and ''.", "subsections": [] }, "The two tag names 'BASE' and 'HEAD' are reserved for use by CVS. It is": { "content": "expected that future names which are special to CVS will be specially\nnamed, for example by starting with '.', rather than being named\nanalogously to 'BASE' and 'HEAD', to avoid conflicts with actual tag\nnames.\n\nYou'll want to choose some convention for naming tags, based on\ninformation such as the name of the program and the version number of\nthe release. For example, one might take the name of the program,\nimmediately followed by the version number with '.' changed to '-', so\nthat CVS 1.9 would be tagged with the name 'cvs1-9'. If you choose a\nconsistent convention, then you won't constantly be guessing whether a\ntag is 'cvs-1-9' or 'cvs19' or what. You might even want to consider\nenforcing your convention in the 'taginfo' file (*note taginfo::).\n\nThe following example shows how you can add a tag to a file. The\ncommands must be issued inside your working directory. That is, you\nshould issue the command in the directory where 'backend.c' resides.\n\n$ cvs tag rel-0-4 backend.c\nT backend.c", "subsections": [ { "name": "$ cvs status -v backend.c", "content": "File: backend.c Status: Up-to-date\n\nVersion: 1.4 Tue Dec 1 14:39:01 1992\nRCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v\nSticky Tag: (none)\nSticky Date: (none)\nSticky Options: (none)\n\nExisting Tags:\nrel-0-4 (revision: 1.4)\n\n\nFor a complete summary of the syntax of 'cvs tag', including the\nvarious options, see *note Invoking CVS::.\n\nThere is seldom reason to tag a file in isolation. A more common use\nis to tag all the files that constitute a module with the same tag at\nstrategic points in the development life-cycle, such as when a release\nis made.\n\n$ cvs tag rel-1-0 .\ncvs tag: Tagging .\nT Makefile\nT backend.c\nT driver.c\nT frontend.c\nT parser.c\n\n(When you give CVS a directory as argument, it generally applies the\noperation to all the files in that directory, and (recursively), to any\nsubdirectories that it may contain. *Note Recursive behavior::.)\n\nThe 'checkout' command has a flag, '-r', that lets you check out a\ncertain revision of a module. This flag makes it easy to retrieve the\nsources that make up release 1.0 of the module 'tc' at any time in the\nfuture:\n\n$ cvs checkout -r rel-1-0 tc\n" } ] }, "This is useful, for instance, if someone claims that there is a bug in": { "content": "that release, but you cannot find the bug in the current working copy.\n\nYou can also check out a module as it was on any branch at any given\ndate. *Note checkout options::. When specifying '-r' or '-D' to any of\nthese commands, you will need beware of sticky tags; see *note Sticky\ntags::.\n\nWhen you tag more than one file with the same tag you can think about\nthe tag as \"a curve drawn through a matrix of filename vs. revision\nnumber.\" Say we have 5 files with the following revisions:\n\nfile1 file2 file3 file4 file5\n\n1.1 1.1 1.1 1.1 /--1.1* <-*- TAG\n1.2*- 1.2 1.2 -1.2*-\n1.3 \\- 1.3*- 1.3 / 1.3\n1.4 \\ 1.4 / 1.4\n\\-1.5*- 1.5\n1.6\n\nAt some time in the past, the '*' versions were tagged. You can\nthink of the tag as a handle attached to the curve drawn through the\ntagged revisions. When you pull on the handle, you get all the tagged\nrevisions. Another way to look at it is that you \"sight\" through a set\nof revisions that is \"flat\" along the tagged revisions, like this:\n\nfile1 file2 file3 file4 file5\n\n1.1\n1.2\n1.1 1.3\n1.1 1.2 1.4 1.1 /\n1.2*----1.3*----1.5*----1.2*----1.1* (--- <--- Look here\n1.3 1.6 1.3 \\\n1.4 1.4\n1.5\n", "subsections": [] }, "File: cvs.info, Node: Tagging the working directory, Next: Tagging by date/tag, Prev: Tags, Up: Revisions": { "content": "", "subsections": [ { "name": "4.5 Specifying what to tag from the working directory", "content": "" } ] }, "The example in the previous section demonstrates one of the most common": { "content": "ways to choose which revisions to tag. Namely, running the 'cvs tag'\ncommand without arguments causes CVS to select the revisions which are\nchecked out in the current working directory. For example, if the copy\nof 'backend.c' in working directory was checked out from revision 1.4,\nthen CVS will tag revision 1.4. Note that the tag is applied\nimmediately to revision 1.4 in the repository; tagging is not like\nmodifying a file, or other operations in which one first modifies the\nworking directory and then runs 'cvs commit' to transfer that\nmodification to the repository.\n\nOne potentially surprising aspect of the fact that 'cvs tag' operates\non the repository is that you are tagging the checked-in revisions,\nwhich may differ from locally modified files in your working directory.", "subsections": [] }, "If you want to avoid doing this by mistake, specify the '-c' option to": { "content": "'cvs tag'. If there are any locally modified files, CVS will abort with\nan error before it tags any files:\n\n$ cvs tag -c rel-0-4\ncvs tag: backend.c is locally modified\ncvs [tag aborted]: correct the above errors first!\n", "subsections": [] }, "File: cvs.info, Node: Tagging by date/tag, Next: Modifying tags, Prev: Tagging the working directory, Up: Revisions": { "content": "", "subsections": [ { "name": "4.6 Specifying what to tag by date or revision", "content": "" } ] }, "The 'cvs rtag' command tags the repository as of a certain date or time": { "content": "(or can be used to tag the latest revision). 'rtag' works directly on\nthe repository contents (it requires no prior checkout and does not look\nfor a working directory).\n\nThe following options specify which date or revision to tag. See\n*note Common options::, for a complete description of them.\n\n'-D DATE'\nTag the most recent revision no later than DATE.\n\n'-f'\nOnly useful with the '-D' or '-r' flags. If no matching revision\nis found, use the most recent revision (instead of ignoring the\nfile).\n\n'-r TAG[:DATE]'\nTag the revision already tagged with TAG or, when DATE is specified\nand TAG is a branch tag, the version from the branch TAG as it\nexisted on DATE. See *note Common options::.\n\nThe 'cvs tag' command also allows one to specify files by revision or\ndate, using the same '-r', '-D', and '-f' options. However, this\nfeature is probably not what you want. The reason is that 'cvs tag'\nchooses which files to tag based on the files that exist in the working\ndirectory, rather than the files which existed as of the given tag/date.", "subsections": [] }, "Therefore, you are generally better off using 'cvs rtag'. The": { "content": "exceptions might be cases like:\n\ncvs tag -r 1.4 stable backend.c\n", "subsections": [] }, "File: cvs.info, Node: Modifying tags, Next: Tagging add/remove, Prev: Tagging by date/tag, Up: Revisions": { "content": "", "subsections": [ { "name": "4.7 Deleting, moving, and renaming tags", "content": "" } ] }, "Normally one does not modify tags. They exist in order to record the": { "content": "history of the repository and so deleting them or changing their meaning\nwould, generally, not be what you want.\n\nHowever, there might be cases in which one uses a tag temporarily or\naccidentally puts one in the wrong place. Therefore, one might delete,\nmove, or rename a tag.\n\nWARNING: the commands in this section are dangerous; they permanently\ndiscard historical information and it can be difficult or impossible to\nrecover from errors. If you are a CVS administrator, you may consider\nrestricting these commands with the 'taginfo' file (*note taginfo::).\n\nTo delete a tag, specify the '-d' option to either 'cvs tag' or 'cvs\nrtag'. For example:\n\ncvs rtag -d rel-0-4 tc\n\ndeletes the non-branch tag 'rel-0-4' from the module 'tc'. In the event\nthat branch tags are encountered within the repository with the given\nname, a warning message will be issued and the branch tag will not be\ndeleted. If you are absolutely certain you know what you are doing, the\n'-B' option may be specified to allow deletion of branch tags. In that\ncase, any non-branch tags encountered will trigger warnings and will not\nbe deleted.\n\nWARNING: Moving branch tags is very dangerous! If you think you need\nthe '-B' option, think again and ask your CVS administrator about it (if\nthat isn't you). There is almost certainly another way to accomplish\nwhat you want to accomplish.\n\nWhen we say \"move\" a tag, we mean to make the same name point to\ndifferent revisions. For example, the 'stable' tag may currently point\nto revision 1.4 of 'backend.c' and perhaps we want to make it point to\nrevision 1.6. To move a non-branch tag, specify the '-F' option to\neither 'cvs tag' or 'cvs rtag'. For example, the task just mentioned\nmight be accomplished as:\n\ncvs tag -r 1.6 -F stable backend.c\n", "subsections": [] }, "If any branch tags are encountered in the repository with the given": { "content": "name, a warning is issued and the branch tag is not disturbed. If you\nare absolutely certain you wish to move the branch tag, the '-B' option\nmay be specified. In that case, non-branch tags encountered with the\ngiven name are ignored with a warning message.\n\nWARNING: Moving branch tags is very dangerous! If you think you need\nthe '-B' option, think again and ask your CVS administrator about it (if\nthat isn't you). There is almost certainly another way to accomplish\nwhat you want to accomplish.\n\nWhen we say \"rename\" a tag, we mean to make a different name point to\nthe same revisions as the old tag. For example, one may have misspelled\nthe tag name and want to correct it (hopefully before others are relying\non the old spelling). To rename a tag, first create a new tag using the\n'-r' option to 'cvs rtag', and then delete the old name. (Caution: this\nmethod will not work with branch tags.) This leaves the new tag on\nexactly the same files as the old tag. For example:\n\ncvs rtag -r old-name-0-4 rel-0-4 tc\ncvs rtag -d old-name-0-4 tc\n", "subsections": [] }, "File: cvs.info, Node: Tagging add/remove, Next: Sticky tags, Prev: Modifying tags, Up: Revisions": { "content": "", "subsections": [ { "name": "4.8 Tagging and adding and removing files", "content": "" } ] }, "The subject of exactly how tagging interacts with adding and removing": { "content": "files is somewhat obscure; for the most part CVS will keep track of\nwhether files exist or not without too much fussing. By default, tags\nare applied to only files which have a revision corresponding to what is\nbeing tagged. Files which did not exist yet, or which were already\nremoved, simply omit the tag, and CVS knows to treat the absence of a\ntag as meaning that the file didn't exist as of that tag.\n\nHowever, this can lose a small amount of information. For example,\nsuppose a file was added and then removed. Then, if the tag is missing\nfor that file, there is no way to know whether the tag refers to the\ntime before the file was added, or the time after it was removed. If\nyou specify the '-r' option to 'cvs rtag', then CVS tags the files which\nhave been removed, and thereby avoids this problem. For example, one\nmight specify '-r HEAD' to tag the head.\n\nOn the subject of adding and removing files, the 'cvs rtag' command\nhas a '-a' option which means to clear the tag from removed files that\nwould not otherwise be tagged. For example, one might specify this\noption in conjunction with '-F' when moving a tag. If one moved a tag\nwithout '-a', then the tag in the removed files might still refer to the\nold revision, rather than reflecting the fact that the file had been\nremoved. I don't think this is necessary if '-r' is specified, as noted\nabove.\n", "subsections": [] }, "File: cvs.info, Node: Sticky tags, Prev: Tagging add/remove, Up: Revisions": { "content": "", "subsections": [ { "name": "4.9 Sticky tags", "content": "" } ] }, "Sometimes a working copy's revision has extra data associated with it,": { "content": "for example it might be on a branch (*note Branching and merging::), or\nrestricted to versions prior to a certain date by 'checkout -D' or\n'update -D'. Because this data persists - that is, it applies to\nsubsequent commands in the working copy - we refer to it as \"sticky\".\n\nMost of the time, stickiness is an obscure aspect of CVS that you\ndon't need to think about. However, even if you don't want to use the\nfeature, you may need to know something about sticky tags (for\nexample, how to avoid them!).\n\nYou can use the 'status' command to see if any sticky tags or dates\nare set:\n", "subsections": [ { "name": "$ cvs status driver.c", "content": "File: driver.c Status: Up-to-date\n\nVersion: 1.7.2.1 Sat Dec 5 19:35:03 1992\nRCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v\nSticky Tag: rel-1-0-patches (branch: 1.7.2)\nSticky Date: (none)\nSticky Options: (none)\n\n\nThe sticky tags will remain on your working files until you delete\nthem with 'cvs update -A'. The '-A' option merges local changes into\nthe version of the file from the head of the trunk, removing any sticky\ntags, dates, or options. See *note update:: for more on the operation\nof 'cvs update'.\n\nThe most common use of sticky tags is to identify which branch one is\nworking on, as described in *note Accessing branches::. However,\nnon-branch sticky tags have uses as well. For example, suppose that you\nwant to avoid updating your working directory, to isolate yourself from\npossibly destabilizing changes other people are making. You can, of\ncourse, just refrain from running 'cvs update'. But if you want to\navoid updating only a portion of a larger tree, then sticky tags can\nhelp. If you check out a certain revision (such as 1.4) it will become\nsticky. Subsequent 'cvs update' commands will not retrieve the latest\nrevision until you reset the tag with 'cvs update -A'. Likewise, use of\nthe '-D' option to 'update' or 'checkout' sets a \"sticky date\", which,\nsimilarly, causes that date to be used for future retrievals.\n\nPeople often want to retrieve an old version of a file without\nsetting a sticky tag. This can be done with the '-p' option to\n'checkout' or 'update', which sends the contents of the file to standard\noutput. For example:" }, { "name": "$ cvs update -p -r 1.1 file1 >file1", "content": "Checking out file1\nRCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v" } ] }, "VERS: 1.1": { "content": "$\n\nHowever, this isn't the easiest way, if you are asking how to undo a\nprevious checkin (in this example, put 'file1' back to the way it was as\nof revision 1.1). In that case you are better off using the '-j' option\nto 'update'; for further discussion see *note Merging two revisions::.\n", "subsections": [] }, "File: cvs.info, Node: Branching and merging, Next: Recursive behavior, Prev: Revisions, Up: Top": { "content": "", "subsections": [] }, "5 Branching and merging": { "content": "CVS allows you to isolate changes onto a separate line of development,\nknown as a \"branch\". When you change files on a branch, those changes\ndo not appear on the main trunk or other branches.\n\nLater you can move changes from one branch to another branch (or the\nmain trunk) by \"merging\". Merging involves first running 'cvs update\n-j', to merge the changes into the working directory. You can then\ncommit that revision, and thus effectively copy the changes onto another\nbranch.\n\n* Menu:\n\n* Branches motivation:: What branches are good for\n* Creating a branch:: Creating a branch\n* Accessing branches:: Checking out and updating branches\n* Branches and revisions:: Branches are reflected in revision numbers\n* Magic branch numbers:: Magic branch numbers\n* Merging a branch:: Merging an entire branch\n* Merging more than once:: Merging from a branch several times\n* Merging two revisions:: Merging differences between two revisions\n* Merging adds and removals:: What if files are added or removed?\n* Merging and keywords:: Avoiding conflicts due to keyword substitution\n", "subsections": [] }, "File: cvs.info, Node: Branches motivation, Next: Creating a branch, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.1 What branches are good for", "content": "" } ] }, "Suppose that release 1.0 of tc has been made. You are continuing to": { "content": "develop tc, planning to create release 1.1 in a couple of months. After\na while your customers start to complain about a fatal bug. You check\nout release 1.0 (*note Tags::) and find the bug (which turns out to have\na trivial fix). However, the current revision of the sources are in a\nstate of flux and are not expected to be stable for at least another\nmonth. There is no way to make a bug fix release based on the newest\nsources.\n\nThe thing to do in a situation like this is to create a \"branch\" on\nthe revision trees for all the files that make up release 1.0 of tc.", "subsections": [] }, "You can then make modifications to the branch without disturbing the": { "content": "main trunk. When the modifications are finished you can elect to either\nincorporate them on the main trunk, or leave them on the branch.\n", "subsections": [] }, "File: cvs.info, Node: Creating a branch, Next: Accessing branches, Prev: Branches motivation, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.2 Creating a branch", "content": "" } ] }, "You can create a branch with 'tag -b'; for example, assuming you're in a": { "content": "working copy:\n\n$ cvs tag -b rel-1-0-patches\n\nThis splits off a branch based on the current revisions in the\nworking copy, assigning that branch the name 'rel-1-0-patches'.\n\nIt is important to understand that branches get created in the\nrepository, not in the working copy. Creating a branch based on current\nrevisions, as the above example does, will not automatically switch\nthe working copy to be on the new branch. For information on how to do\nthat, see *note Accessing branches::.\n\nYou can also create a branch without reference to any working copy,\nby using 'rtag':\n\n$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc\n\n'-r rel-1-0' says that this branch should be rooted at the revision\nthat corresponds to the tag 'rel-1-0'. It need not be the most recent\nrevision - it's often useful to split a branch off an old revision (for\nexample, when fixing a bug in a past release otherwise known to be\nstable).\n\nAs with 'tag', the '-b' flag tells 'rtag' to create a branch (rather\nthan just a symbolic revision name). Note that the numeric revision\nnumber that matches 'rel-1-0' will probably be different from file to\nfile.\n\nSo, the full effect of the command is to create a new branch - named\n'rel-1-0-patches' - in module 'tc', rooted in the revision tree at the\npoint tagged by 'rel-1-0'.\n", "subsections": [] }, "File: cvs.info, Node: Accessing branches, Next: Branches and revisions, Prev: Creating a branch, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.3 Accessing branches", "content": "" } ] }, "You can retrieve a branch in one of two ways: by checking it out fresh": { "content": "from the repository, or by switching an existing working copy over to\nthe branch.\n\nTo check out a branch from the repository, invoke 'checkout' with the\n'-r' flag, followed by the tag name of the branch (*note Creating a\nbranch::):\n\n$ cvs checkout -r rel-1-0-patches tc\n\nOr, if you already have a working copy, you can switch it to a given\nbranch with 'update -r':\n\n$ cvs update -r rel-1-0-patches tc\n\nor equivalently:\n\n$ cd tc\n$ cvs update -r rel-1-0-patches\n\nIt does not matter if the working copy was originally on the main\ntrunk or on some other branch - the above command will switch it to the\nnamed branch. And similarly to a regular 'update' command, 'update -r'\nmerges any changes you have made, notifying you of conflicts where they\noccur.\n\nOnce you have a working copy tied to a particular branch, it remains\nthere until you tell it otherwise. This means that changes checked in\nfrom the working copy will add new revisions on that branch, while\nleaving the main trunk and other branches unaffected.\n\nTo find out what branch a working copy is on, you can use the\n'status' command. In its output, look for the field named 'Sticky tag'\n(*note Sticky tags::) - that's CVS's way of telling you the branch, if\nany, of the current working files:\n", "subsections": [ { "name": "$ cvs status -v driver.c backend.c", "content": "File: driver.c Status: Up-to-date\n\nVersion: 1.7 Sat Dec 5 18:25:54 1992\nRCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c,v\nSticky Tag: rel-1-0-patches (branch: 1.7.2)\nSticky Date: (none)\nSticky Options: (none)\n\nExisting Tags:\nrel-1-0-patches (branch: 1.7.2)\nrel-1-0 (revision: 1.7)\n\n===================================================================\nFile: backend.c Status: Up-to-date\n\nVersion: 1.4 Tue Dec 1 14:39:01 1992\nRCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v\nSticky Tag: rel-1-0-patches (branch: 1.4.2)\nSticky Date: (none)\nSticky Options: (none)\n\nExisting Tags:\nrel-1-0-patches (branch: 1.4.2)\nrel-1-0 (revision: 1.4)\nrel-0-4 (revision: 1.4)\n\n\nDon't be confused by the fact that the branch numbers for each file\nare different ('1.7.2' and '1.4.2' respectively). The branch tag is the\nsame, 'rel-1-0-patches', and the files are indeed on the same branch." } ] }, "The numbers simply reflect the point in each file's revision history at": { "content": "which the branch was made. In the above example, one can deduce that\n'driver.c' had been through more changes than 'backend.c' before this\nbranch was created.\n\nSee *note Branches and revisions:: for details about how branch\nnumbers are constructed.\n", "subsections": [] }, "File: cvs.info, Node: Branches and revisions, Next: Magic branch numbers, Prev: Accessing branches, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.4 Branches and revisions", "content": "" } ] }, "Ordinarily, a file's revision history is a linear series of increments": { "content": "(*note Revision numbers::):\n\n+-----+ +-----+ +-----+ +-----+ +-----+\n! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !\n+-----+ +-----+ +-----+ +-----+ +-----+\n\nHowever, CVS is not limited to linear development. The \"revision\ntree\" can be split into \"branches\", where each branch is a\nself-maintained line of development. Changes made on one branch can\neasily be moved back to the main trunk.\n\nEach branch has a \"branch number\", consisting of an odd number of\nperiod-separated decimal integers. The branch number is created by\nappending an integer to the revision number where the corresponding\nbranch forked off. Having branch numbers allows more than one branch to\nbe forked off from a certain revision.\n\nAll revisions on a branch have revision numbers formed by appending\nan ordinal number to the branch number. The following figure\nillustrates branching with an example.\n\n+-------------+\nBranch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !\n/ +-------------+\n/\n/\n+---------+ +---------+ +---------+\nBranch 1.2.2 -> ! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !\n/ +---------+ +---------+ +---------+\n/\n/\n+-----+ +-----+ +-----+ +-----+ +-----+\n! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk\n+-----+ +-----+ +-----+ +-----+ +-----+\n!\n!\n! +---------+ +---------+ +---------+\nBranch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !\n+---------+ +---------+ +---------+\n\n\nThe exact details of how the branch number is constructed is not\nsomething you normally need to be concerned about, but here is how it\nworks: When CVS creates a branch number it picks the first unused even\ninteger, starting with 2. So when you want to create a branch from\nrevision 6.4 it will be numbered 6.4.2. All branch numbers ending in a\nzero (such as 6.4.0) are used internally by CVS (*note Magic branch\nnumbers::). The branch 1.1.1 has a special meaning. *Note Tracking\nsources::.\n", "subsections": [] }, "File: cvs.info, Node: Magic branch numbers, Next: Merging a branch, Prev: Branches and revisions, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.5 Magic branch numbers", "content": "This section describes a CVS feature called \"magic branches\". For most\npurposes, you need not worry about magic branches; CVS handles them for\nyou. However, they are visible to you in certain circumstances, so it\nmay be useful to have some idea of how it works.\n\nExternally, branch numbers consist of an odd number of dot-separated\ndecimal integers. *Note Revision numbers::. That is not the whole\ntruth, however. For efficiency reasons CVS sometimes inserts an extra 0\nin the second rightmost position (1.2.4 becomes 1.2.0.4, 8.9.10.11.12\nbecomes 8.9.10.11.0.12 and so on).\n\nCVS does a pretty good job at hiding these so called magic branches,\nbut in a few places the hiding is incomplete:\n\n* The magic branch number appears in the output from 'cvs log'.\n\n* You cannot specify a symbolic branch name to 'cvs admin'.\n\nYou can use the 'admin' command to reassign a symbolic name to a\nbranch the way RCS expects it to be. If 'R4patches' is assigned to the\nbranch 1.4.2 (magic branch number 1.4.0.2) in file 'numbers.c' you can\ndo this:\n\n$ cvs admin -NR4patches:1.4.2 numbers.c\n\nIt only works if at least one revision is already committed on the\nbranch. Be very careful so that you do not assign the tag to the wrong\nnumber. (There is no way to see how the tag was assigned yesterday).\n" } ] }, "File: cvs.info, Node: Merging a branch, Next: Merging more than once, Prev: Magic branch numbers, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.6 Merging an entire branch", "content": "" } ] }, "You can merge changes made on a branch into your working copy by giving": { "content": "the '-j BRANCHNAME' flag to the 'update' subcommand. With one '-j\nBRANCHNAME' option it merges the changes made between the greatest\ncommon ancestor (GCA) of the branch and the destination revision (in the\nsimple case below the GCA is the point where the branch forked) and the\nnewest revision on that branch into your working copy.\n\nThe '-j' stands for \"join\".\n\nConsider this revision tree:\n\n+-----+ +-----+ +-----+ +-----+\n! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk\n+-----+ +-----+ +-----+ +-----+\n!\n!\n! +---------+ +---------+\nBranch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !\n+---------+ +---------+\n", "subsections": [] }, "The branch 1.2.2 has been given the tag (symbolic name) 'R1fix'. The": { "content": "following example assumes that the module 'mod' contains only one file,\n'm.c'.\n\n$ cvs checkout mod # Retrieve the latest revision, 1.4\n\n$ cvs update -j R1fix m.c # Merge all changes made on the branch,\n# i.e. the changes between revision 1.2\n# and 1.2.2.2, into your working copy\n# of the file.\n\n$ cvs commit -m \"Included R1fix\" # Create revision 1.5.\n\nA conflict can result from a merge operation. If that happens, you\nshould resolve it before committing the new revision. *Note Conflicts\nexample::.\n\nIf your source files contain keywords (*note Keyword substitution::),\nyou might be getting more conflicts than strictly necessary. See *note\nMerging and keywords::, for information on how to avoid this.\n\nThe 'checkout' command also supports the '-j BRANCHNAME' flag. The\nsame effect as above could be achieved with this:\n\n$ cvs checkout -j R1fix mod\n$ cvs commit -m \"Included R1fix\"\n\nIt should be noted that 'update -j TAGNAME' will also work but may\nnot produce the desired result. *Note Merging adds and removals::, for\nmore.\n", "subsections": [] }, "File: cvs.info, Node: Merging more than once, Next: Merging two revisions, Prev: Merging a branch, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.7 Merging from a branch several times", "content": "Continuing our example, the revision tree now looks like this:\n\n+-----+ +-----+ +-----+ +-----+ +-----+\n! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk\n+-----+ +-----+ +-----+ +-----+ +-----+\n! *\n! *\n! +---------+ +---------+\nBranch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !\n+---------+ +---------+\n\nwhere the starred line represents the merge from the 'R1fix' branch to\nthe main trunk, as just discussed.\n\nNow suppose that development continues on the 'R1fix' branch:\n\n+-----+ +-----+ +-----+ +-----+ +-----+\n! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk\n+-----+ +-----+ +-----+ +-----+ +-----+\n! *\n! *\n! +---------+ +---------+ +---------+\nBranch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !\n+---------+ +---------+ +---------+\n\nand then you want to merge those new changes onto the main trunk. If\nyou just use the 'cvs update -j R1fix m.c' command again, CVS will\nattempt to merge again the changes which you have already merged, which\ncan have undesirable side effects.\n\nSo instead you need to specify that you only want to merge the\nchanges on the branch which have not yet been merged into the trunk. To\ndo that you specify two '-j' options, and CVS merges the changes from\nthe first revision to the second revision. For example, in this case\nthe simplest way would be\n\ncvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the\n# head of the R1fix branch\n\nThe problem with this is that you need to specify the 1.2.2.2\nrevision manually. A slightly better approach might be to use the date\nthe last merge was done:\n\ncvs update -j R1fix:yesterday -j R1fix m.c\n\nBetter yet, tag the R1fix branch after every merge into the trunk,\nand then use that tag for subsequent merges:\n\ncvs update -j mergedfromR1fixtotrunk -j R1fix m.c\n" } ] }, "File: cvs.info, Node: Merging two revisions, Next: Merging adds and removals, Prev: Merging more than once, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.8 Merging differences between any two revisions", "content": "" } ] }, "With two '-j REVISION' flags, the 'update' (and 'checkout') command can": { "content": "merge the differences between any two revisions into your working file.\n\n$ cvs update -j 1.5 -j 1.3 backend.c\n\nwill undo all changes made between revision 1.3 and 1.5. Note the order\nof the revisions!\n\nIf you try to use this option when operating on multiple files,\nremember that the numeric revisions will probably be very different\nbetween the various files. You almost always use symbolic tags rather\nthan revision numbers when operating on multiple files.\n\nSpecifying two '-j' options can also undo file removals or additions.", "subsections": [] }, "For example, suppose you have a file named 'file1' which existed as": { "content": "revision 1.1, and you then removed it (thus adding a dead revision 1.2).", "subsections": [] }, "Now suppose you want to add it again, with the same contents it had": { "content": "previously. Here is how to do it:\n\n$ cvs update -j 1.2 -j 1.1 file1\nU file1\n$ cvs commit -m test\nChecking in file1;\n/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1\nnew revision: 1.3; previous revision: 1.2\ndone\n$\n", "subsections": [] }, "File: cvs.info, Node: Merging adds and removals, Next: Merging and keywords, Prev: Merging two revisions, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.9 Merging can add or remove files", "content": "" } ] }, "If the changes which you are merging involve removing or adding some": { "content": "files, 'update -j' will reflect such additions or removals.\n\nFor example:\ncvs update -A\ntouch a b c\ncvs add a b c ; cvs ci -m \"added\" a b c\ncvs tag -b branchtag\ncvs update -r branchtag\ntouch d ; cvs add d\nrm a ; cvs rm a\ncvs ci -m \"added d, removed a\"\ncvs update -A\ncvs update -jbranchtag\n\nAfter these commands are executed and a 'cvs commit' is done, file\n'a' will be removed and file 'd' added in the main branch.\n\nNote that using a single static tag ('-j TAGNAME') rather than a\ndynamic tag ('-j BRANCHNAME') to merge changes from a branch will\nusually not remove files which were removed on the branch since CVS does\nnot automatically add static tags to dead revisions. The exception to\nthis rule occurs when a static tag has been attached to a dead revision\nmanually. Use the branch tag to merge all changes from the branch or\nuse two static tags as merge endpoints to be sure that all intended\nchanges are propagated in the merge.\n", "subsections": [] }, "File: cvs.info, Node: Merging and keywords, Prev: Merging adds and removals, Up: Branching and merging": { "content": "", "subsections": [ { "name": "5.10 Merging and keywords", "content": "If you merge files containing keywords (*note Keyword substitution::),\nyou will normally get numerous conflicts during the merge, because the\nkeywords are expanded differently in the revisions which you are\nmerging.\n\nTherefore, you will often want to specify the '-kk' (*note" } ] }, "Substitution modes::) switch to the merge command line. By substituting": { "content": "just the name of the keyword, not the expanded value of that keyword,\nthis option ensures that the revisions which you are merging will be the\nsame as each other, and avoid spurious conflicts.\n\nFor example, suppose you have a file like this:\n\n+---------+\n! 1.1.2.1 ! <- br1\n/ +---------+\n/\n/\n+-----+ +-----+\n! 1.1 !----! 1.2 !\n+-----+ +-----+\n\nand your working directory is currently on the trunk (revision 1.2).\nThen you might get the following results from a merge:\n\n$ cat file1\nkey $Revision: 1.2 $\n. . .\n$ cvs update -j br1\nU file1\nRCS file: /cvsroot/first-dir/file1,v\nretrieving revision 1.1\nretrieving revision 1.1.2.1\nMerging differences between 1.1 and 1.1.2.1 into file1\nrcsmerge: warning: conflicts during merge\n$ cat file1\n<<<<<<< file1", "subsections": [ { "name": "key $Revision: 1.2 $", "content": "key $Revision: 1.1.2.1 $\n>>>>>>> 1.1.2.1\n. . .\n\nWhat happened was that the merge tried to merge the differences\nbetween 1.1 and 1.1.2.1 into your working directory. So, since the\nkeyword changed from 'Revision: 1.1' to 'Revision: 1.1.2.1', CVS tried\nto merge that change into your working directory, which conflicted with\nthe fact that your working directory had contained 'Revision: 1.2'.\n\nHere is what happens if you had used '-kk':\n\n$ cat file1\nkey $Revision: 1.2 $\n. . .\n$ cvs update -kk -j br1\nU file1\nRCS file: /cvsroot/first-dir/file1,v\nretrieving revision 1.1\nretrieving revision 1.1.2.1\nMerging differences between 1.1 and 1.1.2.1 into file1\n$ cat file1\nkey $Revision$\n. . .\n\nWhat is going on here is that revision 1.1 and 1.1.2.1 both expand as\nplain 'Revision', and therefore merging the changes between them into\nthe working directory need not change anything. Therefore, there is no\nconflict.\n\nWARNING: In versions of CVS prior to 1.12.2, there was a major\nproblem with using '-kk' on merges. Namely, '-kk' overrode any default\nkeyword expansion mode set in the archive file in the repository. This\ncould, unfortunately for some users, cause data corruption in binary\nfiles (with a default keyword expansion mode set to '-kb'). Therefore,\nwhen a repository contained binary files, conflicts had to be dealt with\nmanually rather than using '-kk' in a merge command.\n\nIn CVS version 1.12.2 and later, the keyword expansion mode provided\non the command line to any CVS command no longer overrides the '-kb'\nkeyword expansion mode setting for binary files, though it will still\noverride other default keyword expansion modes. You can now safely\nmerge using '-kk' to avoid spurious conflicts on lines containing RCS\nkeywords, even when your repository contains binary files.\n" } ] }, "File: cvs.info, Node: Recursive behavior, Next: Adding and removing, Prev: Branching and merging, Up: Top": { "content": "", "subsections": [] }, "6 Recursive behavior": { "content": "", "subsections": [] }, "Almost all of the subcommands of CVS work recursively when you specify a": { "content": "directory as an argument. For instance, consider this directory\nstructure:\n\n$HOME\n|\n+--tc\n| |\n+--CVS\n| (internal CVS files)\n+--Makefile\n+--backend.c\n+--driver.c\n+--frontend.c\n+--parser.c\n+--man\n| |\n| +--CVS\n| | (internal CVS files)\n| +--tc.1\n|\n+--testing\n|\n+--CVS\n| (internal CVS files)\n+--testpgm.t\n+--test2.t\n\nIf 'tc' is the current working directory, the following is true:\n\n* 'cvs update testing' is equivalent to\n\ncvs update testing/testpgm.t testing/test2.t\n\n* 'cvs update testing man' updates all files in the subdirectories\n\n* 'cvs update .' or just 'cvs update' updates all files in the 'tc'\ndirectory\n\nIf no arguments are given to 'update' it will update all files in the\ncurrent working directory and all its subdirectories. In other words,\n'.' is a default argument to 'update'. This is also true for most of\nthe CVS subcommands, not only the 'update' command.\n\nThe recursive behavior of the CVS subcommands can be turned off with\nthe '-l' option. Conversely, the '-R' option can be used to force\nrecursion if '-l' is specified in '~/.cvsrc' (*note ~/.cvsrc::).\n\n$ cvs update -l # Don't update files in subdirectories\n", "subsections": [] }, "File: cvs.info, Node: Adding and removing, Next: History browsing, Prev: Recursive behavior, Up: Top": { "content": "", "subsections": [] }, "7 Adding, removing, and renaming files and directories": { "content": "", "subsections": [] }, "In the course of a project, one will often add new files. Likewise with": { "content": "removing or renaming, or with directories. The general concept to keep\nin mind in all these cases is that instead of making an irreversible\nchange you want CVS to record the fact that a change has taken place,\njust as with modifying an existing file. The exact mechanisms to do\nthis in CVS vary depending on the situation.\n\n* Menu:\n\n* Adding files:: Adding files\n* Removing files:: Removing files\n* Removing directories:: Removing directories\n* Moving files:: Moving and renaming files\n* Moving directories:: Moving and renaming directories\n", "subsections": [] }, "File: cvs.info, Node: Adding files, Next: Removing files, Up: Adding and removing": { "content": "", "subsections": [ { "name": "7.1 Adding files to a directory", "content": "To add a new file to a directory, follow these steps.\n\n* You must have a working copy of the directory. *Note Getting the\nsource::.\n\n* Create the new file inside your working copy of the directory.\n\n* Use 'cvs add FILENAME' to tell CVS that you want to version control\nthe file. If the file contains binary data, specify '-kb' (*note\nBinary files::).\n\n* Use 'cvs commit FILENAME' to actually check in the file into the\nrepository. Other developers cannot see the file until you perform\nthis step.\n\nYou can also use the 'add' command to add a new directory.\n\nUnlike most other commands, the 'add' command is not recursive. You\nhave to expcicitly name files and directories that you wish to add to\nthe repository. However, each directory will need to be added\nseparately before you will be able to add new files to those\ndirectories.\n\n$ mkdir -p foo/bar\n$ cp ~/myfile foo/bar/myfile\n$ cvs add foo foo/bar\n$ cvs add foo/bar/myfile\n\n-- Command: cvs add [-k kflag] [-m message] files ...\n\nSchedule FILES to be added to the repository. The files or\ndirectories specified with 'add' must already exist in the current\ndirectory. To add a whole new directory hierarchy to the source\nrepository (for example, files received from a third-party vendor),\nuse the 'import' command instead. *Note import::.\n\nThe added files are not placed in the source repository until you\nuse 'commit' to make the change permanent. Doing an 'add' on a\nfile that was removed with the 'remove' command will undo the\neffect of the 'remove', unless a 'commit' command intervened.\n*Note Removing files::, for an example.\n\nThe '-k' option specifies the default way that this file will be\nchecked out; for more information see *note Substitution modes::.\n\nThe '-m' option specifies a description for the file. This\ndescription appears in the history log (if it is enabled, *note\nhistory file::). It will also be saved in the version history\ninside the repository when the file is committed. The 'log'\ncommand displays this description. The description can be changed\nusing 'admin -t'. *Note admin::. If you omit the '-m DESCRIPTION'\nflag, an empty string will be used. You will not be prompted for a\ndescription.\n\nFor example, the following commands add the file 'backend.c' to the\nrepository:\n\n$ cvs add backend.c\n$ cvs commit -m \"Early version. Not yet compilable.\" backend.c\n\nWhen you add a file it is added only on the branch which you are\nworking on (*note Branching and merging::). You can later merge the\nadditions to another branch if you want (*note Merging adds and\nremovals::).\n" } ] }, "File: cvs.info, Node: Removing files, Next: Removing directories, Prev: Adding files, Up: Adding and removing": { "content": "", "subsections": [ { "name": "7.2 Removing files", "content": "Directories change. New files are added, and old files disappear.\nStill, you want to be able to retrieve an exact copy of old releases.\n\nHere is what you can do to remove a file, but remain able to retrieve\nold revisions:\n\n* Make sure that you have not made any uncommitted modifications to\nthe file. *Note Viewing differences::, for one way to do that.\nYou can also use the 'status' or 'update' command. If you remove\nthe file without committing your changes, you will of course not be\nable to retrieve the file as it was immediately before you deleted\nit.\n\n* Remove the file from your working copy of the directory. You can\nfor instance use 'rm'.\n\n* Use 'cvs remove FILENAME' to tell CVS that you really want to\ndelete the file.\n\n* Use 'cvs commit FILENAME' to actually perform the removal of the\nfile from the repository.\n\nWhen you commit the removal of the file, CVS records the fact that\nthe file no longer exists. It is possible for a file to exist on only\nsome branches and not on others, or to re-add another file with the same\nname later. CVS will correctly create or not create the file, based on\nthe '-r' and '-D' options specified to 'checkout' or 'update'.\n\n-- Command: cvs remove [options] files ...\n\nSchedule file(s) to be removed from the repository (files which\nhave not already been removed from the working directory are not\nprocessed). This command does not actually remove the file from\nthe repository until you commit the removal. For a full list of\noptions, see *note Invoking CVS::.\n\nHere is an example of removing several files:\n\n$ cd test\n$ rm *.c\n$ cvs remove\ncvs remove: Removing .\ncvs remove: scheduling a.c for removal\ncvs remove: scheduling b.c for removal\ncvs remove: use 'cvs commit' to remove these files permanently\n$ cvs ci -m \"Removed unneeded files\"\ncvs commit: Examining .\ncvs commit: Committing .\n\nAs a convenience you can remove the file and 'cvs remove' it in one\nstep, by specifying the '-f' option. For example, the above example\ncould also be done like this:\n\n$ cd test\n$ cvs remove -f *.c\ncvs remove: scheduling a.c for removal\ncvs remove: scheduling b.c for removal\ncvs remove: use 'cvs commit' to remove these files permanently\n$ cvs ci -m \"Removed unneeded files\"\ncvs commit: Examining .\ncvs commit: Committing .\n\nIf you execute 'remove' for a file, and then change your mind before\nyou commit, you can undo the 'remove' with an 'add' command.\n\n$ ls\nCVS ja.h oj.c\n$ rm oj.c\n$ cvs remove oj.c\ncvs remove: scheduling oj.c for removal\ncvs remove: use 'cvs commit' to remove this file permanently\n$ cvs add oj.c\nU oj.c\ncvs add: oj.c, version 1.1.1.1, resurrected\n\nIf you realise your mistake before you run the 'remove' command you\ncan use 'update' to resurrect the file:\n\n$ rm oj.c\n$ cvs update oj.c\ncvs update: warning: oj.c was lost\nU oj.c\n\nWhen you remove a file it is removed only on the branch which you are\nworking on (*note Branching and merging::). You can later merge the\nremovals to another branch if you want (*note Merging adds and\nremovals::).\n" } ] }, "File: cvs.info, Node: Removing directories, Next: Moving files, Prev: Removing files, Up: Adding and removing": { "content": "", "subsections": [ { "name": "7.3 Removing directories", "content": "" } ] }, "In concept, removing directories is somewhat similar to removing": { "content": "files--you want the directory to not exist in your current working\ndirectories, but you also want to be able to retrieve old releases in\nwhich the directory existed.\n\nThe way that you remove a directory is to remove all the files in it.\nYou don't remove the directory itself; there is no way to do that.", "subsections": [] }, "Instead you specify the '-P' option to 'cvs update' or 'cvs checkout',": { "content": "which will cause CVS to remove empty directories from working\ndirectories. (Note that 'cvs export' always removes empty directories.)", "subsections": [] }, "Probably the best way to do this is to always specify '-P'; if you want": { "content": "an empty directory then put a dummy file (for example '.keepme') in it\nto prevent '-P' from removing it.\n\nNote that '-P' is implied by the '-r' or '-D' options of 'checkout'.", "subsections": [] }, "This way, CVS will be able to correctly create the directory or not": { "content": "depending on whether the particular version you are checking out\ncontains any files in that directory.\n", "subsections": [] }, "File: cvs.info, Node: Moving files, Next: Moving directories, Prev: Removing directories, Up: Adding and removing": { "content": "", "subsections": [ { "name": "7.4 Moving and renaming files", "content": "" } ] }, "Moving files to a different directory or renaming them is not difficult,": { "content": "but some of the ways in which this works may be non-obvious. (Moving or\nrenaming a directory is even harder. *Note Moving directories::.).\n\nThe examples below assume that the file OLD is renamed to NEW.\n\n* Menu:\n\n* Outside:: The normal way to Rename\n* Inside:: A tricky, alternative way\n* Rename by copying:: Another tricky, alternative way\n", "subsections": [] }, "File: cvs.info, Node: Outside, Next: Inside, Up: Moving files": { "content": "", "subsections": [] }, "The normal way to move a file is to copy OLD to NEW, and then issue the": { "content": "normal CVS commands to remove OLD from the repository, and add NEW to\nit.\n\n$ mv OLD NEW\n$ cvs remove OLD\n$ cvs add NEW\n$ cvs commit -m \"Renamed OLD to NEW\" OLD NEW\n\nThis is the simplest way to move a file, it is not error-prone, and\nit preserves the history of what was done. Note that to access the\nhistory of the file you must specify the old or the new name, depending\non what portion of the history you are accessing. For example, 'cvs log\nOLD' will give the log up until the time of the rename.\n\nWhen NEW is committed its revision numbers will start again, usually\nat 1.1, so if that bothers you, use the '-r TAG' option to commit. For\nmore information see *note Assigning revisions::.\n", "subsections": [] }, "File: cvs.info, Node: Inside, Next: Rename by copying, Prev: Outside, Up: Moving files": { "content": "", "subsections": [] }, "This method is more dangerous, since it involves moving files inside the": { "content": "repository. Read this entire section before trying it out!\n\n$ cd $CVSROOT/DIR\n$ mv OLD,v NEW,v\n\nAdvantages:\n\n* The log of changes is maintained intact.\n\n* The revision numbers are not affected.\n\nDisadvantages:\n\n* Old releases cannot easily be fetched from the repository. (The\nfile will show up as NEW even in revisions from the time before it\nwas renamed).\n\n* There is no log information of when the file was renamed.\n\n* Nasty things might happen if someone accesses the history file\nwhile you are moving it. Make sure no one else runs any of the CVS\ncommands while you move it.\n", "subsections": [] }, "File: cvs.info, Node: Rename by copying, Prev: Inside, Up: Moving files": { "content": "", "subsections": [] }, "This way also involves direct modifications to the repository. It is": { "content": "safe, but not without drawbacks.\n\n# Copy the RCS file inside the repository\n$ cd $CVSROOT/DIR\n$ cp OLD,v NEW,v\n# Remove the old file\n$ cd ~/DIR\n$ rm OLD\n$ cvs remove OLD\n$ cvs commit OLD\n# Remove all tags from NEW\n$ cvs update NEW\n$ cvs log NEW # Remember the non-branch tag names\n$ cvs tag -d TAG1 NEW\n$ cvs tag -d TAG2 NEW\n...\n\nBy removing the tags you will be able to check out old revisions.\n\nAdvantages:\n\n* Checking out old revisions works correctly, as long as you use '-r\nTAG' and not '-D DATE' to retrieve the revisions.\n\n* The log of changes is maintained intact.\n\n* The revision numbers are not affected.\n\nDisadvantages:\n\n* You cannot easily see the history of the file across the rename.\n", "subsections": [] }, "File: cvs.info, Node: Moving directories, Prev: Moving files, Up: Adding and removing": { "content": "", "subsections": [ { "name": "7.5 Moving and renaming directories", "content": "" } ] }, "The normal way to rename or move a directory is to rename or move each": { "content": "file within it as described in *note Outside::. Then check out with the\n'-P' option, as described in *note Removing directories::.\n\nIf you really want to hack the repository to rename or delete a\ndirectory in the repository, you can do it like this:\n\n1. Inform everyone who has a checked out copy of the directory that\nthe directory will be renamed. They should commit all their\nchanges in all their copies of the project containing the directory\nto be removed, and remove all their working copies of said project,\nbefore you take the steps below.\n\n2. Rename the directory inside the repository.\n\n$ cd $CVSROOT/PARENT-DIR\n$ mv OLD-DIR NEW-DIR\n\n3. Fix the CVS administrative files, if necessary (for instance if you\nrenamed an entire module).\n\n4. Tell everyone that they can check out again and continue working.\n\nIf someone had a working copy the CVS commands will cease to work for\nhim, until he removes the directory that disappeared inside the\nrepository.\n\nIt is almost always better to move the files in the directory instead\nof moving the directory. If you move the directory you are unlikely to\nbe able to retrieve old releases correctly, since they probably depend\non the name of the directories.\n", "subsections": [] }, "File: cvs.info, Node: History browsing, Next: Binary files, Prev: Adding and removing, Up: Top": { "content": "", "subsections": [] }, "8 History browsing": { "content": "", "subsections": [] }, "Once you have used CVS to store a version control history--what files": { "content": "have changed when, how, and by whom, there are a variety of mechanisms\nfor looking through the history.\n\n* Menu:\n\n* log messages:: Log messages\n* history database:: The history database\n* user-defined logging:: User-defined logging\n", "subsections": [] }, "File: cvs.info, Node: log messages, Next: history database, Up: History browsing": { "content": "", "subsections": [ { "name": "8.1 Log messages", "content": "Whenever you commit a file you specify a log message.\n\nTo look through the log messages which have been specified for every\nrevision which has been committed, use the 'cvs log' command (*note\nlog::).\n" } ] }, "File: cvs.info, Node: history database, Next: user-defined logging, Prev: log messages, Up: History browsing": { "content": "", "subsections": [ { "name": "8.2 The history database", "content": "You can use the history file (*note history file::) to log various CVS\nactions. To retrieve the information from the history file, use the\n'cvs history' command (*note history::).\n\nNote: you can control what is logged to this file by using the\n'LogHistory' keyword in the 'CVSROOT/config' file (*note config::).\n" } ] }, "File: cvs.info, Node: user-defined logging, Prev: history database, Up: History browsing": { "content": "", "subsections": [ { "name": "8.3 User-defined logging", "content": "" } ] }, "You can customise CVS to log various kinds of actions, in whatever": { "content": "manner you choose. These mechanisms operate by executing a script at\nvarious times. The script might append a message to a file listing the\ninformation and the programmer who created it, or send mail to a group\nof developers, or, perhaps, post a message to a particular newsgroup.\nTo log commits, use the 'loginfo' file (*note loginfo::), and to log\ntagging operations, use the 'taginfo' file (*note taginfo::).\n\nTo log commits, checkouts, exports, and tags, respectively, you can\nalso use the '-i', '-o', '-e', and '-t' options in the modules file.", "subsections": [] }, "For a more flexible way of giving notifications to various users, which": { "content": "requires less in the way of keeping centralised scripts up to date, use\nthe 'cvs watch add' command (*note Getting Notified::); this command is\nuseful even if you are not using 'cvs watch on'.\n", "subsections": [] }, "File: cvs.info, Node: Binary files, Next: Multiple developers, Prev: History browsing, Up: Top": { "content": "", "subsections": [] }, "9 Handling binary files": { "content": "", "subsections": [] }, "The most common use for CVS is to store text files. With text files,": { "content": "CVS can merge revisions, display the differences between revisions in a\nhuman-visible fashion, and other such operations. However, if you are\nwilling to give up a few of these abilities, CVS can store binary files.", "subsections": [] }, "For example, one might store a web site in CVS including both text files": { "content": "and binary images.\n\n* Menu:\n\n* Binary why:: More details on issues with binary files\n* Binary howto:: How to store them\n", "subsections": [] }, "File: cvs.info, Node: Binary why, Next: Binary howto, Up: Binary files": { "content": "", "subsections": [ { "name": "9.1 The issues with binary files", "content": "" } ] }, "While the need to manage binary files may seem obvious if the files that": { "content": "you customarily work with are binary, putting them into version control\ndoes present some additional issues.\n\nOne basic function of version control is to show the differences\nbetween two revisions. For example, if someone else checked in a new\nversion of a file, you may wish to look at what they changed and\ndetermine whether their changes are good. For text files, CVS provides\nthis functionality via the 'cvs diff' command. For binary files, it may\nbe possible to extract the two revisions and then compare them with a\ntool external to CVS (for example, word processing software often has\nsuch a feature). If there is no such tool, one must track changes via\nother mechanisms, such as urging people to write good log messages, and\nhoping that the changes they actually made were the changes that they\nintended to make.\n\nAnother ability of a version control system is the ability to merge\ntwo revisions. For CVS this happens in two contexts. The first is when\nusers make changes in separate working directories (*note Multiple\ndevelopers::). The second is when one merges explicitly with the\n'update -j' command (*note Branching and merging::).\n\nIn the case of text files, CVS can merge changes made independently,\nand signal a conflict if the changes conflict. With binary files, the\nbest that CVS can do is present the two different copies of the file,\nand leave it to the user to resolve the conflict. The user may choose\none copy or the other, or may run an external merge tool which knows\nabout that particular file format, if one exists. Note that having the\nuser merge relies primarily on the user to not accidentally omit some\nchanges, and thus is potentially error prone.\n\nIf this process is thought to be undesirable, the best choice may be\nto avoid merging. To avoid the merges that result from separate working\ndirectories, see the discussion of reserved checkouts (file locking) in\n*note Multiple developers::. To avoid the merges resulting from\nbranches, restrict use of branches.\n", "subsections": [] }, "File: cvs.info, Node: Binary howto, Prev: Binary why, Up: Binary files": { "content": "", "subsections": [ { "name": "9.2 How to store binary files", "content": "" } ] }, "There are two issues with using CVS to store binary files. The first is": { "content": "that CVS by default converts line endings between the canonical form in\nwhich they are stored in the repository (linefeed only), and the form\nappropriate to the operating system in use on the client (for example,\ncarriage return followed by line feed for Windows NT).\n\nThe second is that a binary file might happen to contain data which\nlooks like a keyword (*note Keyword substitution::), so keyword\nexpansion must be turned off.\n\nThe '-kb' option available with some CVS commands insures that\nneither line ending conversion nor keyword expansion will be done.\n\nHere is an example of how you can create a new file using the '-kb'\nflag:\n\n$ echo '$Id$' > kotest\n$ cvs add -kb -m\"A test file\" kotest\n$ cvs ci -m\"First checkin; contains a keyword\" kotest\n\nIf a file accidentally gets added without '-kb', one can use the 'cvs\nadmin' command to recover. For example:\n\n$ echo '$Id$' > kotest\n$ cvs add -m\"A test file\" kotest\n$ cvs ci -m\"First checkin; contains a keyword\" kotest\n$ cvs admin -kb kotest\n$ cvs update -A kotest\n# For non-unix systems:\n# Copy in a good copy of the file from outside CVS\n$ cvs commit -m \"make it binary\" kotest\n\nWhen you check in the file 'kotest' the file is not preserved as a\nbinary file, because you did not check it in as a binary file. The 'cvs\nadmin -kb' command sets the default keyword substitution method for this\nfile, but it does not alter the working copy of the file that you have.", "subsections": [] }, "If you need to cope with line endings (that is, you are using CVS on a": { "content": "non-unix system), then you need to check in a new copy of the file, as\nshown by the 'cvs commit' command above. On unix, the 'cvs update -A'\ncommand suffices. (Note that you can use 'cvs log' to determine the\ndefault keyword substitution method for a file and 'cvs status' to\ndetermine the keyword substitution method for a working copy.)\n\nHowever, in using 'cvs admin -k' to change the keyword expansion, be\naware that the keyword expansion mode is not version controlled. This\nmeans that, for example, that if you have a text file in old releases,\nand a binary file with the same name in new releases, CVS provides no\nway to check out the file in text or binary mode depending on what\nversion you are checking out. There is no good workaround for this\nproblem.\n\nYou can also set a default for whether 'cvs add' and 'cvs import'\ntreat a file as binary based on its name; for example you could say that\nfiles who names end in '.exe' are binary. *Note Wrappers::. There is\ncurrently no way to have CVS detect whether a file is binary based on\nits contents. The main difficulty with designing such a feature is that\nit is not clear how to distinguish between binary and non-binary files,\nand the rules to apply would vary considerably with the operating\nsystem.\n", "subsections": [] }, "File: cvs.info, Node: Multiple developers, Next: Revision management, Prev: Binary files, Up: Top": { "content": "", "subsections": [] }, "10 Multiple developers": { "content": "", "subsections": [] }, "When more than one person works on a software project things often get": { "content": "complicated. Often, two people try to edit the same file\nsimultaneously. One solution, known as \"file locking\" or \"reserved\ncheckouts\", is to allow only one person to edit each file at a time.", "subsections": [] }, "This is the only solution with some version control systems, including": { "content": "RCS and SCCS. Currently the usual way to get reserved checkouts with\nCVS is the 'cvs admin -l' command (*note admin options::). This is not\nas nicely integrated into CVS as the watch features, described below,\nbut it seems that most people with a need for reserved checkouts find it\nadequate.\n\nAs of CVS version 1.12.10, another technique for getting most of the\neffect of reserved checkouts is to enable advisory locks. To enable\nadvisory locks, have all developers put \"edit -c\", \"commit -c\" in their\n.cvsrc file, and turn on watches in the repository. This prevents them\nfrom doing a 'cvs edit' if anyone is already editing the file. It also\nmay be possible to use plain watches together with suitable procedures\n(not enforced by software), to avoid having two people edit at the same\ntime.\n\nThe default model with CVS is known as \"unreserved checkouts\". In\nthis model, developers can edit their own \"working copy\" of a file\nsimultaneously. The first person that commits his changes has no\nautomatic way of knowing that another has started to edit it. Others\nwill get an error message when they try to commit the file. They must\nthen use CVS commands to bring their working copy up to date with the\nrepository revision. This process is almost automatic.\n\nCVS also supports mechanisms which facilitate various kinds of\ncommunication, without actually enforcing rules like reserved checkouts\ndo.\n\nThe rest of this chapter describes how these various models work, and\nsome of the issues involved in choosing between them.\n\n* Menu:\n\n* File status:: A file can be in several states\n* Updating a file:: Bringing a file up-to-date\n* Conflicts example:: An informative example\n* Informing others:: To cooperate you must inform\n* Concurrency:: Simultaneous repository access\n* Watches:: Mechanisms to track who is editing files\n* Choosing a model:: Reserved or unreserved checkouts?\n", "subsections": [] }, "File: cvs.info, Node: File status, Next: Updating a file, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.1 File status", "content": "" } ] }, "Based on what operations you have performed on a checked out file, and": { "content": "what operations others have performed to that file in the repository,\none can classify a file in a number of states. The states, as reported\nby the 'status' command, are:\n", "subsections": [] }, "Up-to-date": { "content": "The file is identical with the latest revision in the repository\nfor the branch in use.\n", "subsections": [] }, "Locally Modified": { "content": "You have edited the file, and not yet committed your changes.\n", "subsections": [] }, "Locally Added": { "content": "You have added the file with 'add', and not yet committed your\nchanges.\n", "subsections": [] }, "Locally Removed": { "content": "You have removed the file with 'remove', and not yet committed your\nchanges.\n", "subsections": [] }, "Needs Checkout": { "content": "Someone else has committed a newer revision to the repository. The\nname is slightly misleading; you will ordinarily use 'update'\nrather than 'checkout' to get that newer revision.\n", "subsections": [] }, "Needs Patch": { "content": "Like Needs Checkout, but the CVS server will send a patch rather\nthan the entire file. Sending a patch or sending an entire file\naccomplishes the same thing.\n", "subsections": [] }, "Needs Merge": { "content": "Someone else has committed a newer revision to the repository, and\nyou have also made modifications to the file.\n", "subsections": [] }, "Unresolved Conflict": { "content": "A file with the same name as this new file has been added to the\nrepository from a second workspace. This file will need to be\nmoved out of the way to allow an 'update' to complete.\n", "subsections": [] }, "File had conflicts on merge": { "content": "This is like Locally Modified, except that a previous 'update'\ncommand gave a conflict. If you have not already done so, you need\nto resolve the conflict as described in *note Conflicts example::.\n", "subsections": [] }, "Unknown": { "content": "CVS doesn't know anything about this file. For example, you have\ncreated a new file and have not run 'add'.\n\nTo help clarify the file status, 'status' also reports the 'Working\nrevision' which is the revision that the file in the working directory\nderives from, and the 'Repository revision' which is the latest revision\nin the repository for the branch in use. The 'Commit Identifier'\nreflects the unique commitid of the 'commit'.\n\nThe options to 'status' are listed in *note Invoking CVS::. For\ninformation on its 'Sticky tag' and 'Sticky date' output, see *note", "subsections": [] }, "Sticky tags::. For information on its 'Sticky options' output, see the": { "content": "'-k' option in *note update options::.\n\nYou can think of the 'status' and 'update' commands as somewhat\ncomplementary. You use 'update' to bring your files up to date, and you\ncan use 'status' to give you some idea of what an 'update' would do (of\ncourse, the state of the repository might change before you actually run\n'update'). In fact, if you want a command to display file status in a\nmore brief format than is displayed by the 'status' command, you can\ninvoke\n\n$ cvs -n -q update\n\nThe '-n' option means to not actually do the update, but merely to\ndisplay statuses; the '-q' option avoids printing the name of each\ndirectory. For more information on the 'update' command, and these\noptions, see *note Invoking CVS::.\n", "subsections": [] }, "File: cvs.info, Node: Updating a file, Next: Conflicts example, Prev: File status, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.2 Bringing a file up to date", "content": "" } ] }, "When you want to update or merge a file, use the 'cvs update -d'": { "content": "command. For files that are not up to date this is roughly equivalent\nto a 'checkout' command: the newest revision of the file is extracted\nfrom the repository and put in your working directory. The '-d' option,\nnot necessary with 'checkout', tells CVS that you wish it to create\ndirectories added by other developers.\n\nYour modifications to a file are never lost when you use 'update'.", "subsections": [] }, "If no newer revision exists, running 'update' has no effect. If you": { "content": "have edited the file, and a newer revision is available, CVS will merge\nall changes into your working copy.\n\nFor instance, imagine that you checked out revision 1.4 and started\nediting it. In the meantime someone else committed revision 1.5, and\nshortly after that revision 1.6. If you run 'update' on the file now,\nCVS will incorporate all changes between revision 1.4 and 1.6 into your\nfile.\n\nIf any of the changes between 1.4 and 1.6 were made too close to any\nof the changes you have made, an \"overlap\" occurs. In such cases a\nwarning is printed, and the resulting file includes both versions of the\nlines that overlap, delimited by special markers. *Note update::, for a\ncomplete description of the 'update' command.\n", "subsections": [] }, "File: cvs.info, Node: Conflicts example, Next: Informing others, Prev: Updating a file, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.3 Conflicts example", "content": "Suppose revision 1.4 of 'driver.c' contains this:\n\n#include \n\nvoid main()\n{\nparse();\nif (nerr == 0)\ngencode();\nelse\nfprintf(stderr, \"No code generated.\\n\");\nexit(nerr == 0 ? 0 : 1);\n}\n\nRevision 1.6 of 'driver.c' contains this:\n\n#include \n\nint main(int argc,\nchar argv)\n{\nparse();\nif (argc != 1)\n{\nfprintf(stderr, \"tc: No args expected.\\n\");\nexit(1);\n}\nif (nerr == 0)\ngencode();\nelse\nfprintf(stderr, \"No code generated.\\n\");\nexit(!!nerr);\n}\n" } ] }, "Your working copy of 'driver.c', based on revision 1.4, contains this": { "content": "before you run 'cvs update':\n\n#include \n#include \n\nvoid main()\n{\ninitscanner();\nparse();\nif (nerr == 0)\ngencode();\nelse\nfprintf(stderr, \"No code generated.\\n\");\nexit(nerr == 0 ? EXITSUCCESS : EXITFAILURE);\n}\n\nYou run 'cvs update':\n\n$ cvs update driver.c\nRCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v\nretrieving revision 1.4\nretrieving revision 1.6\nMerging differences between 1.4 and 1.6 into driver.c\nrcsmerge warning: overlaps during merge\ncvs update: conflicts found in driver.c\nC driver.c\n\nCVS tells you that there were some conflicts. Your original working\nfile is saved unmodified in '.#driver.c.1.4'. The new version of\n'driver.c' contains this:\n\n#include \n#include \n\nint main(int argc,\nchar argv)\n{\ninitscanner();\nparse();\nif (argc != 1)\n{\nfprintf(stderr, \"tc: No args expected.\\n\");\nexit(1);\n}\nif (nerr == 0)\ngencode();\nelse\nfprintf(stderr, \"No code generated.\\n\");\n<<<<<<< driver.c", "subsections": [ { "name": "exit(nerr == 0 ? EXITSUCCESS : EXITFAILURE);", "content": "exit(!!nerr);\n>>>>>>> 1.6\n}\n\nNote how all non-overlapping modifications are incorporated in your\nworking copy, and that the overlapping section is clearly marked with\n'<<<<<<<', '=======' and '>>>>>>>'.\n\nYou resolve the conflict by editing the file, removing the markers\nand the erroneous line. Suppose you end up with this file:\n#include \n#include \n\nint main(int argc,\nchar argv)\n{\ninitscanner();\nparse();\nif (argc != 1)\n{\nfprintf(stderr, \"tc: No args expected.\\n\");\nexit(1);\n}\nif (nerr == 0)\ngencode();\nelse\nfprintf(stderr, \"No code generated.\\n\");\nexit(nerr == 0 ? EXITSUCCESS : EXITFAILURE);\n}\n\nYou can now go ahead and commit this as revision 1.7.\n\n$ cvs commit -m \"Initialise scanner. Use symbolic exit values.\" driver.c\nChecking in driver.c;\n/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c\nnew revision: 1.7; previous revision: 1.6\ndone\n\nFor your protection, CVS will refuse to check in a file if a conflict\noccurred and you have not resolved the conflict. Currently to resolve a\nconflict, you must change the timestamp on the file. In previous\nversions of CVS, you also needed to insure that the file contains no\nconflict markers. Because your file may legitimately contain conflict\nmarkers (that is, occurrences of '>>>>>>> ' at the start of a line that\ndon't mark a conflict), the current version of CVS will print a warning\nand proceed to check in the file.\n\nIf you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end\nfor CVS) you can use an Emacs package called emerge to help you resolve\nconflicts. See the documentation for pcl-cvs.\n" } ] }, "File: cvs.info, Node: Informing others, Next: Concurrency, Prev: Conflicts example, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.4 Informing others about commits", "content": "" } ] }, "It is often useful to inform others when you commit a new revision of a": { "content": "file. The '-i' option of the 'modules' file, or the 'loginfo' file, can\nbe used to automate this process. *Note modules::. *Note loginfo::.", "subsections": [] }, "You can use these features of CVS to, for instance, instruct CVS to mail": { "content": "a message to all developers, or post a message to a local newsgroup.\n", "subsections": [] }, "File: cvs.info, Node: Concurrency, Next: Watches, Prev: Informing others, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.5 Several developers simultaneously attempting to run CVS", "content": "" } ] }, "If several developers try to run CVS at the same time, one may get the": { "content": "following message:\n\n[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo\n\nCVS will try again every 30 seconds, and either continue with the\noperation or print the message again, if it still needs to wait. If a\nlock seems to stick around for an undue amount of time, find the person\nholding the lock and ask them about the cvs command they are running.", "subsections": [] }, "If they aren't running a cvs command, look in the repository directory": { "content": "mentioned in the message and remove files which they own whose names\nstart with '#cvs.rfl', '#cvs.wfl', or '#cvs.lock'.\n\nNote that these locks are to protect CVS's internal data structures\nand have no relationship to the word \"lock\" in the sense used by\nRCS--which refers to reserved checkouts (*note Multiple developers::).\n\nAny number of people can be reading from a given repository at a\ntime; only when someone is writing do the locks prevent other people\nfrom reading or writing.\n\nOne might hope for the following property:\n\nIf someone commits some changes in one cvs command, then an update\nby someone else will either get all the changes, or none of them.\n\nbut CVS does not have this property. For example, given the files\n\na/one.c\na/two.c\nb/three.c\nb/four.c\n\nif someone runs\n\ncvs ci a/two.c b/three.c\n\nand someone else runs 'cvs update' at the same time, the person running\n'update' might get only the change to 'b/three.c' and not the change to\n'a/two.c'.\n", "subsections": [] }, "File: cvs.info, Node: Watches, Next: Choosing a model, Prev: Concurrency, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.6 Mechanisms to track who is editing files", "content": "" } ] }, "For many groups, use of CVS in its default mode is perfectly": { "content": "satisfactory. Users may sometimes go to check in a modification only to\nfind that another modification has intervened, but they deal with it and\nproceed with their check in. Other groups prefer to be able to know who\nis editing what files, so that if two people try to edit the same file\nthey can choose to talk about who is doing what when rather than be\nsurprised at check in time. The features in this section allow such\ncoordination, while retaining the ability of two developers to edit the\nsame file at the same time.\n\nFor maximum benefit developers should use 'cvs edit' (not 'chmod') to\nmake files read-write to edit them, and 'cvs release' (not 'rm') to\ndiscard a working directory which is no longer in use, but CVS is not\nable to enforce this behavior.\n\nIf a development team wants stronger enforcement of watches and all\nteam members are using a CVS client version 1.12.10 or greater to access\na CVS server version 1.12.10 or greater, they can enable advisory locks.\nTo enable advisory locks, have all developers put \"edit -c\" and \"commit\n-c\" into all .cvsrc files, and make files default to read only by\nturning on watches or putting \"cvs -r\" into all .cvsrc files. This\nprevents multiple people from editing a file at the same time (unless\nexplicitly overriden with '-f').\n\n* Menu:\n\n* Setting a watch:: Telling CVS to watch certain files\n* Getting Notified:: Telling CVS to notify you\n* Editing files:: How to edit a file which is being watched\n* Watch information:: Information about who is watching and editing\n* Watches Compatibility:: Watches interact poorly with CVS 1.6 or earlier\n", "subsections": [] }, "File: cvs.info, Node: Setting a watch, Next: Getting Notified, Up: Watches": { "content": "", "subsections": [] }, "To enable the watch features, you first specify that certain files are": { "content": "to be watched.\n\n-- Command: cvs watch on [-lR] [FILES]...\n\nSpecify that developers should run 'cvs edit' before editing FILES.\nCVS will create working copies of FILES read-only, to remind\ndevelopers to run the 'cvs edit' command before working on them.\n\nIf FILES includes the name of a directory, CVS arranges to watch\nall files added to the corresponding repository directory, and sets\na default for files added in the future; this allows the user to\nset notification policies on a per-directory basis. The contents\nof the directory are processed recursively, unless the '-l' option\nis given. The '-R' option can be used to force recursion if the\n'-l' option is set in '~/.cvsrc' (*note ~/.cvsrc::).\n\nIf FILES is omitted, it defaults to the current directory.\n\n-- Command: cvs watch off [-lR] [FILES]...\n\nDo not create FILES read-only on checkout; thus, developers will\nnot be reminded to use 'cvs edit' and 'cvs unedit'.\n\nThe FILES and options are processed as for 'cvs watch on'.\n", "subsections": [] }, "File: cvs.info, Node: Getting Notified, Next: Editing files, Prev: Setting a watch, Up: Watches": { "content": "", "subsections": [] }, "You can tell CVS that you want to receive notifications about various": { "content": "actions taken on a file. You can do this without using 'cvs watch on'\nfor the file, but generally you will want to use 'cvs watch on', to\nremind developers to use the 'cvs edit' command.\n\n-- Command: cvs watch add [-lR] [-a ACTION]... [FILES]...\n\nAdd the current user to the list of people to receive notification\nof work done on FILES.\n\nThe '-a' option specifies what kinds of events CVS should notify\nthe user about. ACTION is one of the following:\n\n'edit'\nAnother user has applied the 'cvs edit' command (described\nbelow) to a watched file.\n\n'commit'\nAnother user has committed changes to one of the named FILES.\n\n'unedit'\nAnother user has abandoned editing a file (other than by\ncommitting changes). They can do this in several ways, by:\n\n* applying the 'cvs unedit' command (described below) to\nthe file\n\n* applying the 'cvs release' command (*note release::) to\nthe file's parent directory (or recursively to a\ndirectory more than one level up)\n\n* deleting the file and allowing 'cvs update' to recreate\nit\n\n'all'\nAll of the above.\n\n'none'\nNone of the above. (This is useful with 'cvs edit', described\nbelow.)\n\nThe '-a' option may appear more than once, or not at all. If\nomitted, the action defaults to 'all'.\n\nThe FILES and options are processed as for 'cvs watch on'.\n\n-- Command: cvs watch remove [-lR] [-a ACTION]... [FILES]...\n\nRemove a notification request established using 'cvs watch add';\nthe arguments are the same. If the '-a' option is present, only\nwatches for the specified actions are removed.\n\nWhen the conditions exist for notification, CVS calls the 'notify'\nadministrative file. Edit 'notify' as one edits the other\nadministrative files (*note Intro administrative files::). This file\nfollows the usual conventions for administrative files (*note syntax::),\nwhere each line is a regular expression followed by a command to\nexecute. The command should contain a single occurrence of '%s' which\nwill be replaced by the user to notify; the rest of the information\nregarding the notification will be supplied to the command on standard\ninput. The standard thing to put in the 'notify' file is the single\nline:\n\nALL mail %s -s \"CVS notification\"\n\nThis causes users to be notified by electronic mail.\n\nNote that if you set this up in the straightforward way, users\nreceive notifications on the server machine. One could of course write\na 'notify' script which directed notifications elsewhere, but to make\nthis easy, CVS allows you to associate a notification address for each\nuser. To do so create a file 'users' in 'CVSROOT' with a line for each\nuser in the format USER:VALUE. Then instead of passing the name of the\nuser to be notified to 'notify', CVS will pass the VALUE (normally an\nemail address on some other machine).\n\nCVS does not notify you for your own changes. Currently this check\nis done based on whether the user name of the person taking the action\nwhich triggers notification matches the user name of the person getting\nnotification. In fact, in general, the watches features only track one\nedit by each user. It probably would be more useful if watches tracked\neach working directory separately, so this behavior might be worth\nchanging.\n", "subsections": [] }, "File: cvs.info, Node: Editing files, Next: Watch information, Prev: Getting Notified, Up: Watches": { "content": "", "subsections": [] }, "Since a file which is being watched is checked out read-only, you cannot": { "content": "simply edit it. To make it read-write, and inform others that you are\nplanning to edit it, use the 'cvs edit' command. Some systems call this\na \"checkout\", but CVS uses that term for obtaining a copy of the sources\n(*note Getting the source::), an operation which those systems call a\n\"get\" or a \"fetch\".\n\n-- Command: cvs edit [-lR] [-a ACTION]... [FILES]...\n\nPrepare to edit the working files FILES. CVS makes the FILES\nread-write, and notifies users who have requested 'edit'\nnotification for any of FILES.\n\nThe 'cvs edit' command accepts the same options as the 'cvs watch\nadd' command, and establishes a temporary watch for the user on\nFILES; CVS will remove the watch when FILES are 'unedit'ed or\n'commit'ted. If the user does not wish to receive notifications,\nshe should specify '-a none'.\n\nThe FILES and the options are processed as for the 'cvs watch'\ncommands.\n\nThere are two additional options that 'cvs edit' understands as of\nCVS client and server versions 1.12.10 but 'cvs watch' does not.\nThe first is '-c', which causes 'cvs edit' to fail if anyone else\nis editing the file. This is probably only useful when 'edit -c'\nand 'commit -c' are specified in all developers' '.cvsrc' files.\nThis behavior may be overriden this via the '-f' option, which\noverrides '-c' and allows multiple edits to succeed.\n\nNormally when you are done with a set of changes, you use the 'cvs\ncommit' command, which checks in your changes and returns the watched\nfiles to their usual read-only state. But if you instead decide to\nabandon your changes, or not to make any changes, you can use the 'cvs\nunedit' command.\n\n-- Command: cvs unedit [-lR] [FILES]...\n\nAbandon work on the working files FILES, and revert them to the\nrepository versions on which they are based. CVS makes those FILES\nread-only for which users have requested notification using 'cvs\nwatch on'. CVS notifies users who have requested 'unedit'\nnotification for any of FILES.\n\nThe FILES and options are processed as for the 'cvs watch'\ncommands.\n\nIf watches are not in use, the 'unedit' command probably does not\nwork, and the way to revert to the repository version is with the\ncommand 'cvs update -C file' (*note update::). The meaning is not\nprecisely the same; the latter may also bring in some changes which\nhave been made in the repository since the last time you updated.\n\nWhen using client/server CVS, you can use the 'cvs edit' and 'cvs\nunedit' commands even if CVS is unable to successfully communicate with\nthe server; the notifications will be sent upon the next successful CVS\ncommand.\n", "subsections": [] }, "File: cvs.info, Node: Watch information, Next: Watches Compatibility, Prev: Editing files, Up: Watches": { "content": "-- Command: cvs watchers [-lR] [FILES]...\n\nList the users currently watching changes to FILES. The report\nincludes the files being watched, and the mail address of each\nwatcher.\n\nThe FILES and options are processed as for the 'cvs watch'\ncommands.\n\n-- Command: cvs editors [-lR] [FILES]...\n\nList the users currently working on FILES. The report includes the\nmail address of each user, the time when the user began working\nwith the file, and the host and path of the working directory\ncontaining the file.\n\nThe FILES and options are processed as for the 'cvs watch'\ncommands.\n", "subsections": [] }, "File: cvs.info, Node: Watches Compatibility, Prev: Watch information, Up: Watches": { "content": "", "subsections": [] }, "If you use the watch features on a repository, it creates 'CVS'": { "content": "directories in the repository and stores the information about watches\nin that directory. If you attempt to use CVS 1.6 or earlier with the\nrepository, you get an error message such as the following (all on one\nline):\n\ncvs update: cannot open CVS/Entries for reading:\nNo such file or directory\n\nand your operation will likely be aborted. To use the watch features,\nyou must upgrade all copies of CVS which use that repository in local or\nserver mode. If you cannot upgrade, use the 'watch off' and 'watch\nremove' commands to remove all watches, and that will restore the\nrepository to a state which CVS 1.6 can cope with.\n", "subsections": [] }, "File: cvs.info, Node: Choosing a model, Prev: Watches, Up: Multiple developers": { "content": "", "subsections": [ { "name": "10.7 Choosing between reserved or unreserved checkouts", "content": "" } ] }, "Reserved and unreserved checkouts each have pros and cons. Let it be": { "content": "said that a lot of this is a matter of opinion or what works given\ndifferent groups' working styles, but here is a brief description of\nsome of the issues. There are many ways to organise a team of\ndevelopers. CVS does not try to enforce a certain organization. It is\na tool that can be used in several ways.\n\nReserved checkouts can be very counter-productive. If two persons\nwant to edit different parts of a file, there may be no reason to\nprevent either of them from doing so. Also, it is common for someone to\ntake out a lock on a file, because they are planning to edit it, but\nthen forget to release the lock.\n\nPeople, especially people who are familiar with reserved checkouts,\noften wonder how often conflicts occur if unreserved checkouts are used,\nand how difficult they are to resolve. The experience with many groups\nis that they occur rarely and usually are relatively straightforward to\nresolve.\n\nThe rarity of serious conflicts may be surprising, until one realises\nthat they occur only when two developers disagree on the proper design\nfor a given section of code; such a disagreement suggests that the team\nhas not been communicating properly in the first place. In order to\ncollaborate under any source management regimen, developers must agree\non the general design of the system; given this agreement, overlapping\nchanges are usually straightforward to merge.\n\nIn some cases unreserved checkouts are clearly inappropriate. If no\nmerge tool exists for the kind of file you are managing (for example\nword processor files or files edited by Computer Aided Design programs),\nand it is not desirable to change to a program which uses a mergeable\ndata format, then resolving conflicts is going to be unpleasant enough\nthat you generally will be better off to simply avoid the conflicts\ninstead, by using reserved checkouts.\n\nThe watches features described above in *note Watches:: can be\nconsidered to be an intermediate model between reserved checkouts and\nunreserved checkouts. When you go to edit a file, it is possible to\nfind out who else is editing it. And rather than having the system\nsimply forbid both people editing the file, it can tell you what the\nsituation is and let you figure out whether it is a problem in that\nparticular case or not. Therefore, for some groups watches can be\nconsidered the best of both the reserved checkout and unreserved\ncheckout worlds.\n\nAs of CVS client and server versions 1.12.10, you may also enable\nadvisory locks by putting 'edit -c' and 'commit -c' in all developers'\n'.cvsrc' files. After this is done, 'cvs edit' will fail if there are\nany other editors, and 'cvs commit' will fail if the committer has not\nregistered to edit the file via 'cvs edit'. This is most effective in\nconjunction with files checked out read-only by default, which may be\nenabled by turning on watches in the repository or by putting 'cvs -r'\nin all '.cvsrc' files.\n", "subsections": [] }, "File: cvs.info, Node: Revision management, Next: Keyword substitution, Prev: Multiple developers, Up: Top": { "content": "", "subsections": [] }, "11 Revision management": { "content": "", "subsections": [] }, "If you have read this far, you probably have a pretty good grasp on what": { "content": "CVS can do for you. This chapter talks a little about things that you\nstill have to decide.\n\nIf you are doing development on your own using CVS you could probably\nskip this chapter. The questions this chapter takes up become more\nimportant when more than one person is working in a repository.\n\n* Menu:\n\n* When to commit:: Some discussion on the subject\n", "subsections": [] }, "File: cvs.info, Node: When to commit, Up: Revision management": { "content": "", "subsections": [ { "name": "11.1 When to commit?", "content": "" } ] }, "Your group should decide which policy to use regarding commits. Several": { "content": "policies are possible, and as your experience with CVS grows you will\nprobably find out what works for you.\n\nIf you commit files too quickly you might commit files that do not\neven compile. If your partner updates his working sources to include\nyour buggy file, he will be unable to compile the code. On the other\nhand, other persons will not be able to benefit from the improvements\nyou make to the code if you commit very seldom, and conflicts will\nprobably be more common.\n\nIt is common to only commit files after making sure that they can be\ncompiled. Some sites require that the files pass a test suite.\nPolicies like this can be enforced using the commitinfo file (*note\ncommitinfo::), but you should think twice before you enforce such a\nconvention. By making the development environment too controlled it\nmight become too regimented and thus counter-productive to the real\ngoal, which is to get software written.\n", "subsections": [] }, "File: cvs.info, Node: Keyword substitution, Next: Tracking sources, Prev: Revision management, Up: Top": { "content": "", "subsections": [] }, "12 Keyword substitution": { "content": "", "subsections": [] }, "As long as you edit source files inside a working directory you can": { "content": "always find out the state of your files via 'cvs status' and 'cvs log'.", "subsections": [] }, "But as soon as you export the files from your development environment it": { "content": "becomes harder to identify which revisions they are.\n\nCVS can use a mechanism known as \"keyword substitution\" (or \"keyword\nexpansion\") to help identifying the files. Embedded strings of the form\n'$KEYWORD$' and '$KEYWORD:...$' in a file are replaced with strings of\nthe form '$KEYWORD:VALUE$' whenever you obtain a new revision of the\nfile.\n\n* Menu:\n\n* Keyword list:: Keywords\n* Using keywords:: Using keywords\n* Avoiding substitution:: Avoiding substitution\n* Substitution modes:: Substitution modes\n* Configuring keyword expansion:: Configuring keyword expansion\n* Log keyword:: Problems with the $Log$ keyword.\n", "subsections": [] }, "File: cvs.info, Node: Keyword list, Next: Using keywords, Up: Keyword substitution": { "content": "", "subsections": [ { "name": "12.1 Keyword List", "content": "This is a list of the keywords:\n\n'$Author$'\nThe login name of the user who checked in the revision.\n\n'$CVSHeader$'\nA standard header (similar to $Header$, but with the CVS root\nstripped off). It contains the relative pathname of the RCS file\nto the CVS root, the revision number, the date (UTC), the author,\nthe state, and the locker (if locked). Files will normally never\nbe locked when you use CVS.\n\nNote that this keyword has only been recently introduced to CVS and\nmay cause problems with existing installations if $CVSHeader$ is\nalready in the files for a different purpose. This keyword may be\nexcluded using the 'KeywordExpand=eCVSHeader' in the\n'CVSROOT/config' file. See *note Configuring keyword expansion::\nfor more details.\n\n'$Date$'\nThe date and time (UTC) the revision was checked in.\n\n'$Mdocdate$'\nThe date (UTC) the revision was checked in, in a format suitable\nfor the Berkeley mdoc macro processing.\n\n$Mdocdate: January 30 2021 $\n\n'$Header$'\nA standard header containing the full pathname of the RCS file, the\nrevision number, the date (UTC), the author, the state, and the\nlocker (if locked). Files will normally never be locked when you\nuse CVS.\n\n'$Id$'\nSame as '$Header$', except that the RCS filename is without a path.\n\n'$Name$'\nTag name used to check out this file. The keyword is expanded only\nif one checks out with an explicit tag name. For example, when\nrunning the command 'cvs co -r first', the keyword expands to\n'Name: first'.\n\n'$Locker$'\nThe login name of the user who locked the revision (empty if not\nlocked, which is the normal case unless 'cvs admin -l' is in use).\n\n'$Log$'\nThe log message supplied during commit, preceded by a header\ncontaining the RCS filename, the revision number, the author, and\nthe date (UTC). Existing log messages are not replaced. Instead,\nthe new log message is inserted after '$Log:...$'. By default,\neach new line is prefixed with the same string which precedes the\n'$Log$' keyword, unless it exceeds the 'MaxCommentLeaderLength' set\nin 'CVSROOT/config'.\n\nFor example, if the file contains:\n\n/* Here is what people have been up to:\n*\n* $Log: frob.c,v $\n* Revision 1.1 1997/01/03 14:23:51 joe\n* Add the superfrobnicate option\n*\n*/\n\nthen additional lines which are added when expanding the '$Log$'\nkeyword will be preceded by ' * '. Unlike previous versions of CVS\nand RCS, the \"comment leader\" from the RCS file is not used. The\n'$Log$' keyword is useful for accumulating a complete change log in\na source file, but for several reasons it can be problematic.\n\nIf the prefix of the '$Log$' keyword turns out to be longer than\nthe 'CVSROOT/config' setting 'MaxCommentLeaderLength', CVS will\nskip expansion of this keyword unless 'UseArchiveCommentLeader' is\nalso set in 'CVSROOT/config' and a 'comment leader' is set in the\nRCS archive file, in which case the comment leader will be used\ninstead. For more on setting the comment leader in the RCS archive\nfile, *Note admin::. For more on configuring the default '$Log$'\nsubstitution behavior, *Note config::.\n\n*Note Log keyword::.\n\n'$RCSfile$'\nThe name of the RCS file without a path.\n\n'$Revision$'\nThe revision number assigned to the revision.\n\n'$Source$'\nThe full pathname of the RCS file.\n\n'$State$'\nThe state assigned to the revision. States can be assigned with\n'cvs admin -s'--see *note admin options::.\n\n'Local keyword'\nThe 'LocalKeyword' option in the 'CVSROOT/config' file may be used\nto specify a local keyword which is to be used as an alias for one\nof the keywords: $Id$, $Header$, or $CVSHeader$. For example, if\nthe 'CVSROOT/config' file contains a line with\n'LocalKeyword=MYBSD=CVSHeader', then a file with the local keyword\n$MYBSD$ will be expanded as if it were a $CVSHeader$ keyword. If\nthe src/frob.c file contained this keyword, it might look something\nlike this:\n\n/*\n* $MYBSD: src/frob.c,v 1.1 2003/05/04 09:27:45 john Exp $\n*/\n\nMany repositories make use of a such a \"local keyword\" feature. An\nold patch to CVS provided the 'LocalKeyword' feature using a 'tag='\noption and called this the \"custom tag\" or \"local tag\" feature. It\nwas used in conjunction with the what they called the 'tagexpand='\noption. In CVS this other option is known as the 'KeywordExpand'\noption. See *note Configuring keyword expansion:: for more\ndetails.\n\nExamples from popular projects include: $FreeBSD$, $NetBSD$,\n$OpenBSD$, $XFree86$, $Xorg$.\n\nThe advantage of this is that you can include your local version\ninformation in a file using this local keyword without disrupting\nthe upstream version information (which may be a different local\nkeyword or a standard keyword). Allowing bug reports and the like\nto more properly identify the source of the original bug to the\nthird-party and reducing the number of conflicts that arise during\nan import of a new version.\n\nAll keyword expansion except the local keyword may be disabled\nusing the 'KeywordExpand' option in the 'CVSROOT/config' file--see\n*note Configuring keyword expansion:: for more details.\n" } ] }, "File: cvs.info, Node: Using keywords, Next: Avoiding substitution, Prev: Keyword list, Up: Keyword substitution": { "content": "", "subsections": [ { "name": "12.2 Using keywords", "content": "" } ] }, "To include a keyword string you simply include the relevant text string,": { "content": "such as '$Id$', inside the file, and commit the file. CVS will\nautomatically (Or, more accurately, as part of the update run that\nautomatically happens after a commit.) expand the string as part of the\ncommit operation.\n\nIt is common to embed the '$Id$' string in the source files so that\nit gets passed through to generated files. For example, if you are\nmanaging computer program source code, you might include a variable\nwhich is initialised to contain that string. Or some C compilers may\nprovide a '#pragma ident' directive. Or a document management system\nmight provide a way to pass a string through to generated files.\n\nThe 'ident' command (which is part of the RCS package) can be used to\nextract keywords and their values from a file. This can be handy for\ntext files, but it is even more useful for extracting keywords from\nbinary files.\n\n$ ident samp.c\nsamp.c:\n$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $\n$ gcc samp.c\n$ ident a.out\na.out:\n$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $\n\nSCCS is another popular revision control system. It has a command,\n'what', which is very similar to 'ident' and used for the same purpose.", "subsections": [] }, "Many sites without RCS have SCCS. Since 'what' looks for the character": { "content": "sequence '@(#)' it is easy to include keywords that are detected by\neither command. Simply prefix the keyword with the magic SCCS phrase,\nlike this:\n\nstatic char *id=\"@(#) $Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $\";\n", "subsections": [] }, "File: cvs.info, Node: Avoiding substitution, Next: Substitution modes, Prev: Using keywords, Up: Keyword substitution": { "content": "", "subsections": [ { "name": "12.3 Avoiding substitution", "content": "" } ] }, "Keyword substitution has its disadvantages. Sometimes you might want": { "content": "the literal text string '$Author$' to appear inside a file without CVS\ninterpreting it as a keyword and expanding it into something like\n'$Author: ceder $'.\n\nThere is unfortunately no way to selectively turn off keyword\nsubstitution. You can use '-ko' (*note Substitution modes::) to turn\noff keyword substitution entirely.\n\nIn many cases you can avoid using keywords in the source, even though\nthey appear in the final product. For example, the source for this\nmanual contains '$@asis{}Author$' whenever the text '$Author$' should\nappear. In 'nroff' and 'troff' you can embed the null-character '\\&'\ninside the keyword for a similar effect.\n\nIt is also possible to specify an explicit list of keywords to\ninclude or exclude using the 'KeywordExpand' option in the\n'CVSROOT/config' file-see *note Configuring keyword expansion:: for more\ndetails. This feature is intended primarily for use with the\n'LocalKeyword' option-see *note Keyword list::.\n", "subsections": [] }, "File: cvs.info, Node: Substitution modes, Next: Configuring keyword expansion, Prev: Avoiding substitution, Up: Keyword substitution": { "content": "", "subsections": [ { "name": "12.4 Substitution modes", "content": "" } ] }, "Each file has a stored default substitution mode, and each working": { "content": "directory copy of a file also has a substitution mode. The former is\nset by the '-k' option to 'cvs add' and 'cvs admin'; the latter is set\nby the '-k' or '-A' options to 'cvs checkout' or 'cvs update'. 'cvs\ndiff' and 'cvs rdiff' also have '-k' options. For some examples, see\n*note Binary files::, and *note Merging and keywords::.\n\nThe modes available are:\n\n'-kkv'\nGenerate keyword strings using the default form, e.g. '$Revision:\n5.7 $' for the 'Revision' keyword.\n\n'-kkvl'\nLike '-kkv', except that a locker's name is always inserted if the\ngiven revision is currently locked. The locker's name is only\nrelevant if 'cvs admin -l' is in use.\n\n'-kk'\nGenerate only keyword names in keyword strings; omit their values.\nFor example, for the 'Revision' keyword, generate the string\n'$Revision$' instead of '$Revision: 5.7 $'. This option is useful\nto ignore differences due to keyword substitution when comparing\ndifferent revisions of a file (*note Merging and keywords::).\n\n'-ko'\nGenerate the old keyword string, present in the working file just\nbefore it was checked in. For example, for the 'Revision' keyword,\ngenerate the string '$Revision: 1.1 $' instead of '$Revision: 5.7\n$' if that is how the string appeared when the file was checked in.\n\n'-kb'\nLike '-ko', but also inhibit conversion of line endings between the\ncanonical form in which they are stored in the repository (linefeed\nonly), and the form appropriate to the operating system in use on\nthe client. For systems, like unix, which use linefeed only to\nterminate lines, this is very similar to '-ko'. For more\ninformation on binary files, see *note Binary files::. In CVS\nversion 1.12.2 and later '-kb', as set by 'cvs add', 'cvs admin',\nor 'cvs import' may not be overridden by a '-k' option specified on\nthe command line.\n\n'-kv'\nGenerate only keyword values for keyword strings. For example, for\nthe 'Revision' keyword, generate the string '5.7' instead of\n'$Revision: 5.7 $'. This can help generate files in programming\nlanguages where it is hard to strip keyword delimiters like\n'$Revision: $' from a string. However, further keyword\nsubstitution cannot be performed once the keyword names are\nremoved, so this option should be used with care.\n\nOne often would like to use '-kv' with 'cvs export'--*note\nexport::. But be aware that doesn't handle an export containing\nbinary files correctly.\n", "subsections": [] }, "File: cvs.info, Node: Configuring keyword expansion, Next: Log keyword, Prev: Substitution modes, Up: Keyword substitution": { "content": "", "subsections": [ { "name": "12.5 Configuring Keyword Expansion", "content": "" } ] }, "In a repository that includes third-party software on vendor branches,": { "content": "it is sometimes helpful to configure CVS to use a local keyword instead\nof the standard $Id$ or $Header$ keywords. Examples from real projects\ninclude $Xorg$, $XFree86$, $FreeBSD$, $NetBSD$, $OpenBSD$, and even\n$dotat$. The advantage of this is that you can include your local\nversion information in a file using this local keyword (sometimes called\na \"custom tag\" or a \"local tag\") without disrupting the upstream version\ninformation (which may be a different local keyword or a standard\nkeyword). In these cases, it is typically desirable to disable the\nexpansion of all keywords except the configured local keyword.\n\nThe 'KeywordExpand' option in the 'CVSROOT/config' file is intended\nto allow for the either the explicit exclusion of a keyword or list of\nkeywords, or for the explicit inclusion of a keyword or a list of\nkeywords. This list may include the 'LocalKeyword' that has been\nconfigured.\n\nThe 'KeywordExpand' option is followed by '=' and the next character\nmay either be 'i' to start an inclusion list or 'e' to start an\nexclusion list. If the following lines were added to the\n'CVSROOT/config' file:\n\n# Add a \"MyBSD\" keyword and restrict keyword\n# expansion\nLocalKeyword=MyBSD=CVSHeader\nKeywordExpand=iMyBSD\n\nthen only the $MyBSD$ keyword would be expanded. A list may be used.\nThe this example:\n\n# Add a \"MyBSD\" keyword and restrict keyword expansion\n# to the MyBSD, Name, Date and Mdocdate keywords.\nLocalKeyword=MyBSD=CVSHeader\nKeywordExpand=iMyBSD,Name,Date,Mdocdate\n\nwould allow $MyBSD$, $Name$, $Mdocdate and $Date$ to be expanded.\n\nIt is also possible to configure an exclusion list using the\nfollowing:\n\n# Do not expand the non-RCS keyword CVSHeader\nKeywordExpand=eCVSHeader\n\nThis allows CVS to ignore the recently introduced $CVSHeader$ keyword\nand retain all of the others. The exclusion entry could also contain\nthe standard RCS keyword list, but this could be confusing to users that\nexpect RCS keywords to be expanded, so care should be taken to properly\nset user expectations for a repository that is configured in that\nmanner.\n\nIf there is a desire to not have any RCS keywords expanded and not\nuse the '-ko' flags everywhere, an administrator may disable all keyword\nexpansion using the 'CVSROOT/config' line:\n\n# Do not expand any RCS keywords\nKeywordExpand=i\n\nthis could be confusing to users that expect RCS keywords like $Id$\nto be expanded properly, so care should be taken to properly set user\nexpectations for a repository so configured.\n\nIt should be noted that a patch to provide both the 'KeywordExpand'\nand 'LocalKeyword' features has been around a long time. However, that\npatch implemented these features using 'tag=' and 'tagexpand=' keywords\nand those keywords are NOT recognised.\n", "subsections": [] }, "File: cvs.info, Node: Log keyword, Prev: Configuring keyword expansion, Up: Keyword substitution": { "content": "", "subsections": [ { "name": "12.6 Problems with the $Log$ keyword.", "content": "The '$Log$' keyword is somewhat controversial. As long as you are\nworking on your development system the information is easily accessible\neven if you do not use the '$Log$' keyword--just do a 'cvs log'. Once\nyou export the file the history information might be useless anyhow.\n\nA more serious concern is that CVS is not good at handling '$Log$'\nentries when a branch is merged onto the main trunk. Conflicts often\nresult from the merging operation.\n\nPeople also tend to \"fix\" the log entries in the file (correcting\nspelling mistakes and maybe even factual errors). If that is done the\ninformation from 'cvs log' will not be consistent with the information\ninside the file. This may or may not be a problem in real life.\n\nIt has been suggested that the '$Log$' keyword should be inserted\nlast in the file, and not in the files header, if it is to be used at\nall. That way the long list of change messages will not interfere with\neveryday source file browsing.\n" } ] }, "File: cvs.info, Node: Tracking sources, Next: Builds, Prev: Keyword substitution, Up: Top": { "content": "", "subsections": [] }, "13 Tracking third-party sources": { "content": "", "subsections": [] }, "If you modify a program to better fit your site, you probably want to": { "content": "include your modifications when the next release of the program arrives.\nCVS can help you with this task.\n\nIn the terminology used in CVS, the supplier of the program is called\na \"vendor\". The unmodified distribution from the vendor is checked in\non its own branch, the \"vendor branch\". CVS reserves branch 1.1.1 for\nthis use.\n\nWhen you modify the source and commit it, your revision will end up\non the main trunk. When a new release is made by the vendor, you commit\nit on the vendor branch and copy the modifications onto the main trunk.\n\nUse the 'import' command to create and update the vendor branch.", "subsections": [] }, "When you import a new file, (usually) the vendor branch is made the": { "content": "'head' revision, so anyone that checks out a copy of the file gets that\nrevision. When a local modification is committed it is placed on the\nmain trunk, and made the 'head' revision.\n\n* Menu:\n\n* First import:: Importing for the first time\n* Update imports:: Updating with the import command\n* Reverting local changes:: Reverting to the latest vendor release\n* Binary files in imports:: Binary files require special handling\n* Keywords in imports:: Keyword substitution might be undesirable\n* Multiple vendor branches:: What if you get sources from several places?\n", "subsections": [] }, "File: cvs.info, Node: First import, Next: Update imports, Up: Tracking sources": { "content": "", "subsections": [ { "name": "13.1 Importing for the first time", "content": "Use the 'import' command to check in the sources for the first time." } ] }, "When you use the 'import' command to track third-party sources, the": { "content": "\"vendor tag\" and \"release tags\" are useful. The \"vendor tag\" is a\nsymbolic name for the branch (which is always 1.1.1, unless you use the\n'-b BRANCH' flag--see *note Multiple vendor branches::.). The \"release\ntags\" are symbolic names for a particular release, such as 'FSF004'.\n\nNote that 'import' does not change the directory in which you\ninvoke it. In particular, it does not set up that directory as a CVS\nworking directory; if you want to work with the sources import them\nfirst and then check them out into a different directory (*note Getting\nthe source::).\n\nSuppose you have the sources to a program called 'wdiff' in a\ndirectory 'wdiff-0.04', and are going to make private modifications that\nyou want to be able to use even when new releases are made in the\nfuture. You start by importing the source to your repository:\n\n$ cd wdiff-0.04\n$ cvs import -m \"Import of FSF v. 0.04\" fsf/wdiff FSFDIST WDIFF004\n\nThe vendor tag is named 'FSFDIST' in the above example, and the only\nrelease tag assigned is 'WDIFF004'.\n", "subsections": [] }, "File: cvs.info, Node: Update imports, Next: Reverting local changes, Prev: First import, Up: Tracking sources": { "content": "", "subsections": [ { "name": "13.2 Updating with the import command", "content": "" } ] }, "When a new release of the source arrives, you import it into the": { "content": "repository with the same 'import' command that you used to set up the\nrepository in the first place. The only difference is that you specify\na different release tag this time:\n\n$ tar xfz wdiff-0.05.tar.gz\n$ cd wdiff-0.05\n$ cvs import -m \"Import of FSF v. 0.05\" fsf/wdiff FSFDIST WDIFF005\n\nWARNING: If you use a release tag that already exists in one of the\nrepository archives, files removed by an import may not be detected.\n\nFor files that have not been modified locally, the newly created\nrevision becomes the head revision. If you have made local changes,\n'import' will warn you that you must merge the changes into the main\ntrunk, and tell you to use 'checkout -j' to do so:\n\n$ cvs checkout -jFSFDIST:yesterday -jFSFDIST wdiff\n", "subsections": [] }, "The above command will check out the latest revision of 'wdiff', merging": { "content": "the changes made on the vendor branch 'FSFDIST' since yesterday into\nthe working copy. If any conflicts arise during the merge they should\nbe resolved in the normal way (*note Conflicts example::). Then, the\nmodified files may be committed.\n\nHowever, it is much better to use the two release tags rather than\nusing a date on the branch as suggested above:\n\n$ cvs checkout -jWDIFF004 -jWDIFF005 wdiff\n", "subsections": [] }, "The reason this is better is that using a date, as suggested above,": { "content": "assumes that you do not import more than one release of a product per\nday. More importantly, using the release tags allows CVS to detect\nfiles that were removed between the two vendor releases and mark them\nfor removal. Since 'import' has no way to detect removed files, you\nshould do a merge like this even if 'import' doesn't tell you to.\n", "subsections": [] }, "File: cvs.info, Node: Reverting local changes, Next: Binary files in imports, Prev: Update imports, Up: Tracking sources": { "content": "", "subsections": [ { "name": "13.3 Reverting to the latest vendor release", "content": "" } ] }, "You can also revert local changes completely and return to the latest": { "content": "vendor release by changing the 'head' revision back to the vendor branch\non all files. This does, however, produce weird results if you should\never edit this file again, for anyone looking at the output from the\n'log' command or CVSweb. To fix this, first commit a revision of the\nfile which equals the vendor branch, then use 'admin' '-b'. For\nexample, if you have a checked-out copy of the sources in\n'~/work.d/wdiff', and you want to revert to the vendor's version for all\nthe files in that directory, you would type:\n\n$ cd ~/work.d/wdiff\n$ cvs admin -bFSFDIST .\n\nYou must specify the '-bFSFDIST' without any space after the '-b'.\n*Note admin options::.\n", "subsections": [] }, "File: cvs.info, Node: Binary files in imports, Next: Keywords in imports, Prev: Reverting local changes, Up: Tracking sources": { "content": "", "subsections": [ { "name": "13.4 How to handle binary files with cvs import", "content": "Use the '-k' wrapper option to tell import which files are binary.\n*Note Wrappers::.\n" } ] }, "File: cvs.info, Node: Keywords in imports, Next: Multiple vendor branches, Prev: Binary files in imports, Up: Tracking sources": { "content": "", "subsections": [ { "name": "13.5 How to handle keyword substitution with cvs import", "content": "The sources which you are importing may contain keywords (*note Keyword\nsubstitution::). For example, the vendor may use CVS or some other\nsystem which uses similar keyword expansion syntax. If you just import\nthe files in the default fashion, then the keyword expansions supplied\nby the vendor will be replaced by keyword expansions supplied by your\nown copy of CVS. It may be more convenient to maintain the expansions\nsupplied by the vendor, so that this information can supply information\nabout the sources that you imported from the vendor.\n\nTo maintain the keyword expansions supplied by the vendor, supply the\n'-ko' option to 'cvs import' the first time you import the file. This\nwill turn off keyword expansion for that file entirely, so if you want\nto be more selective you'll have to think about what you want and use\nthe '-k' option to 'cvs update' or 'cvs admin' as appropriate.\n" } ] }, "File: cvs.info, Node: Multiple vendor branches, Prev: Keywords in imports, Up: Tracking sources": { "content": "", "subsections": [ { "name": "13.6 Multiple vendor branches", "content": "" } ] }, "All the examples so far assume that there is only one vendor from which": { "content": "you are getting sources. In some situations you might get sources from\na variety of places. For example, suppose that you are dealing with a\nproject where many different people and teams are modifying the\nsoftware. There are a variety of ways to handle this, but in some cases\nyou have a bunch of source trees lying around and what you want to do\nmore than anything else is just to all put them in CVS so that you at\nleast have them in one place.\n\nFor handling situations in which there may be more than one vendor,\nyou may specify the '-b' option to 'cvs import'. It takes as an\nargument the vendor branch to import to. The default is '-b 1.1.1'.\n\nVendor branches can only be in the format 1.1.x where 'x' is an\nuneven number, because branch tags use even numbers.\n\nFor example, suppose that there are two teams, the red team and the\nblue team, that are sending you sources. You want to import the red\nteam's efforts to branch 1.1.1 and use the vendor tag RED. You want to\nimport the blue team's efforts to branch 1.1.3 and use the vendor tag\nBLUE. So the commands you might use are:\n\n$ cvs import dir RED RED1-0\n$ cvs import -b 1.1.3 dir BLUE BLUE1-5\n\nNote that if your vendor tag does not match your '-b' option, CVS\nwill not detect this case! For example,\n\n$ cvs import -b 1.1.3 dir RED RED1-0\n", "subsections": [] }, "Be careful; this kind of mismatch is sure to sow confusion or worse. I": { "content": "can't think of a useful purpose for the ability to specify a mismatch\nhere, but if you discover such a use, don't. CVS is likely to make this\nan error in some future release.\n", "subsections": [] }, "File: cvs.info, Node: Builds, Next: Special Files, Prev: Tracking sources, Up: Top": { "content": "", "subsections": [] }, "14 How your build system interacts with CVS": { "content": "", "subsections": [] }, "As mentioned in the introduction, CVS does not contain software for": { "content": "building your software from source code. This section describes how\nvarious aspects of your build system might interact with CVS.\n\nOne common question, especially from people who are accustomed to\nRCS, is how to make their build get an up to date copy of the sources.", "subsections": [] }, "The answer to this with CVS is two-fold. First of all, since CVS itself": { "content": "can recurse through directories, there is no need to modify your\n'Makefile' (or whatever configuration file your build tool uses) to make\nsure each file is up to date. Instead, just use two commands, first\n'cvs -q update' and then 'make' or whatever the command is to invoke\nyour build tool. Secondly, you do not necessarily want to get a copy\nof a change someone else made until you have finished your own work.", "subsections": [] }, "One suggested approach is to first update your sources, then implement,": { "content": "build and test the change you were thinking of, and then commit your\nsources (updating first if necessary). By periodically (in between\nchanges, using the approach just described) updating your entire tree,\nyou ensure that your sources are sufficiently up to date.\n\nOne common need is to record which versions of which source files\nwent into a particular build. This kind of functionality is sometimes\ncalled \"bill of materials\" or something similar. The best way to do\nthis with CVS is to use the 'tag' command to record which versions went\ninto a given build (*note Tags::).\n\nUsing CVS in the most straightforward manner possible, each developer\nwill have a copy of the entire source tree which is used in a particular\nbuild. If the source tree is small, or if developers are geographically\ndispersed, this is the preferred solution. In fact one approach for\nlarger projects is to break a project down into smaller\nseparately-compiled subsystems, and arrange a way of releasing them\ninternally so that each developer need check out only those subsystems\nwhich they are actively working on.\n\nAnother approach is to set up a structure which allows developers to\nhave their own copies of some files, and for other files to access\nsource files from a central location. Many people have come up with\nsome such a system using features such as the symbolic link feature\nfound in many operating systems, or the 'VPATH' feature found in many\nversions of 'make'. One build tool which is designed to help with this\nkind of thing is Odin (see\n'ftp://ftp.cs.colorado.edu/pub/distribs/odin').\n", "subsections": [] }, "File: cvs.info, Node: Special Files, Next: CVS commands, Prev: Builds, Up: Top": { "content": "", "subsections": [] }, "15 Special Files": { "content": "", "subsections": [] }, "In normal circumstances, CVS works only with regular files. Every file": { "content": "in a project is assumed to be persistent; it must be possible to open,\nread and close them; and so on. CVS also ignores file permissions and\nownerships, leaving such issues to be resolved by the developer at\ninstallation time. In other words, it is not possible to \"check in\" a\ndevice into a repository; if the device file cannot be opened, CVS will\nrefuse to handle it. Files also lose their ownerships and permissions\nduring repository transactions.\n", "subsections": [] }, "File: cvs.info, Node: CVS commands, Next: Invoking CVS, Prev: Special Files, Up: Top": { "content": "", "subsections": [] }, "Appendix A Guide to CVS commands": { "content": "", "subsections": [] }, "This appendix describes the overall structure of CVS commands, and": { "content": "describes some commands in detail (others are described elsewhere; for a\nquick reference to CVS commands, *note Invoking CVS::, and for an\nalphabetical list of all CVS commands, *note CVS command list::).\n\n* Menu:\n\n* Structure:: Overall structure of CVS commands\n* Exit status:: Indicating CVS's success or failure\n* ~/.cvsrc:: Default options with the ~/.cvsrc file\n* Global options:: Options you give to the left of cvscommand\n* Common options:: Options you give to the right of cvscommand\n* Date input formats::\t\tAcceptable formats for date specifications\n* admin:: Administration front-end for RCS\n* annotate:: What revision modified each line of a file?\n* checkout:: Checkout sources for editing\n* commit:: Check files into the repository\n* diff:: Show differences between revisions\n* export:: Export sources from CVS, similar to checkout\n* history:: Show repository access history\n* import:: Import sources into CVS, using vendor branches\n* log:: Print out history information for files\n* ls & rls:: List files in the repository\n* rdiff:: Create 'patch' format diffs between revisions\n* release:: Indicate that a directory is no longer in use\n* server & pserver:: Act as a server for a client on stdin/stdout\n* suck:: Download RCS ,v file raw\n* update:: Bring work tree in sync with repository\n", "subsections": [] }, "File: cvs.info, Node: Structure, Next: Exit status, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.1 Overall structure of CVS commands", "content": "The overall format of all CVS commands is:\n\ncvs [ cvsoptions ] cvscommand [ commandoptions ] [ commandargs ]\n\n'cvs'\nThe name of the CVS program.\n\n'cvsoptions'\nSome options that affect all sub-commands of CVS. These are\ndescribed below.\n\n'cvscommand'\nOne of several different sub-commands. Some of the commands have\naliases that can be used instead; those aliases are noted in the\nreference manual for that command. There are only two situations\nwhere you may omit 'cvscommand': 'cvs -H' elicits a list of\navailable commands, and 'cvs -v' displays version information on\nCVS itself.\n\n'commandoptions'\nOptions that are specific for the command.\n\n'commandargs'\nArguments to the commands.\n\nThere is unfortunately some confusion between 'cvsoptions' and\n'commandoptions'. When given as a 'cvsoption', some options only\naffect some of the commands. When given as a 'commandoption' it may\nhave a different meaning, and be accepted by more commands. In other\nwords, do not take the above categorization too seriously. Look at the\ndocumentation instead.\n\nFile: cvs.info, Node: Exit status, Next: ~/.cvsrc, Prev: Structure, Up: CVS commands\n" }, { "name": "A.2 CVS's exit status", "content": "CVS can indicate to the calling environment whether it succeeded or\nfailed by setting its \"exit status\". The exact way of testing the exit\nstatus will vary from one operating system to another. For example in a\nunix shell script the '$?' variable will be 0 if the last command\nreturned a successful exit status, or greater than 0 if the exit status\nindicated failure.\n\nIf CVS is successful, it returns a successful status; if there is an\nerror, it prints an error message and returns a failure status. The one\nexception to this is the 'cvs diff' command. It will return a\nsuccessful status if it found no differences, or a failure status if\nthere were differences or if there was an error. Because this behavior\nprovides no good way to detect errors, in the future it is possible that\n'cvs diff' will be changed to behave like the other CVS commands.\n\nFile: cvs.info, Node: ~/.cvsrc, Next: Global options, Prev: Exit status, Up: CVS commands\n" }, { "name": "A.3 Default options and the ~/.cvsrc file", "content": "" } ] }, "There are some 'commandoptions' that are used so often that you might": { "content": "have set up an alias or some other means to make sure you always specify\nthat option. One example (the one that drove the implementation of the\n'.cvsrc' support, actually) is that many people find the default output\nof the 'diff' command to be very hard to read, and that either context\ndiffs or unidiffs are much easier to understand.\n\nThe '~/.cvsrc' file is a way that you can add default options to\n'cvscommands' within cvs, instead of relying on aliases or other shell\nscripts.\n\nThe format of the '~/.cvsrc' file is simple. The file is searched\nfor a line that begins with the same name as the 'cvscommand' being\nexecuted. If a match is found, then the remainder of the line is split\nup (at whitespace characters) into separate options and added to the\ncommand arguments before any options from the command line.\n\nIf a command has two names (e.g., 'checkout' and 'co'), the official\nname, not necessarily the one used on the command line, will be used to\nmatch against the file. So if this is the contents of the user's\n'~/.cvsrc' file:\n\nlog -N\ndiff -uN\nrdiff -u\nupdate -Pd\ncheckout -P\nrelease -d\n\nthe command 'cvs checkout foo' would have the '-P' option added to the\narguments, as well as 'cvs co foo'.\n\nWith the example file above, the output from 'cvs diff foobar' will\nbe in unidiff format. 'cvs diff -c foobar' will provide context diffs,\nas usual. Getting \"old\" format diffs would be slightly more\ncomplicated, because 'diff' doesn't have an option to specify use of the\n\"old\" format, so you would need 'cvs -f diff foobar'.\n\nIn place of the command name you can use 'cvs' to specify global\noptions (*note Global options::). For example the following line in\n'.cvsrc'\n\ncvs -z6\n\ncauses CVS to use compression level 6.\n\nFile: cvs.info, Node: Global options, Next: Common options, Prev: ~/.cvsrc, Up: CVS commands\n", "subsections": [ { "name": "A.4 Global options", "content": "" } ] }, "The available 'cvsoptions' (that are given to the left of": { "content": "'cvscommand') are:\n\n'--allow-root=ROOTDIR'\nMay be invoked multiple times to specify one legal CVSROOT\ndirectory with each invocation. Also causes CVS to preparse the\nconfiguration file for each specified root, which can be useful\nwhen configuring write proxies, See *note Password authentication\nserver:: & *note Write proxies::.\n\n'-a'\nAuthenticate all communication between the client and the server.\nOnly has an effect on the CVS client. As of this writing, this is\nonly implemented when using a GSSAPI connection (*note GSSAPI\nauthenticated::). Authentication prevents certain sorts of attacks\ninvolving hijacking the active TCP connection. Enabling\nauthentication does not enable encryption.\n\n'-b BINDIR'\nIn CVS 1.9.18 and older, this specified that RCS programs are in\nthe BINDIR directory. Current versions of CVS do not run RCS\nprograms; for compatibility this option is accepted, but it does\nnothing.\n\n'-T TEMPDIR'\nUse TEMPDIR as the directory where temporary files are located.\n\nThe CVS client and server store temporary files in a temporary\ndirectory. The path to this temporary directory is set via, in\norder of precedence:\n\n* The argument to the global '-T' option.\n\n* The value set for 'TmpDir' in the config file (server only -\n*note config::).\n\n* The contents of the '$TMPDIR' environment variable ('%TMPDIR%'\non Windows - *note Environment variables::).\n\n* /tmp\n\nTemporary directories should always be specified as an absolute\npathname. When running a CVS client, '-T' affects only the local\nprocess; specifying '-T' for the client has no effect on the server\nand vice versa.\n\n'-d CVSROOTDIRECTORY'\nUse CVSROOTDIRECTORY as the root directory pathname of the\nrepository. Overrides the setting of the '$CVSROOT' environment\nvariable. *Note Repository::.\n\n'-e EDITOR'\nUse EDITOR to enter revision log information. Overrides the\nsetting of the '$CVSEDITOR' and '$EDITOR' environment variables.\nFor more information, see *note Committing your changes::.\n\n'-f'\nDo not read the '~/.cvsrc' file. This option is most often used\nbecause of the non-orthogonality of the CVS option set. For\nexample, the 'cvs log' option '-N' (turn off display of tag names)\ndoes not have a corresponding option to turn the display on. So if\nyou have '-N' in the '~/.cvsrc' entry for 'log', you may need to\nuse '-f' to show the tag names.\n\n'-g'\nForges group-writable permissions on files in the working copy.\nThis option is typically used when you have multiple users sharing\na single checked out source tree, allowing them to operate their\nshells with a less dangerous umask at the expense of CVS security.\nTo use this feature, create a directory to hold the checked-out\nsource tree, set it to a private group, and set up the directory\nsuch that files created under it inherit the gid of the directory.\nOn BSD systems, this occurs automatically. On SYSV systems and\nGNU/Linux, the sgid bit must be set on the directory for this. The\nusers who are to share the checked out tree must be placed in that\ngroup which owns the directory.\n\nNote that the sharing of a single checked-out source tree is very\ndifferent from giving several users access to a common CVS\nrepository. Access to a common CVS repository already maintains\nshared group-write permissions and does not require this option.\n\nDue to the security implications, setting this option globally in\nyour '.cvsrc' file is strongly discouraged; if you must, ensure all\nsource checkouts are \"firewalled\" within a private group or a\nprivate mode 0700 directory.\n\nThis option is a MidnightBSD extension merged into Debian and\nMirBSD CVS.\n\n'-H'\n'--help'\nDisplay usage information about the specified 'cvscommand' (but do\nnot actually execute the command). If you don't specify a command\nname, 'cvs -H' displays overall help for CVS, including a list of\nother help options.\n\n'-R'\nTurns on read-only repository mode. This allows one to check out\nfrom a read-only repository, such as within an anoncvs server, or\nfrom a CD-ROM repository.\n\nSame effect as if the 'CVSREADONLYFS' environment variable is set.\nUsing '-R' can also considerably speed up checkouts over NFS.\n\n'-n'\nDo not change any files. Attempt to execute the 'cvscommand', but\nonly to issue reports; do not remove, update, or merge any existing\nfiles, or create any new files.\n\nNote that CVS will not necessarily produce exactly the same output\nas without '-n'. In some cases the output will be the same, but in\nother cases CVS will skip some of the processing that would have\nbeen required to produce the exact same output.\n\n'-Q'\nCause the command to be really quiet; the command will only\ngenerate output for serious problems.\n\n'-q'\nCause the command to be somewhat quiet; informational messages,\nsuch as reports of recursion through subdirectories, are\nsuppressed.\n\n'-r'\nMake new working files read-only. Same effect as if the '$CVSREAD'\nenvironment variable is set (*note Environment variables::). The\ndefault is to make working files writable, unless watches are on\n(*note Watches::).\n\n'-s VARIABLE=VALUE'\nSet a user variable (*note Variables::).\n\n'-t'\nTrace program execution; display messages showing the steps of CVS\nactivity. Particularly useful with '-n' to explore the potential\nimpact of an unfamiliar command.\n\n'-v'\n'--version'\nDisplay version and copyright information for CVS.\n\n'-w'\nMake new working files read-write. Overrides the setting of the\n'$CVSREAD' environment variable. Files are created read-write by\ndefault, unless '$CVSREAD' is set or '-r' is given.\n\n'-x'\nEncrypt all communication between the client and the server. Only\nhas an effect on the CVS client. As of this writing, this is only\nimplemented when using a GSSAPI connection (*note GSSAPI\nauthenticated::) or a Kerberos connection (*note Kerberos\nauthenticated::). Enabling encryption implies that message traffic\nis also authenticated. Encryption support is not available by\ndefault; it must be enabled using a special configure option,\n'--enable-encryption', when you build CVS.\n\n'-z LEVEL'\nRequest compression LEVEL for network traffic. CVS interprets\nLEVEL identically to the 'gzip' program. Valid levels are 1 (high\nspeed, low compression) to 9 (low speed, high compression), or 0 to\ndisable compression (the default). Data sent to the server will be\ncompressed at the requested level and the client will request the\nserver use the same compression level for data returned. The\nserver will use the closest level allowed by the server\nadministrator to compress returned data. This option only has an\neffect when passed to the CVS client.\n", "subsections": [] }, "File: cvs.info, Node: Common options, Next: Date input formats, Prev: Global options, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.5 Common command options", "content": "" } ] }, "This section describes the 'commandoptions' that are available across": { "content": "several CVS commands. These options are always given to the right of\n'cvscommand'. Not all commands support all of these options; each\noption is only supported for commands where it makes sense. However,\nwhen a command has one of these options you can almost always count on\nthe same behavior of the option as in other commands. (Other command\noptions, which are listed with the individual commands, may have\ndifferent behavior from one CVS command to the other).\n\nNote: the 'history' command is an exception; it supports many\noptions that conflict even with these standard options.\n\n'-D DATESPEC'\nUse the most recent revision no later than DATESPEC. DATESPEC is\na single argument, a date description specifying a date in the\npast.\n\nThe specification is \"sticky\" when you use it to make a private\ncopy of a source file; that is, when you get a working file using\n'-D', CVS records the date you specified, so that further updates\nin the same directory will use the same date (for more information\non sticky tags/dates, *note Sticky tags::).\n\n'-D' is available with the 'annotate', 'checkout', 'diff',\n'export', 'history', 'ls', 'rdiff', 'rls', 'rtag', 'tag', and\n'update' commands. (The 'history' command uses this option in a\nslightly different way; *note history options::).\n\nFor a complete description of the date formats accepted by CVS,\n*note Date input formats::.\n\nRemember to quote the argument to the '-D' flag so that your shell\ndoesn't interpret spaces as argument separators. A command using\nthe '-D' flag can look like this:\n\n$ cvs diff -D \"1 hour ago\" cvs.texinfo\n\n'-f'\nWhen you specify a particular date or tag to CVS commands, they\nnormally ignore files that do not contain the tag (or did not exist\nprior to the date) that you specified. Use the '-f' option if you\nwant files retrieved even when there is no match for the tag or\ndate. (The most recent revision of the file will be used).\n\nNote that even with '-f', a tag that you specify must exist (that\nis, in some file, not necessary in every file). This is so that\nCVS will continue to give an error if you mistype a tag name.\n\n'-f' is available with these commands: 'annotate', 'checkout',\n'export', 'rdiff', 'rtag', and 'update'.\n\nWARNING: The 'commit' and 'remove' commands also have a '-f'\noption, but it has a different behavior for those commands. See\n*note commit options::, and *note Removing files::.\n\n'-k KFLAG'\nOverride the default processing of RCS keywords other than '-kb'.\n*Note Keyword substitution::, for the meaning of KFLAG. Used with\nthe 'checkout' and 'update' commands, your KFLAG specification is\n\"sticky\"; that is, when you use this option with a 'checkout' or\n'update' command, CVS associates your selected KFLAG with any files\nit operates on, and continues to use that KFLAG with future\ncommands on the same files until you specify otherwise.\n\nThe '-k' option is available with the 'add', 'checkout', 'diff',\n'export', 'import', 'rdiff', and 'update' commands.\n\nWARNING: Prior to CVS version 1.12.2, the '-k' flag overrode the\n'-kb' indication for a binary file. This could sometimes corrupt\nbinary files. *Note Merging and keywords::, for more.\n\n'-l'\nLocal; run only in current working directory, rather than recursing\nthrough subdirectories.\n\nAvailable with the following commands: 'annotate', 'checkout',\n'commit', 'diff', 'edit', 'editors', 'export', 'log', 'rdiff',\n'remove', 'rtag', 'status', 'tag', 'unedit', 'update', 'watch', and\n'watchers'.\n\n'-m MESSAGE'\nUse MESSAGE as log information, instead of invoking an editor.\n\nAvailable with the following commands: 'add', 'commit' and\n'import'.\n\n'-n'\nDo not run any tag program. (A program can be specified to run in\nthe modules database (*note modules::); this option bypasses it).\n\nNote: this is not the same as the 'cvs -n' program option, which\nyou can specify to the left of a cvs command!\n\nAvailable with the 'checkout', 'commit', 'export', and 'rtag'\ncommands.\n\n'-P'\nPrune empty directories. See *note Removing directories::.\n\n'-p'\nPipe the files retrieved from the repository to standard output,\nrather than writing them in the current directory. Available with\nthe 'checkout' and 'update' commands.\n\n'-R'\nProcess directories recursively. This is the default for all CVS\ncommands, with the exception of 'ls' & 'rls'.\n\nAvailable with the following commands: 'annotate', 'checkout',\n'commit', 'diff', 'edit', 'editors', 'export', 'ls', 'rdiff',\n'remove', 'rls', 'rtag', 'status', 'tag', 'unedit', 'update',\n'watch', and 'watchers'.\n\n'-r TAG'\n'-r TAG[:DATE]'\nUse the revision specified by the TAG argument (and the DATE\nargument for the commands which accept it) instead of the default\n\"head\" revision. As well as arbitrary tags defined with the 'tag'\nor 'rtag' command, two special tags are always available: 'HEAD'\nrefers to the most recent version available in the repository (also\nknown as the tip of the 'MAIN' branch, also known as trunk; the\nname of a branch refers to its tip; this version of CVS introduces\n'.bhead', but only for the DIFF command, for the same), and 'BASE'\nrefers to the revision you last checked out into the current\nworking directory.\n\nThe tag specification is sticky when you use this with 'checkout'\nor 'update' to make your own copy of a file: CVS remembers the tag\nand continues to use it on future update commands, until you\nspecify otherwise (for more information on sticky tags/dates, *note\nSticky tags::).\n\nThe tag can be either a symbolic or numeric tag, as described in\n*note Tags::, or the name of a branch, as described in *note\nBranching and merging::. When TAG is the name of a branch, some\ncommands accept the optional DATE argument to specify the revision\nas of the given date on the branch. When a command expects a\nspecific revision, the name of a branch is interpreted as the most\nrecent revision on that branch.\n\nAs a Debian and MirBSD CVS extension, specifying 'BASE' as the DATE\nportion of the argument yields the base revision of the branch\nspecified by the TAG portion of the argument, i.e. the revision on\nthe parent branch the TAG branch split off, or, where both branches\nwere the same. This option has not received very much testing,\nbeware!\n\nSpecifying the '-q' global option along with the '-r' command\noption is often useful, to suppress the warning messages when the\nRCS file does not contain the specified tag.\n\nNote: this is not the same as the overall 'cvs -r' option, which\nyou can specify to the left of a CVS command!\n\n'-r TAG' is available with the 'commit' and 'history' commands.\n\n'-r TAG[:DATE]' is available with the 'annotate', 'checkout',\n'diff', 'export', 'rdiff', 'rtag', and 'update' commands.\n\n'-W'\nSpecify file names that should be filtered. You can use this\noption repeatedly. The spec can be a file name pattern of the same\ntype that you can specify in the '.cvswrappers' file. Available\nwith the following commands: 'import', and 'update'.\n", "subsections": [] }, "File: cvs.info, Node: Date input formats, Next: admin, Prev: Common options, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.6 Date input formats", "content": "First, a quote:\n\nOur units of temporal measurement, from seconds on up to months,\nare so complicated, asymmetrical and disjunctive so as to make\ncoherent mental reckoning in time all but impossible. Indeed, had\nsome tyrannical god contrived to enslave our minds to time, to make\nit all but impossible for us to escape subjection to sodden\nroutines and unpleasant surprises, he could hardly have done better\nthan handing down our present system. It is like a set of\ntrapezoidal building blocks, with no vertical or horizontal\nsurfaces, like a language in which the simplest thought demands\nornate constructions, useless particles and lengthy\ncircumlocutions. Unlike the more successful patterns of language\nand science, which enable us to face experience boldly or at least\nlevel-headedly, our system of temporal calculation silently and\npersistently encourages our terror of time.\n\n... It is as though architects had to measure length in feet, width\nin meters and height in ells; as though basic instruction manuals\ndemanded a knowledge of five different languages. It is no wonder\nthen that we often look into our own immediate past or future, last\nTuesday or a week from Sunday, with feelings of helpless confusion.\n...\n\n-- Robert Grudin, 'Time and the Art of Living'.\n\nThis section describes the textual date representations that GNU\nprograms accept. These are the strings you, as a user, can supply as\narguments to the various programs. The C interface (via the 'getdate'\nfunction) is not described here.\n\n* Menu:\n\n* General date syntax:: Common rules.\n* Calendar date items:: 19 Dec 1994.\n* Time of day items:: 9:20pm.\n* Time zone items:: EST, PDT, GMT.\n* Day of week items:: Monday and others.\n* Relative items in date strings:: next tuesday, 2 years ago.\n* Pure numbers in date strings:: 19931219, 1440.\n* Seconds since the Epoch:: @1101064456\n* Authors of getdate:: Bellovin, Eggert, Salz, Berets, et al.\n" } ] }, "File: cvs.info, Node: General date syntax, Next: Calendar date items, Up: Date input formats": { "content": "A \"date\" is a string, possibly empty, containing many items separated by\nwhitespace. The whitespace may be omitted when no ambiguity arises.", "subsections": [] }, "The empty string means the beginning of today (i.e., midnight). Order": { "content": "of the items is immaterial. A date string may contain many flavors of\nitems:\n\n* calendar date items\n* time of day items\n* time zone items\n* day of the week items\n* relative items\n* pure numbers.\n\nWe describe each of these item types in turn, below.\n\nA few ordinal numbers may be written out in words in some contexts.", "subsections": [] }, "This is most useful for specifying day of the week items or relative": { "content": "items (see below). Among the most commonly used ordinal numbers, the\nword 'last' stands for -1, 'this' stands for 0, and 'first' and 'next'\nboth stand for 1. Because the word 'second' stands for the unit of time\nthere is no way to write the ordinal number 2, but for convenience\n'third' stands for 3, 'fourth' for 4, 'fifth' for 5, 'sixth' for 6,\n'seventh' for 7, 'eighth' for 8, 'ninth' for 9, 'tenth' for 10,\n'eleventh' for 11 and 'twelfth' for 12.\n\nWhen a month is written this way, it is still considered to be\nwritten numerically, instead of being \"spelled in full\"; this changes\nthe allowed strings.\n\nIn the current implementation, only English is supported for words\nand abbreviations like 'AM', 'DST', 'EST', 'first', 'January', 'Sunday',\n'tomorrow', and 'year'.\n\nThe output of 'date' is not always acceptable as a date string, not\nonly because of the language problem, but also because there is no\nstandard meaning for time zone items like 'IST'. When using 'date' to\ngenerate a date string intended to be parsed later, specify a date\nformat that is independent of language and that does not use time zone\nitems other than 'UTC' and 'Z'. Here are some ways to do this:\n\n$ LCALL=C TZ=UTC0 date\nFri Dec 15 19:48:05 UTC 2000\n$ TZ=UTC0 date +\"%Y-%m-%d %H:%M:%SZ\"\n2000-12-15 19:48:05Z\n$ date --iso-8601=seconds # a GNU extension\n2000-12-15T11:48:05-0800\n$ date --iso-8601=ns # a GNU extension\n2004-02-29T16:21:42,692722128-0800\n$ date --iso-8601=ns | tr T ' ' # --iso-8601 is a GNU extension.\n2004-02-29 16:21:42,692722128-0800\n$ date --rfc-2822 # a GNU extension\nFri, 15 Dec 2000 11:48:05 -0800\n$ date +\"%Y-%m-%d %H:%M:%S %z\" # %z is a GNU extension.\n2000-12-15 11:48:05 -0800\n$ date +'@%s' # %s is a MirBSD extension.\n@1101064210\n$ date +'@%s.%N' # %s and %N are GNU extensions.\n@1078100502.692722128\n\nAlphabetic case is completely ignored in dates. Comments may be\nintroduced between round parentheses, as long as included parentheses\nare properly nested. Hyphens not followed by a digit are currently\nignored. Leading zeros on numbers are ignored.\n", "subsections": [] }, "File: cvs.info, Node: Calendar date items, Next: Time of day items, Prev: General date syntax, Up: Date input formats": { "content": "A \"calendar date item\" specifies a day of the year. It is specified\ndifferently, depending on whether the month is specified numerically or\nliterally. All these strings specify the same calendar date:\n\n1972-09-24 # ISO 8601.\n72-9-24 # Assume 19xx for 69 through 99,\n# 20xx for 00 through 68.\n72-09-24 # Leading zeros are ignored.\n9/24/72 # Common U.S. writing.\n24 September 1972\n24 Sept 72 # September has a special abbreviation.\n24 Sep 72 # Three-letter abbreviations always allowed.\nSep 24, 1972\n24-sep-72\n24sep72\n\nThe year can also be omitted. In this case, the last specified year\nis used, or the current year if none. For example:\n\n9/24\nsep 24\n\nHere are the rules.\n\nFor numeric months, the ISO 8601 format 'YEAR-MONTH-DAY' is allowed,\nwhere YEAR is any positive number, MONTH is a number between 01 and 12,\nand DAY is a number between 01 and 31. A leading zero must be present\nif a number is less than ten. If YEAR is 68 or smaller, then 2000 is\nadded to it; otherwise, if YEAR is less than 100, then 1900 is added to\nit. The construct 'MONTH/DAY/YEAR', popular in the United States, is\naccepted. Also 'MONTH/DAY', omitting the year.\n\nLiteral months may be spelled out in full: 'January', 'February',\n'March', 'April', 'May', 'June', 'July', 'August', 'September',\n'October', 'November' or 'December'. Literal months may be abbreviated\nto their first three letters, possibly followed by an abbreviating dot.\nIt is also permitted to write 'Sept' instead of 'September'.\n\nWhen months are written literally, the calendar date may be given as\nany of the following:\n\nDAY MONTH YEAR\nDAY MONTH\nMONTH DAY YEAR\nDAY-MONTH-YEAR\n\nOr, omitting the year:\n\nMONTH DAY\n", "subsections": [] }, "File: cvs.info, Node: Time of day items, Next: Time zone items, Prev: Calendar date items, Up: Date input formats": { "content": "A \"time of day item\" in date strings specifies the time on a given day.\nHere are some examples, all of which represent the same time:\n\n20:02:00.000000\n20:02\n8:02pm\n20:02-0500 # In EST (U.S. Eastern Standard Time).\n\nMore generally, the time of day may be given as 'HOUR:MINUTE:SECOND',\nwhere HOUR is a number between 0 and 23, MINUTE is a number between 0\nand 59, and SECOND is a number between 0 and 59, with an optional\nfraction separated by '.' or ',' consisting of digits. Alternatively,\n':SECOND' can be omitted, in which case it is taken to be zero.\n\nIf the time is followed by 'am' or 'pm' (or 'a.m.' or 'p.m.'), HOUR\nis restricted to run from 1 to 12, and ':MINUTE' may be omitted (taken\nto be zero). 'am' indicates the first half of the day, 'pm' indicates\nthe second half of the day. In this notation, 12 is the predecessor of\n1: midnight is '12am' while noon is '12pm'. (This is the zero-oriented\ninterpretation of '12am' and '12pm', as opposed to the old tradition\nderived from Latin which uses '12m' for noon and '12pm' for midnight.)\n\nThe time may alternatively be followed by a time zone correction,\nexpressed as 'SHHMM', where S is '+' or '-', HH is a number of zone\nhours and MM is a number of zone minutes. You can also separate HH from\nMM with a colon. When a time zone correction is given this way, it\nforces interpretation of the time relative to Coordinated Universal Time\n(UTC), overriding any previous specification for the time zone or the\nlocal time zone. For example, '+0530' and '+05:30' both stand for the\ntime zone 5.5 hours ahead of UTC (e.g., India). The MINUTE part of the\ntime of day may not be elided when a time zone correction is used. This\nis the best way to specify a time zone correction by fractional parts of\nan hour.\n\nEither 'am'/'pm' or a time zone correction may be specified, but not\nboth.\n", "subsections": [] }, "File: cvs.info, Node: Time zone items, Next: Day of week items, Prev: Time of day items, Up: Date input formats": { "content": "A \"time zone item\" specifies an international time zone, indicated by a\nsmall set of letters, e.g., 'UTC' or 'Z' for Coordinated Universal Time.", "subsections": [] }, "Any included periods are ignored. By following a non-daylight-saving": { "content": "time zone by the string 'DST' in a separate word (that is, separated by\nsome white space), the corresponding daylight saving time zone may be\nspecified. Alternatively, a non-daylight-saving time zone can be\nfollowed by a time zone correction, to add the two values. This is\nnormally done only for 'UTC'; for example, 'UTC+05:30' is equivalent to\n'+05:30'.\n\nTime zone items other than 'UTC' and 'Z' are obsolescent and are not\nrecommended, because they are ambiguous; for example, 'EST' has a\ndifferent meaning in Australia than in the United States. Instead, it's\nbetter to use unambiguous numeric time zone corrections like '-0500', as\ndescribed in the previous section.\n\nIf neither a time zone item nor a time zone correction is supplied,\ntime stamps are interpreted using the rules of the default time zone.\n", "subsections": [] }, "File: cvs.info, Node: Day of week items, Next: Relative items in date strings, Prev: Time zone items, Up: Date input formats": { "content": "", "subsections": [] }, "The explicit mention of a day of the week will forward the date (only if": { "content": "necessary) to reach that day of the week in the future.\n\nDays of the week may be spelled out in full: 'Sunday', 'Monday',\n'Tuesday', 'Wednesday', 'Thursday', 'Friday' or 'Saturday'. Days may be\nabbreviated to their first three letters, optionally followed by a\nperiod. The special abbreviations 'Tues' for 'Tuesday', 'Wednes' for\n'Wednesday' and 'Thur' or 'Thurs' for 'Thursday' are also allowed.\n\nA number may precede a day of the week item to move forward\nsupplementary weeks. It is best used in expression like 'third monday'.", "subsections": [] }, "In this context, 'last DAY' or 'next DAY' is also acceptable; they move": { "content": "one week before or after the day that DAY by itself would represent.\n\nA comma following a day of the week item is ignored.\n", "subsections": [] }, "File: cvs.info, Node: Relative items in date strings, Next: Pure numbers in date strings, Prev: Day of week items, Up: Date input formats": { "content": "\"Relative items\" adjust a date (or the current date if none) forward or\nbackward. The effects of relative items accumulate. Here are some\nexamples:\n\n1 year\n1 year ago\n3 years\n2 days\n\nThe unit of time displacement may be selected by the string 'year' or\n'month' for moving by whole years or months. These are fuzzy units, as\nyears and months are not all of equal duration. More precise units are\n'fortnight' which is worth 14 days, 'week' worth 7 days, 'day' worth 24\nhours, 'hour' worth 60 minutes, 'minute' or 'min' worth 60 seconds, and\n'second' or 'sec' worth one second. An 's' suffix on these units is\naccepted and ignored.\n\nThe unit of time may be preceded by a multiplier, given as an\noptionally signed number. Unsigned numbers are taken as positively\nsigned. No number at all implies 1 for a multiplier. Following a\nrelative item by the string 'ago' is equivalent to preceding the unit by\na multiplier with value -1.\n\nThe string 'tomorrow' is worth one day in the future (equivalent to\n'day'), the string 'yesterday' is worth one day in the past (equivalent\nto 'day ago').\n\nThe strings 'now' or 'today' are relative items corresponding to\nzero-valued time displacement, these strings come from the fact a\nzero-valued time displacement represents the current time when not\notherwise changed by previous items. They may be used to stress other\nitems, like in '12:00 today'. The string 'this' also has the meaning of\na zero-valued time displacement, but is preferred in date strings like\n'this thursday'.\n\nWhen a relative item causes the resulting date to cross a boundary\nwhere the clocks were adjusted, typically for daylight-saving time, the\nresulting date and time are adjusted accordingly.\n\nThe fuzz in units can cause problems with relative items. For\nexample, '2003-07-31 -1 month' might evaluate to 2003-07-01, because\n2003-06-31 is an invalid date. To determine the previous month more\nreliably, you can ask for the month before the 15th of the current\nmonth. For example:\n\n$ date -R\nThu, 31 Jul 2003 13:02:39 -0700\n$ date --date=\"-1 month\" +'Last month was %B?'\nLast month was July?\n$ date --date=\"$(date +%Y-%m-15) -1 month\" +'Last month was %B!'\nLast month was June!\n\nAlso, take care when manipulating dates around clock changes such as\ndaylight saving leaps. In a few cases these have added or subtracted as\nmuch as 24 hours from the clock, so it is often wise to adopt universal\ntime by setting the 'TZ' environment variable to 'UTC0' before embarking\non calendrical calculations.\n", "subsections": [] }, "File: cvs.info, Node: Pure numbers in date strings, Next: Seconds since the Epoch, Prev: Relative items in date strings, Up: Date input formats": { "content": "", "subsections": [] }, "The precise interpretation of a pure decimal number depends on the": { "content": "context in the date string.\n\nIf the decimal number is of the form YYYYMMDD and no other calendar\ndate item (*note Calendar date items::) appears before it in the date\nstring, then YYYY is read as the year, MM as the month number and DD as\nthe day of the month, for the specified calendar date.\n\nIf the decimal number is of the form HHMM and no other time of day\nitem appears before it in the date string, then HH is read as the hour\nof the day and MM as the minute of the hour, for the specified time of\nday. MM can also be omitted.\n\nIf both a calendar date and a time of day appear to the left of a\nnumber in the date string, but no relative item, then the number\noverrides the year.\n", "subsections": [] }, "File: cvs.info, Node: Seconds since the Epoch, Next: Authors of getdate, Prev: Pure numbers in date strings, Up: Date input formats": { "content": "If you give a string consisting of '@' followed by a decimal number, it\nis parsed as an internal time stamp, UTC for POSIX compliant systems,\nTAI for systems which keep time correctly, and directly mapped to a\nkernel time. The implementation handles an optional fraction separated\nby '.' or ',' and truncates to a supported internal precision, rounding\ntowards the negative infinity. Since the kernel time stamp represents\ncomplete date and time information, it cannot be combined with any other\nformat given.\n\nAlthough the date syntax here can represent any possible time since\nthe year zero, computer integers often cannot represent such a wide\nrange of time. On POSIX systems, the clock starts at 1970-01-01\n00:00:00 UTC: POSIX does not require support for times before the POSIX", "subsections": [] }, "Epoch and times far in the future. GNU and traditional Unix systems": { "content": "have 32-bit signed 'timet' and can represent times from 1901-12-13\n20:45:52 through 2038-01-19 03:14:07 UTC, such that '@0' represents the\nepoch, '@1' represents 1970-01-01 00:00:01 UTC, and so forth, whereas\n'@-1', not mandated by POSIX, represents 1969-12-31 23:59:59 UTC.", "subsections": [] }, "Systems with 64-bit signed 'timet' can represent all the times in the": { "content": "known lifetime of the universe. Modern UNIX systems also can give\nprecise timecounters in the nanosecond or even attosecond range with a\nresolution often only a small multiply, like 10000, of the CPU frequency\n(on fast machines).\n\nPOSIX conformant systems do not count leap seconds, and their kernel\ntime is a seconds-since-epoch representation of UTC (which is a calendar\ntime); the MirOS family of operating systems keeps time as seconds since\nthe epoch, TAI, correctly counting leap seconds and providing conversion\nfunctions. Most MirBSD ports have already switched to a 64-bit signed\n'timet', some are using a DJB-compatible 'tait' internally. The rest\nof this document has not been throughoutly checked for UTC vs TAI\ncorrectness. For POSIXly broken systems, '@915148799' represents\n1998-12-31 23:59:59 UTC, '@915148800' represents 1999-01-01 00:00:00\nUTC, and there is no way to represent the intervening leap second\n1998-12-31 23:59:60 UTC. Also, calculation of time deltas is wrong,\nsuch as the age of the MirBSD founder is already off by more than 10\nseconds in 2000.\n", "subsections": [] }, "File: cvs.info, Node: Authors of getdate, Prev: Seconds since the Epoch, Up: Date input formats": { "content": "'getdate' was originally implemented by Steven M. Bellovin\n() while at the University of North Carolina at", "subsections": [] }, "Chapel Hill. The code was later tweaked by a couple of people on": { "content": "Usenet, then completely overhauled by Rich $alz () and\nJim Berets () in August, 1990. Various revisions for\nthe GNU system were made by David MacKenzie, Jim Meyering, Paul Eggert\nand others.\n\nThis chapter was originally produced by Franc,ois Pinard\n() from the 'getdate.y' source code, and then\nedited by K. Berry ().\n\nThe version of this chapter you are reading comes with MirBSD GNU CVS\n1.12 (also in Debian); it is based upon an older version of the GNU\ncoreutils manual which is not yet GFDL-licenced. Appropriate changes\nfor the in-tree 'getdate' version of CVS have been applied. The MirBSD\nversion is maintained by mirabilos .\n", "subsections": [] }, "File: cvs.info, Node: admin, Next: annotate, Prev: Date input formats, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.7 admin--Administration front-end for RCS", "content": "* Requires: repository, working directory.\n* Changes: repository.\n* Synonym: rcs\n\nThis is the CVS interface to assorted administrative facilities." } ] }, "Some of them have questionable usefulness for CVS but exist for": { "content": "historical purposes. Some of the questionable options are likely to\ndisappear in the future. This command does work recursively, so\nextreme care should be used.\n\nOn unix, if there is a group named 'cvsadmin', only members of that\ngroup can run 'cvs admin' commands, except for those specified using the\n'UserAdminOptions' configuration option in the 'CVSROOT/config' file.", "subsections": [] }, "Options specified using 'UserAdminOptions' can be run by any user. See": { "content": "*note config:: for more on 'UserAdminOptions'.\n\nThe 'cvsadmin' group should exist on the server, or any system\nrunning the non-client/server CVS. To disallow 'cvs admin' for all\nusers, create a group with no users in it. On NT, the 'cvsadmin'\nfeature does not exist and all users can run 'cvs admin'.\n\n* Menu:\n\n* admin options:: admin options\n", "subsections": [] }, "File: cvs.info, Node: admin options, Up: admin": { "content": "", "subsections": [] }, "Some of these options have questionable usefulness for CVS but exist for": { "content": "historical purposes. Some even make it impossible to use CVS until you\nundo the effect!\n\n'-AOLDFILE'\nMight not work together with CVS. Append the access list of\nOLDFILE to the access list of the RCS file.\n\n'-aLOGINS'\nMight not work together with CVS. Append the login names appearing\nin the comma-separated list LOGINS to the access list of the RCS\nfile.\n\n'-b[REV]'\nSet the default branch to REV. In CVS, you normally do not\nmanipulate default branches; sticky tags (*note Sticky tags::) are\na better way to decide which branch you want to work on. There is\none reason to run 'cvs admin -b': to revert to the vendor's version\nwhen using vendor branches (*note Reverting local changes::).\nThere can be no space between '-b' and its argument.\n\n'-cSTRING'\nSets the comment leader to STRING. The comment leader is not used\nby current versions of CVS or RCS 5.7. Therefore, you can almost\nsurely not worry about it. *Note Keyword substitution::.\n\n'-e[LOGINS]'\nMight not work together with CVS. Erase the login names appearing\nin the comma-separated list LOGINS from the access list of the RCS\nfile. If LOGINS is omitted, erase the entire access list. There\ncan be no space between '-e' and its argument.\n\n'-I'\nRun interactively, even if the standard input is not a terminal.\nThis option does not work with the client/server CVS and is likely\nto disappear in a future release of CVS.\n\n'-i'\nUseless with CVS. This creates and initialises a new RCS file,\nwithout depositing a revision. With CVS, add files with the 'cvs\nadd' command (*note Adding files::).\n\n'-kSUBST'\nSet the default keyword substitution to SUBST. *Note Keyword\nsubstitution::. Giving an explicit '-k' option to 'cvs update',\n'cvs export', or 'cvs checkout' overrides this default.\n\n'-l[REV]'\nLock the revision with number REV. If a branch is given, lock the\nlatest revision on that branch. If REV is omitted, lock the latest\nrevision on the default branch. There can be no space between '-l'\nand its argument.\n\nThis can be used in conjunction with the 'rcslock.pl' script in the\n'contrib' directory of the CVS source distribution to provide\nreserved checkouts (where only one user can be editing a given file\nat a time). See the comments in that file for details (and see the\n'README' file in that directory for disclaimers about the\nunsupported nature of contrib). According to comments in that\nfile, locking must set to strict (which is the default).\n\n'-L'\nSet locking to strict. Strict locking means that the owner of an\nRCS file is not exempt from locking for checkin. For use with CVS,\nstrict locking must be set; see the discussion under the '-l'\noption above.\n\n'-mREV:MSG'\nReplace the log message of revision REV with MSG.\n\n'-NNAME[:[REV]]'\nAct like '-n', except override any previous assignment of NAME.\nFor use with magic branches, see *note Magic branch numbers::.\n\n'-nNAME[:[REV]]'\nAssociate the symbolic name NAME with the branch or revision REV.\nIt is normally better to use 'cvs tag' or 'cvs rtag' instead.\nDelete the symbolic name if both ':' and REV are omitted;\notherwise, print an error message if NAME is already associated\nwith another number. If REV is symbolic, it is expanded before\nassociation. A REV consisting of a branch number followed by a '.'\nstands for the current latest revision in the branch. A ':' with\nan empty REV stands for the current latest revision on the default\nbranch, normally the trunk. For example, 'cvs admin -nNAME:'\nassociates NAME with the current latest revision of all the RCS\nfiles; this contrasts with 'cvs admin -nNAME:$' which associates\nNAME with the revision numbers extracted from keyword strings in\nthe corresponding working files.\n\n'-oRANGE'\nDeletes (\"outdates\") the revisions given by RANGE.\n\nNote that this command can be quite dangerous unless you know\nexactly what you are doing (for example see the warnings below\nabout how the REV1:REV2 syntax is confusing).\n\nIf you are short on disc this option might help you. But think\ntwice before using it--there is no way short of restoring the\nlatest backup to undo this command! If you delete different\nrevisions than you planned, either due to carelessness or (heaven\nforbid) a CVS bug, there is no opportunity to correct the error\nbefore the revisions are deleted. It probably would be a good idea\nto experiment on a copy of the repository first.\n\nSpecify RANGE in one of the following ways:\n\n'REV1::REV2'\nCollapse all revisions between rev1 and rev2, so that CVS only\nstores the differences associated with going from rev1 to\nrev2, not intermediate steps. For example, after '-o\n1.3::1.5' one can retrieve revision 1.3, revision 1.5, or the\ndifferences to get from 1.3 to 1.5, but not the revision 1.4,\nor the differences between 1.3 and 1.4. Other examples: '-o\n1.3::1.4' and '-o 1.3::1.3' have no effect, because there are\nno intermediate revisions to remove.\n\n'::REV'\nCollapse revisions between the beginning of the branch\ncontaining REV and REV itself. The branchpoint and REV are\nleft intact. For example, '-o ::1.3.2.6' deletes revision\n1.3.2.1, revision 1.3.2.5, and everything in between, but\nleaves 1.3 and 1.3.2.6 intact.\n\n'REV::'\nCollapse revisions between REV and the end of the branch\ncontaining REV. Revision REV is left intact but the head\nrevision is deleted.\n\n'REV'\nDelete the revision REV. For example, '-o 1.3' is equivalent\nto '-o 1.2::1.4'.\n\n'REV1:REV2'\nDelete the revisions from REV1 to REV2, inclusive, on the same\nbranch. One will not be able to retrieve REV1 or REV2 or any\nof the revisions in between. For example, the command 'cvs\nadmin -oR101:R102 .' is rarely useful. It means to delete\nrevisions up to, and including, the tag R102. But beware!\nIf there are files that have not changed between R102 and\nR103 the file will have the same numerical revision number\nassigned to the tags R102 and R103. So not only will it\nbe impossible to retrieve R102; R103 will also have to be\nrestored from the tapes! In most cases you want to specify\nREV1::REV2 instead.\n\n':REV'\nDelete revisions from the beginning of the branch containing\nREV up to and including REV.\n\n'REV:'\nDelete revisions from revision REV, including REV itself, to\nthe end of the branch containing REV.\n\nNone of the revisions to be deleted may have branches or locks.\n\nIf any of the revisions to be deleted have symbolic names, and one\nspecifies one of the '::' syntaxes, then CVS will give an error and\nnot delete any revisions. If you really want to delete both the\nsymbolic names and the revisions, first delete the symbolic names\nwith 'cvs tag -d', then run 'cvs admin -o'. If one specifies the\nnon-'::' syntaxes, then CVS will delete the revisions but leave the\nsymbolic names pointing to nonexistent revisions. This behavior is\npreserved for compatibility with previous versions of CVS, but\nbecause it isn't very useful, in the future it may change to be\nlike the '::' case.\n\nDue to the way CVS handles branches REV cannot be specified\nsymbolically if it is a branch. *Note Magic branch numbers::, for\nan explanation.\n\nMake sure that no-one has checked out a copy of the revision you\noutdate. Strange things will happen if he starts to edit it and\ntries to check it back in. For this reason, this option is not a\ngood way to take back a bogus commit; commit a new revision undoing\nthe bogus change instead (*note Merging two revisions::).\n\n'-q'\nRun quietly; do not print diagnostics.\n\n'-sSTATE[:REV]'\nUseful with CVS. Set the state attribute of the revision REV to\nSTATE. If REV is a branch number, assume the latest revision on\nthat branch. If REV is omitted, assume the latest revision on the\ndefault branch. Any identifier is acceptable for STATE. A useful\nset of states is 'Exp' (for experimental), 'Stab' (for stable), and\n'Rel' (for released). By default, the state of a new revision is\nset to 'Exp' when it is created. The state is visible in the\noutput from CVS LOG (*note log::), and in the '$Log$' and '$State$'\nkeywords (*note Keyword substitution::). Note that CVS uses the\n'dead' state for its own purposes (*note Attic::); to take a file\nto or from the 'dead' state use commands like 'cvs remove' and 'cvs\nadd' (*note Adding and removing::), not 'cvs admin -s'.\n\n'-t[FILE]'\nUseful with CVS. Write descriptive text from the contents of the\nnamed FILE into the RCS file, deleting the existing text. The FILE\npathname may not begin with '-'. The descriptive text can be seen\nin the output from 'cvs log' (*note log::). There can be no space\nbetween '-t' and its argument.\n\nIf FILE is omitted, obtain the text from standard input, terminated\nby end-of-file or by a line containing '.' by itself. Prompt for\nthe text if interaction is possible; see '-I'.\n\n'-t-STRING'\nSimilar to '-tFILE'. Write descriptive text from the STRING into\nthe RCS file, deleting the existing text. There can be no space\nbetween '-t' and its argument.\n\n'-U'\nSet locking to non-strict. Non-strict locking means that the owner\nof a file need not lock a revision for checkin. For use with CVS,\nstrict locking must be set; see the discussion under the '-l'\noption above.\n\n'-u[REV]'\nSee the option '-l' above, for a discussion of using this option\nwith CVS. Unlock the revision with number REV. If a branch is\ngiven, unlock the latest revision on that branch. If REV is\nomitted, remove the latest lock held by the caller. Normally, only\nthe locker of a revision may unlock it; somebody else unlocking a\nrevision breaks the lock. This causes the original locker to be\nsent a 'commit' notification (*note Getting Notified::). There can\nbe no space between '-u' and its argument.\n\n'-VN'\nIn previous versions of CVS, this option meant to write an RCS file\nwhich would be acceptable to RCS version N, but it is now obsolete\nand specifying it will produce an error.\n\n'-xSUFFIXES'\nIn previous versions of CVS, this was documented as a way of\nspecifying the names of the RCS files. However, CVS has always\nrequired that the RCS files used by CVS end in ',v', so this option\nhas never done anything useful.\n", "subsections": [] }, "File: cvs.info, Node: annotate, Next: checkout, Prev: admin, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.8 annotate--What revision modified each line of a file?", "content": "* Synopsis: annotate [options] files...\n\nrannotate [options] files...\n* Requires: repository.\n* Changes: nothing.\n\nFor each file in FILES, print the head revision of the trunk,\ntogether with information on the last modification for each line. If\nbackwards annotation is requested, show the first modification after the\nspecified revision. (Backwards annotation currently appears to be\nbroken.)\n\n* Menu:\n\n* annotate options:: annotate options\n* annotate example:: annotate example\n" } ] }, "File: cvs.info, Node: annotate options, Next: annotate example, Up: annotate": { "content": "These standard options are supported by 'annotate' (*note Common\noptions::, for a complete description of them):\n\n'-b'\nBackwards, show when a line was removed. Currently appears to be\nbroken.\n\n'-l'\nLocal directory only, no recursion.\n\n'-R'\nProcess directories recursively.\n\n'-f'\nUse head revision if tag/date not found.\n\n'-F'\nAnnotate binary files.\n\n'-r TAG[:DATE]'\nAnnotate file as of specified revision/tag or, when DATE is\nspecified and TAG is a branch tag, the version from the branch TAG\nas it existed on DATE. See *note Common options::.\n\n'-D DATE'\nAnnotate file as of specified date.\n", "subsections": [] }, "File: cvs.info, Node: annotate example, Prev: annotate options, Up: annotate": { "content": "For example:\n\n$ cvs annotate ssfile", "subsections": [] }, "Annotations for ssfile": { "content": "1.1 (mary 27-Mar-96): ssfile line 1\n1.2 (joe 28-Mar-96): ssfile line 2\n\nThe file 'ssfile' currently contains two lines. The 'ssfile line 1'\nline was checked in by 'mary' on March 27. Then, on March 28, 'joe'\nadded a line 'ssfile line 2', without modifying the 'ssfile line 1'\nline. This report doesn't tell you anything about lines which have been\ndeleted or replaced; you need to use 'cvs diff' for that (*note diff::).\n\nThe options to 'cvs annotate' are listed in *note Invoking CVS::, and\ncan be used to select the files and revisions to annotate. The options\nare described in more detail there and in *note Common options::.\n", "subsections": [] }, "File: cvs.info, Node: checkout, Next: commit, Prev: annotate, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.9 checkout--Check out sources for editing", "content": "* Synopsis: checkout [options] modules...\n* Requires: repository.\n* Changes: working directory.\n* Synonyms: co, get\n\nCreate or update a working directory containing copies of the source\nfiles specified by MODULES. You must execute 'checkout' before using\nmost of the other CVS commands, since most of them operate on your\nworking directory.\n\nThe MODULES are either symbolic names for some collection of source\ndirectories and files, or paths to directories or files in the\nrepository. The symbolic names are defined in the 'modules' file.\n*Note modules::.\n\nDepending on the modules you specify, 'checkout' may recursively\ncreate directories and populate them with the appropriate source files." } ] }, "You can then edit these source files at any time (regardless of whether": { "content": "other software developers are editing their own copies of the sources);\nupdate them to include new changes applied by others to the source\nrepository; or commit your work as a permanent change to the source\nrepository.\n\nNote that 'checkout' is used to create directories. The top-level\ndirectory created is always added to the directory where 'checkout' is\ninvoked, and usually has the same name as the specified module. In the\ncase of a module alias, the created sub-directory may have a different\nname, but you can be sure that it will be a sub-directory, and that\n'checkout' will show the relative path leading to each file as it is\nextracted into your private work area (unless you specify the '-Q'\nglobal option).\n\nThe files created by 'checkout' are created read-write, unless the\n'-r' option to CVS (*note Global options::) is specified, the 'CVSREAD'\nenvironment variable is specified (*note Environment variables::), or a\nwatch is in effect for that file (*note Watches::).\n\nNote that running 'checkout' on a directory that was already built by\na prior 'checkout' is also permitted. This is similar to specifying the\n'-d' option to the 'update' command in the sense that new directories\nthat have been created in the repository will appear in your work area.", "subsections": [] }, "However, 'checkout' takes a module name whereas 'update' takes a": { "content": "directory name. Also to use 'checkout' this way it must be run from the\ntop level directory (where you originally ran 'checkout' from), so\nbefore you run 'checkout' to update an existing directory, don't forget\nto change your directory to the top level directory.\n\nFor the output produced by the 'checkout' command see *note update\noutput::.\n\n* Menu:\n\n* checkout options:: checkout options\n* checkout examples:: checkout examples\n", "subsections": [] }, "File: cvs.info, Node: checkout options, Next: checkout examples, Up: checkout": { "content": "These standard options are supported by 'checkout' (*note Common\noptions::, for a complete description of them):\n\n'-D DATE'\nUse the most recent revision no later than DATE. This option is\nsticky, and implies '-P'. See *note Sticky tags::, for more\ninformation on sticky tags/dates.\n\n'-f'\nOnly useful with the '-D' or '-r' flags. If no matching revision\nis found, retrieve the most recent revision (instead of ignoring\nthe file).\n\n'-k KFLAG'\nProcess keywords according to KFLAG. See *note Keyword\nsubstitution::. This option is sticky; future updates of this file\nin this working directory will use the same KFLAG. The 'status'\ncommand can be viewed to see the sticky options. See *note\nInvoking CVS::, for more information on the 'status' command.\n\n'-l'\nLocal; run only in current working directory.\n\n'-n'\nDo not run any checkout program (as specified with the '-o' option\nin the modules file; *note modules::).\n\n'-P'\nPrune empty directories. See *note Moving directories::.\n\n'-p'\nPipe files to the standard output.\n\n'-R'\nCheckout directories recursively. This option is on by default.\n\n'-r TAG[:DATE]'\nCheckout the revision specified by TAG or, when DATE is specified\nand TAG is a branch tag, the version from the branch TAG as it\nexisted on DATE. This option is sticky, and implies '-P'. See\n*note Sticky tags::, for more information on sticky tags/dates.\nAlso, see *note Common options::.\n\nIn addition to those, you can use these special command options with\n'checkout':\n\n'-A'\nReset any sticky tags, dates, or '-k' options. See *note Sticky\ntags::, for more information on sticky tags/dates.\n\n'-c'\nCopy the module file, sorted, to the standard output, instead of\ncreating or modifying any files or directories in your working\ndirectory.\n\n'-d DIR'\nCreate a directory called DIR for the working files, instead of\nusing the module name. In general, using this flag is equivalent\nto using 'mkdir DIR; cd DIR' followed by the checkout command\nwithout the '-d' flag.\n\nThere is an important exception, however. It is very convenient\nwhen checking out a single item to have the output appear in a\ndirectory that doesn't contain empty intermediate directories. In\nthis case only, CVS tries to \"shorten\" pathnames to avoid those\nempty directories.\n\nFor example, given a module 'foo' that contains the file 'bar.c',\nthe command 'cvs co -d dir foo' will create directory 'dir' and\nplace 'bar.c' inside. Similarly, given a module 'bar' which has\nsubdirectory 'baz' wherein there is a file 'quux.c', the command\n'cvs co -d dir bar/baz' will create directory 'dir' and place\n'quux.c' inside.\n\nUsing the '-N' flag will defeat this behavior. Given the same\nmodule definitions above, 'cvs co -N -d dir foo' will create\ndirectories 'dir/foo' and place 'bar.c' inside, while 'cvs co -N -d\ndir bar/baz' will create directories 'dir/bar/baz' and place\n'quux.c' inside.\n\n'-j TAG'\nWith two '-j' options, merge changes from the revision specified\nwith the first '-j' option to the revision specified with the\nsecond 'j' option, into the working directory.\n\nWith one '-j' option, merge changes from the ancestor revision to\nthe revision specified with the '-j' option, into the working\ndirectory. The ancestor revision is the common ancestor of the\nrevision which the working directory is based on, and the revision\nspecified in the '-j' option.\n\nIn addition, each -j option can contain an optional date\nspecification which, when used with branches, can limit the chosen\nrevision to one within a specific date. An optional date is\nspecified by adding a colon (:) to the tag:\n'-jSYMBOLICTAG:DATESPECIFIER'.\n\n*Note Branching and merging::.\n\n'-N'\nOnly useful together with '-d DIR'. With this option, CVS will not\n\"shorten\" module paths in your working directory when you check out\na single module. See the '-d' flag for examples and a discussion.\n\n'-s'\nLike '-c', but include the status of all modules, and sort it by\nthe status string. *Note modules::, for info about the '-s' option\nthat is used inside the modules file to set the module status.\n", "subsections": [] }, "File: cvs.info, Node: checkout examples, Prev: checkout options, Up: checkout": { "content": "Get a copy of the module 'tc':\n\n$ cvs checkout tc\n\nGet a copy of the module 'tc' as it looked one day ago:\n\n$ cvs checkout -D yesterday tc\n", "subsections": [] }, "File: cvs.info, Node: commit, Next: diff, Prev: checkout, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.10 commit--Check files into the repository", "content": "* Synopsis: commit [-lnRf] [-m 'logmessage' | -F file] [-r revision]\n[files...]\n* Requires: working directory, repository.\n* Changes: repository.\n* Synonym: ci\n\nUse 'commit' when you want to incorporate changes from your working\nsource files into the source repository.\n\nIf you don't specify particular files to commit, all of the files in\nyour working current directory are examined. 'commit' is careful to\nchange in the repository only those files that you have really changed." } ] }, "By default (or if you explicitly specify the '-R' option), files in": { "content": "subdirectories are also examined and committed if they have changed; you\ncan use the '-l' option to limit 'commit' to the current directory only.\n\n'commit' verifies that the selected files are up to date with the\ncurrent revisions in the source repository; it will notify you, and exit\nwithout committing, if any of the specified files must be made current\nfirst with 'update' (*note update::). 'commit' does not call the\n'update' command for you, but rather leaves that for you to do when the\ntime is right.\n\nWhen all is well, an editor is invoked to allow you to enter a log\nmessage that will be written to one or more logging programs (*note\nmodules::, and *note loginfo::) and placed in the RCS file inside the\nrepository. This log message can be retrieved with the 'log' command;\nsee *note log::. You can specify the log message on the command line\nwith the '-m MESSAGE' option, and thus avoid the editor invocation, or\nuse the '-F FILE' option to specify that the argument file contains the\nlog message.\n\nAt 'commit', a unique commitid is placed in the RCS file inside the\nrepository. All files committed at once get the same commitid, a string\nconsisting only of hexadecimal digits (usually 16 in GNU CVS, 19 in", "subsections": [] }, "Debian and MirBSD CVS). FSF GNU CVS 1.11 and OpenBSD OpenCVS do not": { "content": "support commitids yet. The commitid can be retrieved with the 'log' and\n'status' command; see *note log:: and *note File status::.\n\n* Menu:\n\n* commit options:: commit options\n* commit examples:: commit examples\n", "subsections": [] }, "File: cvs.info, Node: commit options, Next: commit examples, Up: commit": { "content": "These standard options are supported by 'commit' (*note Common\noptions::, for a complete description of them):\n\n'-l'\nLocal; run only in current working directory.\n\n'-R'\nCommit directories recursively. This is on by default.\n\n'-r REVISION'\nCommit to REVISION. REVISION must be either a branch, or a\nrevision on the main trunk that is higher than any existing\nrevision number (*note Assigning revisions::). You cannot commit\nto a specific revision on a branch.\n\n'commit' also supports these options:\n\n'-c'\nRefuse to commit files unless the user has registered a valid edit\non the file via 'cvs edit'. This is most useful when 'commit -c'\nand 'edit -c' have been placed in all '.cvsrc' files. A commit can\nbe forced anyways by either regestering an edit retroactively via\n'cvs edit' (no changes to the file will be lost) or using the '-f'\noption to commit. Support for 'commit -c' requires both client and\na server versions 1.12.10 or greater.\n\n'-F FILE'\nRead the log message from FILE, instead of invoking an editor.\n\n'-f'\nNote that this is not the standard behavior of the '-f' option as\ndefined in *note Common options::.\n\nForce CVS to commit a new revision even if you haven't made any\nchanges to the file. As of CVS version 1.12.10, it also causes the\n'-c' option to be ignored. If the current revision of FILE is 1.7,\nthen the following two commands are equivalent:\n\n$ cvs commit -f FILE\n$ cvs commit -r 1.8 FILE\n\nThe '-f' option disables recursion (i.e., it implies '-l'). To\nforce CVS to commit a new revision for all files in all\nsubdirectories, you must use '-f -R'.\n\n'-m MESSAGE'\nUse MESSAGE as the log message, instead of invoking an editor.\n", "subsections": [] }, "File: cvs.info, Node: commit examples, Prev: commit options, Up: commit": { "content": "A.10.2.1 Committing to a branch\n...............................\n", "subsections": [] }, "You can commit to a branch revision (one that has an even number of": { "content": "dots) with the '-r' option. To create a branch revision, use the '-b'\noption of the 'rtag' or 'tag' commands (*note Branching and merging::).", "subsections": [] }, "Then, either 'checkout' or 'update' can be used to base your sources on": { "content": "the newly created branch. From that point on, all 'commit' changes made\nwithin these working sources will be automatically added to a branch\nrevision, thereby not disturbing main-line development in any way. For\nexample, if you had to create a patch to the 1.2 version of the product,\neven though the 2.0 version is already under development, you might do:\n\n$ cvs rtag -b -r FCS12 FCS12Patch productmodule\n$ cvs checkout -r FCS12Patch productmodule\n$ cd productmodule\n[[ hack away ]]\n$ cvs commit\n\nThis works automatically since the '-r' option is sticky.\n\nA.10.2.2 Creating the branch after editing\n..........................................\n", "subsections": [] }, "Say you have been working on some extremely experimental software, based": { "content": "on whatever revision you happened to checkout last week. If others in\nyour group would like to work on this software with you, but without\ndisturbing main-line development, you could commit your change to a new\nbranch. Others can then checkout your experimental stuff and utilise\nthe full benefit of CVS conflict resolution. The scenario might look\nlike:\n\n[[ hacked sources are present ]]\n$ cvs tag -b EXPR1\n$ cvs update -r EXPR1\n$ cvs commit\n\nThe 'update' command will make the '-r EXPR1' option sticky on all\nfiles. Note that your changes to the files will never be removed by the\n'update' command. The 'commit' will automatically commit to the correct\nbranch, because the '-r' is sticky. You could also do like this:\n\n[[ hacked sources are present ]]\n$ cvs tag -b EXPR1\n$ cvs commit -r EXPR1\n\nbut then, only those files that were changed by you will have the '-r\nEXPR1' sticky flag. If you hack away, and commit without specifying the\n'-r EXPR1' flag, some files may accidentally end up on the main trunk.\n\nTo work with you on the experimental change, others would simply do\n\n$ cvs checkout -r EXPR1 whatevermodule\n", "subsections": [] }, "File: cvs.info, Node: diff, Next: export, Prev: commit, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.11 diff--Show differences between revisions", "content": "* Synopsis: diff [-lR] [-k kflag] [formatoptions] [(-r rev1[:date1]\n| -D date1) [-r rev2[:date2] | -D date2]] [files...]\n* Requires: working directory, repository.\n* Changes: nothing.\n\nThe 'diff' command is used to compare different revisions of files." } ] }, "The default action is to compare your working files with the revisions": { "content": "they were based on, and report any differences that are found.\n\nIf any file names are given, only those files are compared. If any\ndirectories are given, all files under them will be compared.\n\nThe exit status for diff is different than for other CVS commands;\nfor details *note Exit status::.\n\n* Menu:\n\n* diff options:: diff options\n* diff examples:: diff examples\n", "subsections": [] }, "File: cvs.info, Node: diff options, Next: diff examples, Up: diff": { "content": "These standard options are supported by 'diff' (*note Common options::,\nfor a complete description of them):\n\n'-D DATE'\nUse the most recent revision no later than DATE. See '-r' for how\nthis affects the comparison.\n\n'-k KFLAG'\nProcess keywords according to KFLAG. See *note Keyword\nsubstitution::.\n\n'-l'\nLocal; run only in current working directory.\n\n'-R'\nExamine directories recursively. This option is on by default.\n\n'-r TAG[:DATE]'\nCompare with revision specified by TAG or, when DATE is specified\nand TAG is a branch tag, the version from the branch TAG as it\nexisted on DATE. Zero, one or two '-r' options can be present.\nWith no '-r' option, the working file will be compared with the\nrevision it was based on. With one '-r', that revision will be\ncompared to your current working file. With two '-r' options those\ntwo revisions will be compared (and your working file will not\naffect the outcome in any way).\n\nOne or both '-r' options can be replaced by a '-D DATE' option,\ndescribed above.\n\nThe following options specify the format of the output. They have\nthe same meaning as in GNU diff. Most options have two equivalent\nnames, one of which is a single letter preceded by '-', and the other of\nwhich is a long name preceded by '--'.\n\n'-LINES'\nShow LINES (an integer) lines of context. This option does not\nspecify an output format by itself; it has no effect unless it is\ncombined with '-c' or '-u'. This option is obsolete. For proper\noperation, 'patch' typically needs at least two lines of context.\n\n'-a'\nTreat all files as text and compare them line-by-line, even if they\ndo not seem to be text.\n\n'-b'\nIgnore trailing white space and consider all other sequences of one\nor more white space characters to be equivalent.\n\n'-B'\nIgnore changes that just insert or delete blank lines.\n\n'--binary'\nRead and write data in binary mode.\n\n'--brief'\nReport only whether the files differ, not the details of the\ndifferences.\n\n'-c'\nUse the context output format.\n\n'-C LINES'\n'--context[=LINES]'\nUse the context output format, showing LINES (an integer) lines of\ncontext, or three if LINES is not given. For proper operation,\n'patch' typically needs at least two lines of context.\n\n'--changed-group-format=FORMAT'\nUse FORMAT to output a line group containing differing lines from\nboth files in if-then-else format. *Note Line group formats::.\n\n'-d'\nChange the algorithm to perhaps find a smaller set of changes.\nThis makes 'diff' slower (sometimes much slower).\n\n'-e'\n'--ed'\nMake output that is a valid 'ed' script.\n\n'--expand-tabs'\nExpand tabs to spaces in the output, to preserve the alignment of\ntabs in the input files.\n\n'-f'\nMake output that looks vaguely like an 'ed' script but has changes\nin the order they appear in the file.\n\n'-F REGEXP'\nIn context and unified format, for each hunk of differences, show\nsome of the last preceding line that matches REGEXP.\n\n'--forward-ed'\nMake output that looks vaguely like an 'ed' script but has changes\nin the order they appear in the file.\n\n'-H'\nUse heuristics to speed handling of large files that have numerous\nscattered small changes.\n\n'--horizon-lines=LINES'\nDo not discard the last LINES lines of the common prefix and the\nfirst LINES lines of the common suffix.\n\n'-i'\nIgnore changes in case; consider upper- and lower-case letters\nequivalent.\n\n'-I REGEXP'\nIgnore changes that just insert or delete lines that match REGEXP.\n\n'--ifdef=NAME'\nMake merged if-then-else output using NAME.\n\n'--ignore-all-space'\nIgnore white space when comparing lines.\n\n'--ignore-blank-lines'\nIgnore changes that just insert or delete blank lines.\n\n'--ignore-case'\nIgnore changes in case; consider upper- and lower-case to be the\nsame.\n\n'--ignore-matching-lines=REGEXP'\nIgnore changes that just insert or delete lines that match REGEXP.\n\n'--ignore-space-change'\nIgnore trailing white space and consider all other sequences of one\nor more white space characters to be equivalent.\n\n'--initial-tab'\nOutput a tab rather than a space before the text of a line in\nnormal or context format. This causes the alignment of tabs in the\nline to look normal.\n\n'-L LABEL'\nUse LABEL instead of the file name in the context format and\nunified format headers.\n\n'--label=LABEL'\nUse LABEL instead of the file name in the context format and\nunified format headers.\n\n'--left-column'\nPrint only the left column of two common lines in side by side\nformat.\n\n'--line-format=FORMAT'\nUse FORMAT to output all input lines in if-then-else format. *Note\nLine formats::.\n\n'--minimal'\nChange the algorithm to perhaps find a smaller set of changes.\nThis makes 'diff' slower (sometimes much slower).\n\n'-n'\nOutput RCS-format diffs; like '-f' except that each command\nspecifies the number of lines affected.\n\n'-N'\n'--new-file'\nIn directory comparison, if a file is found in only one directory,\ntreat it as present but empty in the other directory.\n\n'--new-group-format=FORMAT'\nUse FORMAT to output a group of lines taken from just the second\nfile in if-then-else format. *Note Line group formats::.\n\n'--new-line-format=FORMAT'\nUse FORMAT to output a line taken from just the second file in\nif-then-else format. *Note Line formats::.\n\n'--old-group-format=FORMAT'\nUse FORMAT to output a group of lines taken from just the first\nfile in if-then-else format. *Note Line group formats::.\n\n'--old-line-format=FORMAT'\nUse FORMAT to output a line taken from just the first file in\nif-then-else format. *Note Line formats::.\n\n'-p'\nShow which C function each change is in.\n\n'--rcs'\nOutput RCS-format diffs; like '-f' except that each command\nspecifies the number of lines affected.\n\n'--report-identical-files'\n'-s'\nReport when two files are the same.\n\n'--show-c-function'\nShow which C function each change is in.\n\n'--show-function-line=REGEXP'\nIn context and unified format, for each hunk of differences, show\nsome of the last preceding line that matches REGEXP.\n\n'--side-by-side'\nUse the side by side output format.\n\n'--speed-large-files'\nUse heuristics to speed handling of large files that have numerous\nscattered small changes.\n\n'--suppress-common-lines'\nDo not print common lines in side by side format.\n\n'-t'\nExpand tabs to spaces in the output, to preserve the alignment of\ntabs in the input files.\n\n'-T'\nOutput a tab rather than a space before the text of a line in\nnormal or context format. This causes the alignment of tabs in the\nline to look normal.\n\n'--text'\nTreat all files as text and compare them line-by-line, even if they\ndo not appear to be text.\n\n'-u'\nUse the unified output format.\n\n'--unchanged-group-format=FORMAT'\nUse FORMAT to output a group of common lines taken from both files\nin if-then-else format. *Note Line group formats::.\n\n'--unchanged-line-format=FORMAT'\nUse FORMAT to output a line common to both files in if-then-else\nformat. *Note Line formats::.\n\n'-U LINES'\n'--unified[=LINES]'\nUse the unified output format, showing LINES (an integer) lines of\ncontext, or three if LINES is not given. For proper operation,\n'patch' typically needs at least two lines of context.\n\n'-w'\nIgnore white space when comparing lines.\n\n'-W COLUMNS'\n'--width=COLUMNS'\nUse an output width of COLUMNS in side by side format.\n\n'-y'\nUse the side by side output format.\n\n* Menu:\n\n* Line group formats:: Line group formats\n* Line formats:: Line formats\n", "subsections": [] }, "File: cvs.info, Node: Line group formats, Next: Line formats, Up: diff options": { "content": "A.11.1.1 Line group formats\n...........................\n", "subsections": [] }, "Line group formats let you specify formats suitable for many": { "content": "applications that allow if-then-else input, including programming\nlanguages and text formatting languages. A line group format specifies\nthe output format for a contiguous group of similar lines.\n\nFor example, the following command compares the TeX file 'myfile'\nwith the original version from the repository, and outputs a merged file\nin which old regions are surrounded by '\\begin{em}'-'\\end{em}' lines,\nand new regions are surrounded by '\\begin{bf}'-'\\end{bf}' lines.\n\ncvs diff \\\n--old-group-format='\\begin{em}\n%<\\end{em}\n' \\\n--new-group-format='\\begin{bf}\n%>\\end{bf}\n' \\\nmyfile\n\nThe following command is equivalent to the above example, but it is a\nlittle more verbose, because it spells out the default line group\nformats.\n\ncvs diff \\\n--old-group-format='\\begin{em}\n%<\\end{em}\n' \\\n--new-group-format='\\begin{bf}\n%>\\end{bf}\n' \\\n--unchanged-group-format='%=' \\\n--changed-group-format='\\begin{em}\n%<\\end{em}\n\\begin{bf}\n%>\\end{bf}\n' \\\nmyfile\n\nHere is a more advanced example, which outputs a diff listing with\nheaders containing line numbers in a \"plain English\" style.\n\ncvs diff \\\n--unchanged-group-format='' \\\n--old-group-format='-------- %dn line%(n=1?:s) deleted at %df:\n%<' \\\n--new-group-format='-------- %dN line%(N=1?:s) added after %de:\n%>' \\\n--changed-group-format='-------- %dn line%(n=1?:s) changed at %df:\n%<-------- to:\n%>' \\\nmyfile\n\nTo specify a line group format, use one of the options listed below.", "subsections": [] }, "You can specify up to four line group formats, one for each kind of line": { "content": "group. You should quote FORMAT, because it typically contains shell\nmetacharacters.\n\n'--old-group-format=FORMAT'\nThese line groups are hunks containing only lines from the first\nfile. The default old group format is the same as the changed\ngroup format if it is specified; otherwise it is a format that\noutputs the line group as-is.\n\n'--new-group-format=FORMAT'\nThese line groups are hunks containing only lines from the second\nfile. The default new group format is same as the changed group\nformat if it is specified; otherwise it is a format that outputs\nthe line group as-is.\n\n'--changed-group-format=FORMAT'\nThese line groups are hunks containing lines from both files. The\ndefault changed group format is the concatenation of the old and\nnew group formats.\n\n'--unchanged-group-format=FORMAT'\nThese line groups contain lines common to both files. The default\nunchanged group format is a format that outputs the line group\nas-is.\n\nIn a line group format, ordinary characters represent themselves;\nconversion specifications start with '%' and have one of the following\nforms.\n\n'%<'\nstands for the lines from the first file, including the trailing\nnewline. Each line is formatted according to the old line format\n(*note Line formats::).\n\n'%>'\nstands for the lines from the second file, including the trailing\nnewline. Each line is formatted according to the new line format.\n\n'%='\nstands for the lines common to both files, including the trailing\nnewline. Each line is formatted according to the unchanged line\nformat.\n\n'%%'\nstands for '%'.\n\n'%c'C''\nwhere C is a single character, stands for C. C may not be a\nbackslash or an apostrophe. For example, '%c':'' stands for a\ncolon, even inside the then-part of an if-then-else format, which a\ncolon would normally terminate.\n\n'%c'\\O''\nwhere O is a string of 1, 2, or 3 octal digits, stands for the\ncharacter with octal code O. For example, '%c'\\0'' stands for a\nnull character.\n\n'FN'\nwhere F is a 'printf' conversion specification and N is one of the\nfollowing letters, stands for N's value formatted with F.\n\n'e'\nThe line number of the line just before the group in the old\nfile.\n\n'f'\nThe line number of the first line in the group in the old\nfile; equals E + 1.\n\n'l'\nThe line number of the last line in the group in the old file.\n\n'm'\nThe line number of the line just after the group in the old\nfile; equals L + 1.\n\n'n'\nThe number of lines in the group in the old file; equals L - F\n+ 1.\n\n'E, F, L, M, N'\nLikewise, for lines in the new file.\n\nThe 'printf' conversion specification can be '%d', '%o', '%x', or\n'%X', specifying decimal, octal, lower case hexadecimal, or upper\ncase hexadecimal output respectively. After the '%' the following\noptions can appear in sequence: a '-' specifying\nleft-justification; an integer specifying the minimum field width;\nand a period followed by an optional integer specifying the minimum\nnumber of digits. For example, '%5dN' prints the number of new\nlines in the group in a field of width 5 characters, using the\n'printf' format '\"%5d\"'.\n\n'(A=B?T:E)'\nIf A equals B then T else E. A and B are each either a decimal\nconstant or a single letter interpreted as above. This format spec\nis equivalent to T if A's value equals B's; otherwise it is\nequivalent to E.\n\nFor example, '%(N=0?no:%dN) line%(N=1?:s)' is equivalent to 'no\nlines' if N (the number of lines in the group in the new file) is\n0, to '1 line' if N is 1, and to '%dN lines' otherwise.\n", "subsections": [] }, "File: cvs.info, Node: Line formats, Prev: Line group formats, Up: diff options": { "content": "A.11.1.2 Line formats\n.....................\n", "subsections": [] }, "Line formats control how each line taken from an input file is output as": { "content": "part of a line group in if-then-else format.\n\nFor example, the following command outputs text with a one-column\nchange indicator to the left of the text. The first column of output is\n'-' for deleted lines, '|' for added lines, and a space for unchanged\nlines. The formats contain newline characters where newlines are\ndesired on output.\n\ncvs diff \\\n--old-line-format='-%l\n' \\\n--new-line-format='|%l\n' \\\n--unchanged-line-format=' %l\n' \\\nmyfile\n\nTo specify a line format, use one of the following options. You\nshould quote FORMAT, since it often contains shell metacharacters.\n\n'--old-line-format=FORMAT'\nformats lines just from the first file.\n\n'--new-line-format=FORMAT'\nformats lines just from the second file.\n\n'--unchanged-line-format=FORMAT'\nformats lines common to both files.\n\n'--line-format=FORMAT'\nformats all lines; in effect, it sets all three above options\nsimultaneously.\n\nIn a line format, ordinary characters represent themselves;\nconversion specifications start with '%' and have one of the following\nforms.\n\n'%l'\nstands for the contents of the line, not counting its trailing\nnewline (if any). This format ignores whether the line is\nincomplete.\n\n'%L'\nstands for the contents of the line, including its trailing newline\n(if any). If a line is incomplete, this format preserves its\nincompleteness.\n\n'%%'\nstands for '%'.\n\n'%c'C''\nwhere C is a single character, stands for C. C may not be a\nbackslash or an apostrophe. For example, '%c':'' stands for a\ncolon.\n\n'%c'\\O''\nwhere O is a string of 1, 2, or 3 octal digits, stands for the\ncharacter with octal code O. For example, '%c'\\0'' stands for a\nnull character.\n\n'Fn'\nwhere F is a 'printf' conversion specification, stands for the line\nnumber formatted with F. For example, '%.5dn' prints the line\nnumber using the 'printf' format '\"%.5d\"'. *Note Line group\nformats::, for more about printf conversion specifications.\n\nThe default line format is '%l' followed by a newline character.\n\nIf the input contains tab characters and it is important that they\nline up on output, you should ensure that '%l' or '%L' in a line format\nis just after a tab stop (e.g. by preceding '%l' or '%L' with a tab\ncharacter), or you should use the '-t' or '--expand-tabs' option.\n\nTaken together, the line and line group formats let you specify many\ndifferent formats. For example, the following command uses a format\nsimilar to 'diff''s normal format. You can tailor this command to get\nfine control over 'diff''s output.\n\ncvs diff \\\n--old-line-format='< %l\n' \\\n--new-line-format='> %l\n' \\\n--old-group-format='%df%(f=l?:,%dl)d%dE\n%<' \\\n--new-group-format='%dea%dF%(F=L?:,%dL)\n%>' \\\n--changed-group-format='%df%(f=l?:,%dl)c%dF%(F=L?:,%dL)\n%<---\n%>' \\\n--unchanged-group-format='' \\\nmyfile\n", "subsections": [] }, "File: cvs.info, Node: diff examples, Prev: diff options, Up: diff": { "content": "", "subsections": [] }, "The following line produces a Unidiff ('-u' flag) between revision 1.14": { "content": "and 1.19 of 'backend.c'. Due to the '-kk' flag no keywords are\nsubstituted, so differences that only depend on keyword substitution are\nignored.\n\n$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c\n\nSuppose the experimental branch EXPR1 was based on a set of files\ntagged RELEASE10. To see what has happened on that branch, the\nfollowing can be used:\n\n$ cvs diff -r RELEASE10 -r EXPR1\n\nA command like this can be used to produce a context diff between two\nreleases:\n\n$ cvs diff -c -r RELEASE10 -r RELEASE11 > diffs\n\nIf you are maintaining ChangeLogs, a command like the following just\nbefore you commit your changes may help you write the ChangeLog entry.", "subsections": [] }, "All local modifications that have not yet been committed will be": { "content": "printed.\n\n$ cvs diff -u | less\n", "subsections": [] }, "File: cvs.info, Node: export, Next: history, Prev: diff, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.12 export--Export sources from CVS, similar to checkout", "content": "* Synopsis: export [-flNnR] (-r rev[:date] | -D date) [-k subst] [-d\ndir] module...\n* Requires: repository.\n* Changes: current directory.\n\nThis command is a variant of 'checkout'; use it when you want a copy\nof the source for module without the CVS administrative directories." } ] }, "For example, you might use 'export' to prepare source for shipment": { "content": "off-site. This command requires that you specify a date or tag (with\n'-D' or '-r'), so that you can count on reproducing the source you ship\nto others (and thus it always prunes empty directories).\n\nOne often would like to use '-kv' with 'cvs export'. This causes any\nkeywords to be expanded such that an import done at some other site will\nnot lose the keyword revision information. But be aware that doesn't\nhandle an export containing binary files correctly. Also be aware that\nafter having used '-kv', one can no longer use the 'ident' command\n(which is part of the RCS suite--see ident(1)) which looks for keyword\nstrings. If you want to be able to use 'ident' you must not use '-kv'.\n\n* Menu:\n\n* export options:: export options\n", "subsections": [] }, "File: cvs.info, Node: export options, Up: export": { "content": "These standard options are supported by 'export' (*note Common\noptions::, for a complete description of them):\n\n'-D DATE'\nUse the most recent revision no later than DATE.\n\n'-f'\nIf no matching revision is found, retrieve the most recent revision\n(instead of ignoring the file).\n\n'-l'\nLocal; run only in current working directory.\n\n'-n'\nDo not run any checkout program.\n\n'-R'\nExport directories recursively. This is on by default.\n\n'-r TAG[:DATE]'\nExport the revision specified by TAG or, when DATE is specified and\nTAG is a branch tag, the version from the branch TAG as it existed\non DATE. See *note Common options::.\n\nIn addition, these options (that are common to 'checkout' and\n'export') are also supported:\n\n'-d DIR'\nCreate a directory called DIR for the working files, instead of\nusing the module name. *Note checkout options::, for complete\ndetails on how CVS handles this flag.\n\n'-k SUBST'\nSet keyword expansion mode (*note Substitution modes::).\n\n'-N'\nOnly useful together with '-d DIR'. *Note checkout options::, for\ncomplete details on how CVS handles this flag.\n", "subsections": [] }, "File: cvs.info, Node: history, Next: import, Prev: export, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.13 history--Show repository access history", "content": "* Synopsis: history [-report] [-flags] [-options args] [files...]\n* Requires: the file '$CVSROOT/CVSROOT/history'\n* Changes: nothing.\n\nCVS can keep a history log that tracks each use of most CVS commands.\nYou can use 'history' to display this information in various formats.\n\nTo enable logging, the 'LogHistory' config option must be set to some\nvalue other than the empty string and the history file specified by the\n'HistoryLogPath' option must be writable by all users who may run the\nCVS executable (*note config::).\n\nTo enable the 'history' command, logging must be enabled as above and\nthe 'HistorySearchPath' config option (*note config::) must be set to\nspecify some number of the history logs created thereby and these files\nmust be readable by each user who might run the 'history' command.\n\nCreating a repository via the 'cvs init' command will enable logging\nof all possible events to a single history log file\n('$CVSROOT/CVSROOT/history') with read and write permissions for all\nusers (*note Creating a repository::).\n\nNote: 'history' uses '-f', '-l', '-n', and '-p' in ways that\nconflict with the normal use inside CVS (*note Common options::).\n\n* Menu:\n\n* history options:: history options\n" } ] }, "File: cvs.info, Node: history options, Up: history": { "content": "", "subsections": [] }, "Several options (shown above as '-report') control what kind of report": { "content": "is generated:\n\n'-c'\nReport on each time commit was used (i.e., each time the repository\nwas modified).\n\n'-e'\nEverything (all record types). Equivalent to specifying '-x' with\nall record types. Of course, '-e' will also include record types\nwhich are added in a future version of CVS; if you are writing a\nscript which can only handle certain record types, you'll want to\nspecify '-x'.\n\n'-m MODULE'\nReport on a particular module. (You can meaningfully use '-m' more\nthan once on the command line.)\n\n'-o'\nReport on checked-out modules. This is the default report type.\n\n'-T'\nReport on all tags.\n\n'-x TYPE'\nExtract a particular set of record types TYPE from the CVS history.\nThe types are indicated by single letters, which you may specify in\ncombination.\n\nCertain commands have a single record type:\n\n'F'\nrelease\n'O'\ncheckout\n'E'\nexport\n'T'\nrtag\n\nOne of five record types may result from an update:\n\n'C'\nA merge was necessary but collisions were detected (requiring\nmanual merging).\n'G'\nA merge was necessary and it succeeded.\n'U'\nA working file was copied from the repository.\n'P'\nA working file was patched to match the repository.\n'W'\nThe working copy of a file was deleted during update (because\nit was gone from the repository).\n\nOne of three record types results from commit:\n\n'A'\nA file was added for the first time.\n'M'\nA file was modified.\n'R'\nA file was removed.\n\nThe options shown as '-flags' constrain or expand the report without\nrequiring option arguments:\n\n'-a'\nShow data for all users (the default is to show data only for the\nuser executing 'history').\n\n'-l'\nShow last modification only.\n\n'-w'\nShow only the records for modifications done from the same working\ndirectory where 'history' is executing.\n\nThe options shown as '-options ARGS' constrain the report based on an\nargument:\n\n'-b STR'\nShow data back to a record containing the string STR in either the\nmodule name, the file name, or the repository path.\n\n'-D DATE'\nShow data since DATE. This is slightly different from the normal\nuse of '-D DATE', which selects the newest revision older than\nDATE.\n\n'-f FILE'\nShow data for a particular file (you can specify several '-f'\noptions on the same command line). This is equivalent to\nspecifying the file on the command line.\n\n'-n MODULE'\nShow data for a particular module (you can specify several '-n'\noptions on the same command line).\n\n'-p REPOSITORY'\nShow data for a particular source repository (you can specify\nseveral '-p' options on the same command line).\n\n'-r REV'\nShow records referring to revisions since the revision or tag named\nREV appears in individual RCS files. Each RCS file is searched for\nthe revision or tag.\n\n'-t TAG'\nShow records since tag TAG was last added to the history file.\nThis differs from the '-r' flag above in that it reads only the\nhistory file, not the RCS files, and is much faster.\n\n'-u NAME'\nShow records for user NAME.\n\n'-z TIMEZONE'\nShow times in the selected records using the specified time zone\ninstead of UTC.\n", "subsections": [] }, "File: cvs.info, Node: import, Next: log, Prev: history, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.14 import--Import sources into CVS, using vendor branches", "content": "* Synopsis: import [-options] repository vendortag releasetag...\n* Requires: Repository, source distribution directory.\n* Changes: repository.\n\nUse 'import' to incorporate an entire source distribution from an\noutside source (e.g., a source vendor) into your source repository\ndirectory. You can use this command both for initial creation of a\nrepository, and for wholesale updates to the module from the outside\nsource. *Note Tracking sources::, for a discussion on this subject.\n\nThe REPOSITORY argument gives a directory name (or a path to a\ndirectory) under the CVS root directory for repositories; if the\ndirectory did not exist, import creates it.\n\nWhen you use import for updates to source that has been modified in\nyour source repository (since a prior import), it will notify you of any\nfiles that conflict in the two branches of development; use 'checkout\n-j' to reconcile the differences, as import instructs you to do.\n\nIf CVS decides a file should be ignored (*note cvsignore::), it does\nnot import it and prints 'I ' followed by the filename (*note import\noutput::, for a complete description of the output).\n\nIf the file '$CVSROOT/CVSROOT/cvswrappers' exists, any file whose\nnames match the specifications in that file will be treated as packages\nand the appropriate filtering will be performed on the file/directory\nbefore being imported. *Note Wrappers::.\n\nThe outside source is saved in a first-level branch, by default\n1.1.1. Updates are leaves of this branch; for example, files from the\nfirst imported collection of source will be revision 1.1.1.1, then files\nfrom the first imported update will be revision 1.1.1.2, and so on.\n\nAt least three arguments are required. REPOSITORY is needed to\nidentify the collection of source. VENDORTAG is a tag for the entire\nbranch (e.g., for 1.1.1). You must also specify at least one RELEASETAG\nto uniquely identify the files at the leaves created each time you\nexecute 'import'. The RELEASETAG should be new, not previously existing\nin the repository file, and uniquely identify the imported release,\n\nNote that 'import' does not change the directory in which you\ninvoke it. In particular, it does not set up that directory as a CVS\nworking directory; if you want to work with the sources import them\nfirst and then check them out into a different directory (*note Getting\nthe source::).\n\n* Menu:\n\n* import options:: import options\n* import output:: import output\n* import examples:: import examples\n" } ] }, "File: cvs.info, Node: import options, Next: import output, Up: import": { "content": "This standard option is supported by 'import' (*note Common options::,\nfor a complete description):\n\n'-m MESSAGE'\nUse MESSAGE as log information, instead of invoking an editor.\n\nThere are the following additional special options.\n\n'-b BRANCH'\nSee *note Multiple vendor branches::.\n\n'-k SUBST'\nIndicate the keyword expansion mode desired. This setting will\napply to all files created during the import, but not to any files\nthat previously existed in the repository. See *note Substitution\nmodes::, for a list of valid '-k' settings.\n\n'-I NAME'\nSpecify file names that should be ignored during import. You can\nuse this option repeatedly. To avoid ignoring any files at all\n(even those ignored by default), specify '-I !'.\n\nNAME can be a file name pattern of the same type that you can\nspecify in the '.cvsignore' file. *Note cvsignore::.\n\n'-W SPEC'\nSpecify file names that should be filtered during import. You can\nuse this option repeatedly.\n\nSPEC can be a file name pattern of the same type that you can\nspecify in the '.cvswrappers' file. *Note Wrappers::.\n\n'-X'\nModify the algorithm used by CVS when importing new files so that\nnew files do not immediately appear on the main trunk.\n\nSpecifically, this flag causes CVS to mark new files as if they\nwere deleted on the main trunk, by taking the following steps for\neach file in addition to those normally taken on import: creating a\nnew revision on the main trunk indicating that the new file is\n'dead', resetting the new file's default branch, and placing the\nfile in the Attic (*note Attic::) directory.\n\nSetting the 'ImportNewFilesToVendorBranchOnly' option in\nCVSROOT/config (*note config::) forces use of this option on a\nrepository-wide basis.\n", "subsections": [] }, "File: cvs.info, Node: import output, Next: import examples, Prev: import options, Up: import": { "content": "'import' keeps you informed of its progress by printing a line for each\nfile, preceded by one character indicating the status of the file:\n\n'U FILE'\nThe file already exists in the repository and has not been locally\nmodified; a new revision has been created (if necessary).\n\n'N FILE'\nThe file is a new file which has been added to the repository.\n\n'C FILE'\nThe file already exists in the repository but has been locally\nmodified; you will have to merge the changes.\n\n'I FILE'\nThe file is being ignored (*note cvsignore::).\n\n'L FILE'\nThe file is a symbolic link; 'cvs import' ignores symbolic links.\nPeople periodically suggest that this behavior should be changed,\nbut if there is a consensus on what it should be changed to, it is\nnot apparent. (Various options in the 'modules' file can be used\nto recreate symbolic links on checkout, update, etc.; *note\nmodules::.)\n", "subsections": [] }, "File: cvs.info, Node: import examples, Prev: import output, Up: import": { "content": "See *note Tracking sources::, and *note From files::.\n\nFile: cvs.info, Node: log, Next: ls & rls, Prev: import, Up: CVS commands\n", "subsections": [ { "name": "A.15 log--Print out history information for files", "content": "* Synopsis: log [options] [files...]\n\nrlog [options] [files...]\n* Requires: repository, working directory.\n* Changes: nothing.\n\nDisplay log information for files. 'log' used to call the RCS\nutility 'rlog'. Although this is no longer true in the current sources,\nthis history determines the format of the output and the options, which\nare not quite in the style of the other CVS commands.\n\nThe output includes the location of the RCS file, the \"head\" revision\n(the latest revision on the trunk), all symbolic names (tags) and some\nother things. For each revision, the revision number, the date, the\nauthor, the number of lines added/deleted, the commitid and the log\nmessage are printed. All dates are displayed in local time at the\nclient. This is typically specified in the '$TZ' environment variable,\nwhich can be set to govern how 'log' displays dates.\n\nNote: 'log' uses '-R' in a way that conflicts with the normal use\ninside CVS (*note Common options::).\n\n* Menu:\n\n* log options:: log options\n* log examples:: log examples\n" } ] }, "File: cvs.info, Node: log options, Next: log examples, Up: log": { "content": "", "subsections": [] }, "By default, 'log' prints all information that is available. All other": { "content": "options restrict the output. Note that the revision selection options\n('-d', '-r', '-s', and '-w') have no effect, other than possibly causing\na search for files in Attic directories, when used in conjunction with\nthe options that restrict the output to only 'log' header fields ('-b',\n'-h', '-R', and '-t') unless the '-S' option is also specified.\n\n'-b'\nPrint information about the revisions on the default branch,\nnormally the highest branch on the trunk.\n\n'-d DATES'\nPrint information about revisions with a checkin date/time in the\nrange given by the semicolon-separated list of dates. The date\nformats accepted are those accepted by the '-D' option to many\nother CVS commands (*note Common options::). Dates can be combined\ninto ranges as follows:\n\n'D1D1'\nSelect the revisions that were deposited between D1 and D2.\n\n''\nSelect all revisions dated D or earlier.\n\n'D<'\n'>D'\nSelect all revisions dated D or later.\n\n'D'\nSelect the single, latest revision dated D or earlier.\n\nThe '>' or '<' characters may be followed by '=' to indicate an\ninclusive range rather than an exclusive one.\n\nNote that the separator is a semicolon (;).\n\n'-h'\nPrint only the name of the RCS file, name of the file in the\nworking directory, head, default branch, access list, locks,\nsymbolic names, and suffix.\n\n'-l'\nLocal; run only in current working directory. (Default is to run\nrecursively).\n\n'-N'\nDo not print the list of tags for this file. This option can be\nvery useful when your site uses a lot of tags, so rather than\n\"more\"'ing over 3 pages of tag information, the log information is\npresented without tags at all.\n\n'-R'\nPrint only the name of the RCS file.\n\n'-rREVISIONS'\nPrint information about revisions given in the comma-separated list\nREVISIONS of revisions and ranges. The following table explains\nthe available range formats:\n\n'REV1:REV2'\nRevisions REV1 to REV2 (which must be on the same branch).\n\n'REV1::REV2'\nThe same, but excluding REV1.\n\n':REV'\n'::REV'\nRevisions from the beginning of the branch up to and including\nREV.\n\n'REV:'\nRevisions starting with REV to the end of the branch\ncontaining REV.\n\n'REV::'\nRevisions starting just after REV to the end of the branch\ncontaining REV.\n\n'BRANCH'\nAn argument that is a branch means all revisions on that\nbranch.\n\n'BRANCH1:BRANCH2'\n'BRANCH1::BRANCH2'\nA range of branches means all revisions on the branches in\nthat range.\n\n'BRANCH.'\nThe latest revision in BRANCH.\n\nA bare '-r' with no revisions means the latest revision on the\ndefault branch, normally the trunk. There can be no space between\nthe '-r' option and its argument.\n\n'-S'\nSuppress the header if no revisions are selected.\n\n'-s STATES'\nPrint information about revisions whose state attributes match one\nof the states given in the comma-separated list STATES. Individual\nstates may be any text string, though CVS commonly only uses two\nstates, 'Exp' and 'dead'. See *note admin options:: for more\ninformation.\n\n'-t'\nPrint the same as '-h', plus the descriptive text.\n\n'-wLOGINS'\nPrint information about revisions checked in by users with login\nnames appearing in the comma-separated list LOGINS. If LOGINS is\nomitted, the user's login is assumed. There can be no space\nbetween the '-w' option and its argument.\n\n'log' prints the intersection of the revisions selected with the\noptions '-d', '-s', and '-w', intersected with the union of the\nrevisions selected by '-b' and '-r'.\n", "subsections": [] }, "File: cvs.info, Node: log examples, Prev: log options, Up: log": { "content": "", "subsections": [] }, "Since 'log' shows dates in local time, you might want to see them in": { "content": "", "subsections": [] }, "Coordinated Universal Time (UTC) or some other timezone. To do this you": { "content": "can set your '$TZ' environment variable before invoking CVS:\n\n$ TZ=UTC cvs log foo.c\n$ TZ=EST cvs log bar.c\n\n(If you are using a 'csh'-style shell, like 'tcsh', you would need to\nprefix the examples above with 'env'.)\n\nFile: cvs.info, Node: ls & rls, Next: rdiff, Prev: log, Up: CVS commands\n", "subsections": [ { "name": "A.16 ls & rls--List files in the repository", "content": "* ls [-e | -l] [-RP] [-r tag[:date]] [-D date] [path...]\n\nrls [-e | -l] [-RP] [-r tag[:date]] [-D date] [path...]\n* Requires: repository for 'rls', repository & working directory for\n'ls'.\n* Changes: nothing.\n* Synonym: 'dir' & 'list' are synonyms for 'ls' and 'rdir' & 'rlist'\nare synonyms for 'rls'.\n\nThe 'ls' and 'rls' commands are used to list files and directories in\nthe repository.\n\nBy default 'ls' lists the files and directories that belong in your\nworking directory, what would be there after an 'update'.\n\nBy default 'rls' lists the files and directories on the tip of the\ntrunk in the topmost directory of the repository.\n\nBoth commands accept an optional list of file and directory names,\nrelative to the working directory for 'ls' and the topmost directory of\nthe repository for 'rls'. Neither is recursive by default.\n\n* Menu:\n\n* ls & rls options:: ls & rls options\n* rls examples: rls examples\n\nFile: cvs.info, Node: ls & rls options, Next: rls examples, Up: ls & rls\n\n\nThese standard options are supported by 'ls' & 'rls':\n\n'-d'\nShow dead revisions (with tag when specified).\n\n'-e'\nDisplay in CVS/Entries format. This format is meant to remain\neasily parsable by automation.\n\n'-l'\nDisplay all details.\n\n'-P'\nDon't list contents of empty directories when recursing.\n\n'-R'\nList recursively.\n\n'-r TAG[:DATE]'\nShow files specified by TAG or, when DATE is specified and TAG is a\nbranch tag, the version from the branch TAG as it existed on DATE.\nSee *note Common options::.\n\n'-D DATE'\nShow files from date.\n\nFile: cvs.info, Node: rls examples, Prev: ls & rls options, Up: ls & rls\n\n\n$ cvs rls\ncvs rls: Listing module: `.'\nCVSROOT\nfirst-dir\n\n$ cvs rls CVSROOT\ncvs rls: Listing module: `CVSROOT'\ncheckoutlist\ncommitinfo\nconfig\ncvswrappers\nloginfo\nmodules\nnotify\nrcsinfo\ntaginfo\nverifymsg\n\n\nFile: cvs.info, Node: rdiff, Next: release, Prev: ls & rls, Up: CVS commands\n" }, { "name": "A.17 rdiff--Create 'patch' format diffs between revisions", "content": "* rdiff [-flags] [-V vn] (-r tag1[:date1] | -D date1) [-r\ntag2[:date2] | -D date2] modules...\n* Requires: repository.\n* Changes: nothing.\n* Synonym: patch\n\nBuilds a Larry Wall format patch(1) file between two releases, that\ncan be fed directly into the 'patch' program to bring an old release\nup-to-date with the new release. (This is one of the few CVS commands\nthat operates directly from the repository, and doesn't require a prior\ncheckout.) The diff output is sent to the standard output device.\n\nYou can specify (using the standard '-r' and '-D' options) any\ncombination of one or two revisions or dates. If only one revision or\ndate is specified, the patch file reflects differences between that\nrevision or date and the current head revisions in the RCS file.\n\nNote that if the software release affected is contained in more than\none directory, then it may be necessary to specify the '-p' option to\nthe 'patch' command when patching the old sources, so that 'patch' is\nable to find the files that are located in other directories.\n\n* Menu:\n\n* rdiff options:: rdiff options\n* rdiff examples:: rdiff examples\n" } ] }, "File: cvs.info, Node: rdiff options, Next: rdiff examples, Up: rdiff": { "content": "These standard options are supported by 'rdiff' (*note Common options::,\nfor a complete description of them):\n\n'-D DATE'\nUse the most recent revision no later than DATE.\n\n'-f'\nIf no matching revision is found, retrieve the most recent revision\n(instead of ignoring the file).\n\n'-k KFLAG'\nProcess keywords according to KFLAG. See *note Keyword\nsubstitution::.\n\n'-l'\nLocal; don't descend subdirectories.\n\n'-R'\nExamine directories recursively. This option is on by default.\n\n'-r TAG'\nUse the revision specified by TAG, or when DATE is specified and\nTAG is a branch tag, the version from the branch TAG as it existed\non DATE. See *note Common options::.\n\nIn addition to the above, these options are available:\n\n'-c'\nUse the context diff format. This is the default format.\n\n'-p'\nShow which C function each change is in.\n\n'-s'\nCreate a summary change report instead of a patch. The summary\nincludes information about files that were changed or added between\nthe releases. It is sent to the standard output device. This is\nuseful for finding out, for example, which files have changed\nbetween two dates or revisions.\n\n'-t'\nA diff of the top two revisions is sent to the standard output\ndevice. This is most useful for seeing what the last change to a\nfile was.\n\n'-u'\nUse the unidiff format for the context diffs. Remember that old\nversions of the 'patch' program can't handle the unidiff format, so\nif you plan to post this patch to the net you should probably not\nuse '-u'.\n\n'-V VN'\nExpand keywords according to the rules current in RCS version VN\n(the expansion format changed with RCS version 5). Note that this\noption is no longer accepted. CVS will always expand keywords the\nway that RCS version 5 does.\n", "subsections": [] }, "File: cvs.info, Node: rdiff examples, Prev: rdiff options, Up: rdiff": { "content": "Suppose you receive mail from foo@example.net asking for an update from\nrelease 1.2 to 1.4 of the tc compiler. You have no such patches on\nhand, but with CVS that can easily be fixed with a command such as this:\n\n$ cvs rdiff -c -r FOO12 -r FOO14 tc | \\\n$$ Mail -s 'The patches you asked for' foo@example.net\n\nSuppose you have made release 1.3, and forked a branch called\n'R13fix' for bug fixes. 'R131' corresponds to release 1.3.1, which\nwas made some time ago. Now, you want to see how much development has\nbeen done on the branch. This command can be used:\n\n$ cvs patch -s -r R131 -r R13fix module-name\ncvs rdiff: Diffing module-name\nFile ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6\nFile foo.c,v changed from revision 1.52.2.3 to 1.52.2.4\nFile bar.h,v changed from revision 1.29.2.1 to 1.2\n\nFile: cvs.info, Node: release, Next: server & pserver, Prev: rdiff, Up: CVS commands\n", "subsections": [ { "name": "A.18 release--Indicate that a directory is no longer in use", "content": "* release [-d] directories...\n* Requires: Working directory.\n* Changes: Working directory, history log.\n\nThis command is meant to safely cancel the effect of 'cvs checkout'." } ] }, "Since CVS doesn't lock files, it isn't strictly necessary to use this": { "content": "command. You can always simply delete your working directory, if you\nlike; but you risk losing changes you may have forgotten, and you leave\nno trace in the CVS history file (*note history file::) that you've\nabandoned your checkout.\n\nUse 'cvs release' to avoid these problems. This command checks that\nno uncommitted changes are present; that you are executing it from\nimmediately above a CVS working directory; and that the repository\nrecorded for your files is the same as the repository defined in the\nmodule database.\n\nIf all these conditions are true, 'cvs release' leaves a record of\nits execution (attesting to your intentionally abandoning your checkout)\nin the CVS history log.\n\n* Menu:\n\n* release options:: release options\n* release output:: release output\n* release examples:: release examples\n", "subsections": [] }, "File: cvs.info, Node: release options, Next: release output, Up: release": { "content": "The 'release' command supports one command option:\n\n'-d'\nDelete your working copy of the file if the release succeeds. If\nthis flag is not given your files will remain in your working\ndirectory.\n\nWARNING: The 'release' command deletes all directories and files\nrecursively. This has the very serious side-effect that any\ndirectory that you have created inside your checked-out sources,\nand not added to the repository (using the 'add' command; *note\nAdding files::) will be silently deleted--even if it is non-empty!\n", "subsections": [] }, "File: cvs.info, Node: release output, Next: release examples, Prev: release options, Up: release": { "content": "", "subsections": [] }, "Before 'release' releases your sources it will print a one-line message": { "content": "for any file that is not up-to-date.\n\n'U FILE'\n'P FILE'\nThere exists a newer revision of this file in the repository, and\nyou have not modified your local copy of the file ('U' and 'P' mean\nthe same thing).\n\n'A FILE'\nThe file has been added to your private copy of the sources, but\nhas not yet been committed to the repository. If you delete your\ncopy of the sources this file will be lost.\n\n'R FILE'\nThe file has been removed from your private copy of the sources,\nbut has not yet been removed from the repository, since you have\nnot yet committed the removal. *Note commit::.\n\n'M FILE'\nThe file is modified in your working directory. There might also\nbe a newer revision inside the repository.\n\n'? FILE'\nFILE is in your working directory, but does not correspond to\nanything in the source repository, and is not in the list of files\nfor CVS to ignore (see the description of the '-I' option, and\n*note cvsignore::). If you remove your working sources, this file\nwill be lost.\n", "subsections": [] }, "File: cvs.info, Node: release examples, Prev: release output, Up: release": { "content": "", "subsections": [] }, "Release the 'tc' directory, and delete your local working copy of the": { "content": "files.\n\n$ cd .. # You must stand immediately above the\n# sources when you issue 'cvs release'.\n$ cvs release -d tc\nYou have [0] altered files in this repository.\nAre you sure you want to release (and delete) directory `tc': y\n$\n\nFile: cvs.info, Node: server & pserver, Next: suck, Prev: release, Up: CVS commands\n", "subsections": [ { "name": "A.19 server & pserver--Act as a server for a client on stdin/stdout", "content": "* pserver [-c path]\n\nserver [-c path]\n* Requires: repository, client conversation on stdin/stdout\n* Changes: Repository or, indirectly, client working directory.\n\nThe CVS 'server' and 'pserver' commands are used to provide\nrepository access to remote clients and expect a client conversation on\nstdin & stdout. Typically these commands are launched from 'inetd' or\nvia 'ssh' (*note Remote repositories::).\n\n'server' expects that the client has already been authenticated\nsomehow, typically via SSH, and 'pserver' attempts to authenticate the\nclient itself.\n\nOnly one option is available with the 'server' and 'pserver'\ncommands:\n\n'-c path'\nLoad configuration from the given PATH rather than from the default\nlocation '$CVSROOT/CVSROOT/config' (*note config::). PATH must be\n'/etc/cvs.conf' or prefixed by '/etc/cvs/'. This option is\nsupported beginning with CVS release 1.12.13.\n\nFile: cvs.info, Node: suck, Next: update, Prev: server & pserver, Up: CVS commands\n" }, { "name": "A.20 suck--Download RCS ,v file raw", "content": "* suck module/pa/th\n* Requires: repository\n\nLocates the file module/pa/th,v or module/pa/Attic/th,v and downloads\nit raw as RCS comma-v file.\n\nOutput consists of the real pathname of the comma-v file, relative to\nthe CVS repository, followed by a newline and the binary file content\nimmediately thereafter.\n" } ] }, "File: cvs.info, Node: update, Prev: suck, Up: CVS commands": { "content": "", "subsections": [ { "name": "A.21 update--Bring work tree in sync with repository", "content": "* update [-ACdflPpR] [-I name] [-j rev [-j rev]] [-k kflag] [-r\ntag[:date] | -D date] [-W spec] files...\n* Requires: repository, working directory.\n* Changes: working directory.\n\nAfter you've run checkout to create your private copy of source from\nthe common repository, other developers will continue changing the\ncentral source. From time to time, when it is convenient in your\ndevelopment process, you can use the 'update' command from within your\nworking directory to reconcile your work with any revisions applied to\nthe source repository since your last checkout or update. Without the\n'-C' option, 'update' will also merge any differences between the local\ncopy of files and their base revisions into any destination revisions\nspecified with '-r', '-D', or '-A'.\n\n* Menu:\n\n* update options:: update options\n* update output:: update output\n" } ] }, "File: cvs.info, Node: update options, Next: update output, Up: update": { "content": "These standard options are available with 'update' (*note Common\noptions::, for a complete description of them):\n\n'-D date'\nUse the most recent revision no later than DATE. This option is\nsticky, and implies '-P'. See *note Sticky tags::, for more\ninformation on sticky tags/dates.\n\n'-f'\nOnly useful with the '-D' or '-r' flags. If no matching revision\nis found, retrieve the most recent revision (instead of ignoring\nthe file).\n\n'-k KFLAG'\nProcess keywords according to KFLAG. See *note Keyword\nsubstitution::. This option is sticky; future updates of this file\nin this working directory will use the same KFLAG. The 'status'\ncommand can be viewed to see the sticky options. See *note\nInvoking CVS::, for more information on the 'status' command.\n\n'-l'\nLocal; run only in current working directory. *Note Recursive\nbehavior::.\n\n'-P'\nPrune empty directories. See *note Moving directories::.\n\n'-p'\nPipe files to the standard output.\n\n'-R'\nUpdate directories recursively (default). *Note Recursive\nbehavior::.\n\n'-r TAG[:DATE]'\nRetrieve the revisions specified by TAG or, when DATE is specified\nand TAG is a branch tag, the version from the branch TAG as it\nexisted on DATE. This option is sticky, and implies '-P'. See\n*note Sticky tags::, for more information on sticky tags/dates.\nAlso see *note Common options::.\n\nThese special options are also available with 'update'.\n\n'-A'\nReset any sticky tags, dates, or '-k' options. See *note Sticky\ntags::, for more information on sticky tags/dates.\n\n'-C'\nOverwrite locally modified files with clean copies from the\nrepository (the modified file is saved in '.#FILE.REVISION',\nhowever).\n\n'-d'\nCreate any directories that exist in the repository if they're\nmissing from the working directory. Normally, 'update' acts only\non directories and files that were already enrolled in your working\ndirectory.\n\nThis is useful for updating directories that were created in the\nrepository since the initial checkout; but it has an unfortunate\nside effect. If you deliberately avoided certain directories in\nthe repository when you created your working directory (either\nthrough use of a module name or by listing explicitly the files and\ndirectories you wanted on the command line), then updating with\n'-d' will create those directories, which may not be what you want.\n\n'-I NAME'\nIgnore files whose names match NAME (in your working directory)\nduring the update. You can specify '-I' more than once on the\ncommand line to specify several files to ignore. Use '-I !' to\navoid ignoring any files at all. *Note cvsignore::, for other ways\nto make CVS ignore some files.\n\n'-WSPEC'\nSpecify file names that should be filtered during update. You can\nuse this option repeatedly.\n\nSPEC can be a file name pattern of the same type that you can\nspecify in the '.cvswrappers' file. *Note Wrappers::.\n\n'-jREVISION'\nWith two '-j' options, merge changes from the revision specified\nwith the first '-j' option to the revision specified with the\nsecond 'j' option, into the working directory.\n\nWith one '-j' option, merge changes from the ancestor revision to\nthe revision specified with the '-j' option, into the working\ndirectory. The ancestor revision is the common ancestor of the\nrevision which the working directory is based on, and the revision\nspecified in the '-j' option.\n\nNote that using a single '-j TAGNAME' option rather than '-j\nBRANCHNAME' to merge changes from a branch will often not remove\nfiles which were removed on the branch. *Note Merging adds and\nremovals::, for more.\n\nIn addition, each '-j' option can contain an optional date\nspecification which, when used with branches, can limit the chosen\nrevision to one within a specific date. An optional date is\nspecified by adding a colon (:) to the tag:\n'-jSYMBOLICTAG:DATESPECIFIER'.\n\n*Note Branching and merging::.\n", "subsections": [] }, "File: cvs.info, Node: update output, Prev: update options, Up: update": { "content": "'update' and 'checkout' keep you informed of their progress by printing\na line for each file, preceded by one character indicating the status of\nthe file:\n\n'U FILE'\nThe file was brought up to date with respect to the repository.\nThis is done for any file that exists in the repository but not in\nyour working directory, and for files that you haven't changed but\nare not the most recent versions available in the repository.\n\n'P FILE'\nLike 'U', but the CVS server sends a patch instead of an entire\nfile. This accomplishes the same thing as 'U' using less\nbandwidth.\n\n'A FILE'\nThe file has been added to your private copy of the sources, and\nwill be added to the source repository when you run 'commit' on the\nfile. This is a reminder to you that the file needs to be\ncommitted.\n\n'R FILE'\nThe file has been removed from your private copy of the sources,\nand will be removed from the source repository when you run\n'commit' on the file. This is a reminder to you that the file\nneeds to be committed.\n\n'M FILE'\nThe file is modified in your working directory.\n\n'M' can indicate one of two states for a file you're working on:\neither there were no modifications to the same file in the\nrepository, so that your file remains as you last saw it; or there\nwere modifications in the repository as well as in your copy, but\nthey were merged successfully, without conflict, in your working\ndirectory.\n\nCVS will print some messages if it merges your work, and a backup\ncopy of your working file (as it looked before you ran 'update')\nwill be made. The exact name of that file is printed while\n'update' runs.\n\n'C FILE'\nA conflict was detected while trying to merge your changes to FILE\nwith changes from the source repository. FILE (the copy in your\nworking directory) is now the result of attempting to merge the two\nrevisions; an unmodified copy of your file is also in your working\ndirectory, with the name '.#FILE.REVISION' where REVISION is the\nrevision that your modified file started from. Resolve the\nconflict as described in *note Conflicts example::. (Note that\nsome systems automatically purge files that begin with '.#' if they\nhave not been accessed for a few days. If you intend to keep a\ncopy of your original file, it is a very good idea to rename it.)\nUnder VMS, the file name starts with '' rather than '.#'.\n\n'? FILE'\nFILE is in your working directory, but does not correspond to\nanything in the source repository, and is not in the list of files\nfor CVS to ignore (see the description of the '-I' option, and\n*note cvsignore::).\n", "subsections": [] }, "File: cvs.info, Node: Invoking CVS, Next: Administrative files, Prev: CVS commands, Up: Top": { "content": "", "subsections": [] }, "Appendix B Quick reference to CVS commands": { "content": "", "subsections": [] }, "This appendix describes how to invoke CVS, with references to where each": { "content": "command or feature is described in detail. For other references run the\n'cvs --help' command, or see *note Index::. For an alphabetical list of\nall CVS commands, *note CVS command list::).\n\nA CVS command looks like:\n\ncvs [ GLOBALOPTIONS ] COMMAND [ COMMANDOPTIONS ] [ COMMANDARGS ]\n\nGlobal options:\n\n'--allow-root=ROOTDIR'\nSpecify acceptable CVSROOT directory (server only). Appeared in\nCVS 1.10. See *note Password authentication server::.\n\n'--allow-root-regexp=ROOTDIR'\nSpecify a POSIX extended regular expression which matches\nacceptable CVSROOT directories (server only). Appeared in CVS\n1.12.14. See *note Password authentication server::.\n\n'-a'\nAuthenticate all communication (client only) (not in CVS 1.9 and\nolder). See *note Global options::.\n\n'-b'\nSpecify RCS location (CVS 1.9 and older). See *note Global\noptions::.\n\n'-d ROOT'\nSpecify the CVSROOT. See *note Repository::.\n\n'-e EDITOR'\nEdit messages with EDITOR. See *note Committing your changes::.\n\n'-f'\nDo not read the '~/.cvsrc' file. See *note Global options::.\n\n'-g'\nSet the umask to allow group writable permissions in the working\ncopy. See *note Global options::.\n\n'-H'\n'--help'\nPrint a help message. See *note Global options::.\n\n'-n'\nDo not change any files. See *note Global options::.\n\n'-Q'\nBe really quiet. See *note Global options::.\n\n'-q'\nBe somewhat quiet. See *note Global options::.\n\n'-r'\nMake new working files read-only. See *note Global options::.\n\n'-s VARIABLE=VALUE'\nSet a user variable. See *note Variables::.\n\n'-T TEMPDIR'\nPut temporary files in TEMPDIR. See *note Global options::.\n\n'-t'\nTrace CVS execution. See *note Global options::.\n\n'-v'\n'--version'\nDisplay version and copyright information for CVS.\n\n'-w'\nMake new working files read-write. See *note Global options::.\n\n'-x'\nEncrypt all communication (client only). See *note Global\noptions::.\n\n'-z GZIP-LEVEL'\nSet the compression level (client only). See *note Global\noptions::.\n\nKeyword expansion modes (*note Substitution modes::):\n\n-kkv $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $\n-kkvl $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $\n-kk $Id$\n-kv file1,v 1.1 1993/12/09 03:21:13 joe Exp\n-ko no expansion\n-kb no expansion, file is binary\n\nKeywords (*note Keyword list::):\n\n$Author: joe $\n$Date: 1993/12/09 03:21:13 $\n$Mdocdate: December 9 1993 $\n$CVSHeader: files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $\n$Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $\n$Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $\n$Locker: harry $\n$Name: snapshot114 $\n$RCSfile: file1,v $\n$Revision: 1.1 $\n$Source: /home/files/file1,v $\n$State: Exp $\n$Log: file1,v $\nRevision 1.1 1993/12/09 03:30:17 joe\nInitial revision\n\n\nCommands, command options, and command arguments:\n\n'add [OPTIONS] [FILES...]'\nAdd a new file/directory. See *note Adding files::.\n\n'-k KFLAG'\nSet keyword expansion.\n\n'-m MSG'\nSet file description.\n\n'admin [OPTIONS] [FILES...]'\nAdministration of history files in the repository. See *note\nadmin::.\n\n'-b[REV]'\nSet default branch. See *note Reverting local changes::.\n\n'-cSTRING'\nSet comment leader.\n\n'-kSUBST'\nSet keyword substitution. See *note Keyword substitution::.\n\n'-l[REV]'\nLock revision REV, or latest revision.\n\n'-mREV:MSG'\nReplace the log message of revision REV with MSG.\n\n'-oRANGE'\nDelete revisions from the repository. See *note admin\noptions::.\n\n'-q'\nRun quietly; do not print diagnostics.\n\n'-sSTATE[:REV]'\nSet the state. See *note admin options:: for more information\non possible states.\n\n'-t'\nSet file description from standard input.\n\n'-tFILE'\nSet file description from FILE.\n\n'-t-STRING'\nSet file description to STRING.\n\n'-u[REV]'\nUnlock revision REV, or latest revision.\n\n'annotate [OPTIONS] [FILES...]'\nShow last revision where each line was modified. See *note\nannotate::.\n\n'-D DATE'\nAnnotate the most recent revision no later than DATE. See\n*note Common options::.\n\n'-F'\nForce annotation of binary files. (Without this option,\nbinary files are skipped with a message.)\n\n'-f'\nUse head revision if tag/date not found. See *note Common\noptions::.\n\n'-l'\nLocal; run only in current working directory. *Note Recursive\nbehavior::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'-r TAG[:DATE]'\nAnnotate revisions specified by TAG or, when DATE is specified\nand TAG is a branch tag, the version from the branch TAG as it\nexisted on DATE. See *note Common options::.\n\n'checkout [OPTIONS] MODULES...'\nGet a copy of the sources. See *note checkout::.\n\n'-A'\nReset any sticky tags/date/options. See *note Sticky tags::\nand *note Keyword substitution::.\n\n'-c'\nOutput the module database. See *note checkout options::.\n\n'-D DATE'\nCheck out revisions as of DATE (is sticky). See *note Common\noptions::.\n\n'-d DIR'\nCheck out into DIR. See *note checkout options::.\n\n'-f'\nUse head revision if tag/date not found. See *note Common\noptions::.\n\n'-j TAG[:DATE]'\nMerge in the change specified by TAG, or when DATE is\nspecified and TAG is a branch tag, the version from the branch\nTAG as it existed on DATE. See *note checkout options::.\nAlso, see *note Common options::.\n\n'-k KFLAG'\nUse KFLAG keyword expansion. See *note Substitution modes::.\n\n'-l'\nLocal; run only in current working directory. *Note Recursive\nbehavior::.\n\n'-N'\nDon't \"shorten\" module paths if -d specified. See *note\ncheckout options::.\n\n'-n'\nDo not run module program (if any). See *note checkout\noptions::.\n\n'-P'\nPrune empty directories. See *note Moving directories::.\n\n'-p'\nCheck out files to standard output (avoids stickiness). See\n*note checkout options::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'-r TAG[:DATE]'\nCheckout the revision already tagged with TAG or, when DATE is\nspecified and TAG is a branch tag, the version from the branch\nTAG as it existed on DATE. See *note Common options::.\n\n'-s'\nLike -c, but include module status. See *note checkout\noptions::.\n\n'commit [OPTIONS] [FILES...]'\nCheck changes into the repository. See *note commit::.\n\n'-c'\nCheck for valid edits before committing. Requires a CVS\nclient and server both version 1.12.10 or greater.\n\n'-F FILE'\nRead log message from FILE. See *note commit options::.\n\n'-f'\nForce the file to be committed; disables recursion. See *note\ncommit options::.\n\n'-l'\nLocal; run only in current working directory. See *note\nRecursive behavior::.\n\n'-m MSG'\nUse MSG as log message. See *note commit options::.\n\n'-n'\nDo not run module program (if any). See *note commit\noptions::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'-r REV'\nCommit to REV. See *note commit options::.\n\n'diff [OPTIONS] [FILES...]'\nShow differences between revisions. See *note diff::. In addition\nto the options shown below, accepts a wide variety of options to\ncontrol output style, for example '-c' for context diffs.\n\n'-D DATE1'\nDiff revision for date against working file. See *note diff\noptions::.\n\n'-D DATE2'\nDiff REV1/DATE1 against DATE2. See *note diff options::.\n\n'-l'\nLocal; run only in current working directory. See *note\nRecursive behavior::.\n\n'-N'\nInclude diffs for added and removed files. See *note diff\noptions::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'-r TAG1[:DATE1]'\nDiff the revisions specified by TAG1 or, when DATE1 is\nspecified and TAG1 is a branch tag, the version from the\nbranch TAG1 as it existed on DATE1, against the working file.\nSee *note diff options:: and *note Common options::.\n\n'-r TAG2[:DATE2]'\nDiff the revisions specified by TAG2 or, when DATE2 is\nspecified and TAG2 is a branch tag, the version from the\nbranch TAG2 as it existed on DATE2, against REV1/DATE1. See\n*note diff options:: and *note Common options::.\n\n'edit [OPTIONS] [FILES...]'\nGet ready to edit a watched file. See *note Editing files::.\n\n'-a ACTIONS'\nSpecify actions for temporary watch, where ACTIONS is 'edit',\n'unedit', 'commit', 'all', or 'none'. See *note Editing\nfiles::.\n\n'-c'\nCheck edits: Edit fails if someone else is already editing the\nfile. Requires a CVS client and server both of version\n1.12.10 or greater.\n\n'-f'\nForce edit; ignore other edits. Added in CVS 1.12.10.\n\n'-l'\nLocal; run only in current working directory. See *note\nRecursive behavior::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'editors [OPTIONS] [FILES...]'\nSee who is editing a watched file. See *note Watch information::.\n\n'-l'\nLocal; run only in current working directory. See *note\nRecursive behavior::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'export [OPTIONS] MODULES...'\nExport files from CVS. See *note export::.\n\n'-D DATE'\nCheck out revisions as of DATE. See *note Common options::.\n\n'-d DIR'\nCheck out into DIR. See *note export options::.\n\n'-f'\nUse head revision if tag/date not found. See *note Common\noptions::.\n\n'-k KFLAG'\nUse KFLAG keyword expansion. See *note Substitution modes::.\n\n'-l'\nLocal; run only in current working directory. *Note Recursive\nbehavior::.\n\n'-N'\nDon't \"shorten\" module paths if -d specified. See *note\nexport options::.\n\n'-n'\nDo not run module program (if any). See *note export\noptions::.\n\n'-R'\nOperate recursively (default). *Note Recursive behavior::.\n\n'-r TAG[:DATE]'\nExport the revisions specified by TAG or, when DATE is\nspecified and TAG is a branch tag, the version from the branch\nTAG as it existed on DATE. See *note Common options::.\n\n'history [OPTIONS] [FILES...]'\nShow repository access history. See *note history::.\n\n'-a'\nAll users (default is self). See *note history options::.\n\n'-b STR'\nBack to record with STR in module/file/repos field. See *note\nhistory options::.\n\n'-c'\nReport on committed (modified) files. See *note history\noptions::.\n\n'-D DATE'\nSince DATE. See *note history options::.\n\n'-e'\nReport on all record types. See *note history options::.\n\n'-l'\nLast modified (committed or modified report). See *note\nhistory options::.\n\n'-m MODULE'\nReport on MODULE (repeatable). See *note history options::.\n\n'-n MODULE'\nIn MODULE. See *note history options::.\n\n'-o'\nReport on checked out modules. See *note history options::.\n\n'-p REPOSITORY'\nIn REPOSITORY. See *note history options::.\n\n'-r REV'\nSince revision REV. See *note history options::.\n\n'-T'\nProduce report on all TAGs. See *note history options::.\n\n'-t TAG'\nSince tag record placed in history file (by anyone). See\n*note history options::.\n\n'-u USER'\nFor user USER (repeatable). See *note history options::.\n\n'-w'\nWorking directory must match. See *note history options::.\n\n'-x TYPES'\nReport on TYPES, one or more of 'TOEFWUPCGMAR'. See *note\nhistory options::.\n\n'-z ZONE'\nOutput for time zone ZONE. See *note history options::.\n\n'import [OPTIONS] REPOSITORY VENDOR-TAG RELEASE-TAGS...'\nImport files into CVS, using vendor branches. See *note import::.\n\n'-b BRA'\nImport to vendor branch BRA. See *note Multiple vendor\nbranches::.\n\n'-d'\nUse the file's modification time as the time of import. See\n*note import options::.\n\n'-k KFLAG'\nSet default keyword substitution mode. See *note import\noptions::.\n\n'-m MSG'\nUse MSG for log message. See *note import options::.\n\n'-I IGN'\nMore files to ignore (! to reset). See *note import\noptions::.\n\n'-W SPEC'\nMore wrappers. See *note import options::.\n\n'init'\nCreate a CVS repository if it doesn't exist. See *note Creating a\nrepository::.\n\n'kserver'\nKerberos authenticated server. *Note server & pserver::. *Note\nKerberos authenticated::.\n\n'log [OPTIONS] [FILES...]'\nPrint out history information for files. See *note log::.\n\n'-b'\nOnly list revisions on the default branch. See *note log\noptions::.\n\n'-d DATES'\nSpecify dates (D1>$CVSROOT/CVSROOT/commitlog\n\nUsing this same line and assuming a commit of new revisions 1.5.4.4\nand 1.27.4.1 based on old revisions 1.5.4.3 and 1.27, respectively, of\nfile1 and file2 in module, something like the following log message\nshould be appended to commitlog:\n\n\nmodule\nfile1 1.5.4.3 1.5.4.4 file2 1.27 1.27.4.1\nUpdate of /cvsroot/module\nIn directory localhost.localdomain:/home/jrandom/work/module\n\nModified Files:\nfile1 file2\nLog Message:\nA log message.\n", "subsections": [] }, "File: cvs.info, Node: Trigger Script Security, Next: commit files, Prev: syntax, Up: Trigger Scripts": { "content": "", "subsections": [] }, "Security is a huge subject, and implementing a secure system is a": { "content": "non-trivial task. This section will barely touch on all the issues\ninvolved, but it is well to note that, as with any script you will be\nallowing an untrusted user to run on your server, there are measures you\ncan take to help prevent your trigger scripts from being abused.\n\nFor instance, since the CVS trigger scripts all run in a copy of the\nuser's sandbox on the server, a naively coded Perl trigger script which\nattempts to use a Perl module that is not installed on the system can be\nhijacked by any user with commit access who is checking in a file with\nthe correct name. Other scripting languages may be vulnerable to\nsimilar hacks.\n\nOne way to make a script more secure, at least with Perl, is to use\nscripts which invoke the '-T', or \"taint-check\" switch on their '#!'\nline. In the most basic terms, this causes Perl to avoid running code\nthat may have come from an external source. Please run the 'perldoc\nperlsec' command for more on Perl security. Again, other languages may\nimplement other security verification hooks which look more or less like\nPerl's \"taint-check\" mechanism.\n", "subsections": [] }, "File: cvs.info, Node: commit files, Next: commitinfo, Prev: Trigger Script Security, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The '-i' flag in the 'modules' file can be used to run a certain program": { "content": "whenever files are committed (*note modules::). The files described in\nthis section provide other, more flexible, ways to run programs whenever\nsomething is committed.\n\nThere are three kinds of programs that can be run on commit. They\nare specified in files in the repository, as described below. The\nfollowing table summarises the file names and the purpose of the\ncorresponding programs.\n\n'commitinfo'\nThe program is responsible for checking that the commit is allowed.\nIf it exits with a non-zero exit status the commit will be aborted.\n*Note commitinfo::.\n\n'verifymsg'\nThe specified program is used to evaluate the log message, and\npossibly verify that it contains all required fields. This is most\nuseful in combination with the 'rcsinfo' file, which can hold a log\nmessage template (*note rcsinfo::). *Note verifymsg::.\n\n'loginfo'\nThe specified program is called when the commit is complete. It\nreceives the log message and some additional information and can\nstore the log message in a file, or mail it to appropriate persons,\nor maybe post it to a local newsgroup, or... Your imagination is\nthe limit! *Note loginfo::.\n\n* Menu:\n\n* Updating Commit Files:: Updating legacy repositories to stop using\ndeprecated command line template formats\n", "subsections": [] }, "File: cvs.info, Node: Updating Commit Files, Up: commit files": { "content": "C.3.3.1 Updating legacy repositories to stop using deprecated command line template formats\n...........................................................................................\n", "subsections": [] }, "New repositories are created set to use the new format strings by": { "content": "default, so if you are creating a new repository, you shouldn't have to\nworry about this section.\n\nIf you are attempting to maintain a legacy repository which was\nmaking use of the 'commitinfo', 'editinfo', 'verifymsg', 'loginfo',\nand/or 'taginfo' script hooks, you should have no immediate problems\nwith using the current CVS executable, but your users will probably\nstart to see deprecation warnings.\n\nThe reason for this is that all of the script hooks have been updated\nto use a new command line parser that extensibly supports multiple\n'loginfo' & 'notify' style format strings (*note syntax::) and this\nsupport is not completely compatible with the old style format strings.\n\nThe quick upgrade method is to stick a '1' after each format string\nin your old 'loginfo' file. For example:\n\nDEFAULT (echo \"\"; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog\n\nwould become:\n\nDEFAULT (echo \"\"; id; echo %1{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog\n\nIf you were counting on the fact that only the first '%' in the line\nwas replaced as a format string, you may also have to double up any\nfurther percent signs on the line.\n\nIf you did this all at once and checked it in, everything should\nstill be running properly.\n\nNow add the following line to your config file (*note config::):\nUseNewInfoFmtStrings=yes\n\nEverything should still be running properly, but your users will\nprobably start seeing new deprecation warnings.\n\nDealing with the deprecation warnings now generated by 'commitinfo',\n'editinfo', 'verifymsg', and 'taginfo' should be easy. Simply specify\nwhat are currently implicit arguments explicitly. This means appending\nthe following strings to each active command line template in each file:\n'commitinfo'\n' %r/%p %s'\n'editinfo'\n' %l'\n'taginfo'\n' %t %o %p %{sv}'\n'verifymsg'\n' %l'\n\nIf you don't desire that any of the newly available information be\npassed to the scripts hanging off of these hooks, no further\nmodifications to these files should be necessary to insure current and\nfuture compatibility with CVS's format strings.\n\nFixing 'loginfo' could be a little tougher. The old style 'loginfo'\nformat strings caused a single space and comma separated argument to be\npassed in in place of the format string. This is what will continue to\nbe generated due to the deprecated '1' you inserted into the format\nstrings.\n\nSince the new format separates each individual item and passes it\ninto the script as a separate argument (for a good reason - arguments\ncontaining commas and/or white space are now parsable), to remove the\ndeprecated '1' from your 'loginfo' command line templates, you will most\nlikely have to rewrite any scripts called by the hook to handle the new\nargument format.\n\nAlso note that the way '%' followed by unrecognised characters and by\n'{}' was treated in past versions of CVS is not strictly adhered to as\nthere were bugs in the old versions. Specifically, '%{}' would eat the\nnext character and unrecognised strings resolved only to the empty\nstring, which was counter to what was stated in the documentation. This\nversion will do what the documentation said it should have (if you were\nusing only some combination of '%{sVv}', e.g. '%{sVv}', '%{sV}', or\n'%v', you should have no troubles).\n\nOn the bright side, you should have plenty of time to do this before\nall support for the old format strings is removed from CVS, so you can\njust put up with the deprecation warnings for awhile if you like.\n", "subsections": [] }, "File: cvs.info, Node: commitinfo, Next: verifymsg, Prev: commit files, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'commitinfo' file defines programs to execute whenever 'cvs commit'": { "content": "is about to execute. These programs are used for pre-commit checking to\nverify that the modified, added and removed files are really ready to be\ncommitted. This could be used, for instance, to verify that the changed\nfiles conform to to your site's standards for coding practice.\n\nThe 'commitinfo' file has the standard form for script hooks (*note", "subsections": [] }, "Trigger Scripts::), where each line is a regular expression followed by": { "content": "a command to execute. It supports the ALL and DEFAULT keywords.\n\nIn addition to the common format strings, the 'postproxy' file\nsupports the following format string:\n\nP\nthe CVSROOT string which specifies the primary server\n", "subsections": [] }, "If a file is being removed, there will be no copy of the file under the": { "content": "current directory. If a file is being added, there will be no\ncorresponding archive file in the repository unless the file is being\nresurrected.\n\nNote that both the repository directory and the corresponding Attic\n(*note Attic::) directory may need to be checked to locate the archive\nfile corresponding to any given file being committed. Much of the\ninformation about the specific commit request being made, including the\ndestination branch, commit message, and command line options specified,\nis not available to the command.\n", "subsections": [] }, "File: cvs.info, Node: verifymsg, Next: loginfo, Prev: commitinfo, Up: Trigger Scripts": { "content": "", "subsections": [] }, "Once you have entered a log message, you can evaluate that message to": { "content": "check for specific content, such as a bug ID. Use the 'verifymsg' file\nto specify a program that is used to verify the log message. This\nprogram could be a simple script that checks that the entered message\ncontains the required fields.\n\nThe 'verifymsg' file is often most useful together with the 'rcsinfo'\nfile, which can be used to specify a log message template (*note\nrcsinfo::).\n\nThe 'verifymsg' file has the standard form for script hooks (*note", "subsections": [] }, "File: cvs.info, Node: verifymsg example, Up: verifymsg": { "content": "C.3.5.1 Verifying log messages\n..............................\n", "subsections": [] }, "The following is a little silly example of a 'verifymsg' file, together": { "content": "with the corresponding 'rcsinfo' file, the log message template and a\nverification script. We begin with the log message template. We want\nto always record a bug-id number on the first line of the log message.", "subsections": [] }, "The rest of log message is free text. The following template is found": { "content": "in the file '/usr/cvssupport/tc.template'.\n\nBugId:\n\nThe script '/usr/cvssupport/bugid.verify' is used to evaluate the log\nmessage.\n\n#!/bin/sh\n#\n# bugid.verify filename\n#\n# Verify that the log message contains a valid bugid\n# on the first line.\n#\nif sed 1q < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then\nexit 0\nelif sed 1q < $1 | grep '^BugId:[ ]*none$' > /dev/null; then\n# It is okay to allow commits with 'BugId: none',\n# but do not put that text into the real log message.\ngrep -v '^BugId:[ ]*none$' > $1.rewrite\nmv $1.rewrite $1\nexit 0\nelse\necho \"No BugId found.\"\nexit 1\nfi\n\nThe 'verifymsg' file contains this line:\n\n^tc /usr/cvssupport/bugid.verify %l\n\nThe 'rcsinfo' file contains this line:\n\n^tc /usr/cvssupport/tc.template\n\nThe 'config' file contains this line:\n\nRereadLogAfterVerify=always\n", "subsections": [] }, "File: cvs.info, Node: loginfo, Next: postadmin, Prev: verifymsg, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'loginfo' file is used to control where log information is sent": { "content": "after versioned changes are made to repository archive files and after\ndirectories are added to the repository. *note posttag:: for how to log\ntagging information and *note postadmin:: for how to log changes due to\nthe 'admin' command.\n\nThe 'loginfo' file has the standard form for script hooks (*note", "subsections": [] }, "File: cvs.info, Node: loginfo example, Next: Keeping a checked out copy, Up: loginfo": { "content": "C.3.6.1 Loginfo example\n.......................\n", "subsections": [] }, "The following 'loginfo' file, together with the tiny shell-script below,": { "content": "appends all log messages to the file '$CVSROOT/CVSROOT/commitlog', and\nany commits to the administrative files (inside the 'CVSROOT' directory)\nare also logged in '/usr/adm/cvsroot-log'. Commits to the 'prog1'\ndirectory are mailed to ceder.\n\nALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER\n^CVSROOT\\(/\\|$\\) /usr/local/bin/cvs-log /usr/adm/cvsroot-log $USER\n^prog1\\(/\\|$\\) Mail -s \"%p %s\" ceder\n\nThe shell-script '/usr/local/bin/cvs-log' looks like this:\n\n#!/bin/sh\n(echo \"------------------------------------------------------\";\necho -n \"$2 \";\ndate;\necho;\ncat) >> $1\n", "subsections": [] }, "File: cvs.info, Node: Keeping a checked out copy, Prev: loginfo example, Up: loginfo": { "content": "C.3.6.2 Keeping a checked out copy\n..................................\n", "subsections": [] }, "It is often useful to maintain a directory tree which contains files": { "content": "which correspond to the latest version in the repository. For example,\nother developers might want to refer to the latest sources without\nhaving to check them out, or you might be maintaining a web site with\nCVS and want every checkin to cause the files used by the web server to\nbe updated.\n\nThe way to do this is by having loginfo invoke 'cvs update'. Doing\nso in the naive way will cause a problem with locks, so the 'cvs update'\nmust be run in the background. Here is an example for unix (this should\nall be on one line):\n\n^cyclic-pages\\(/\\|$\\)\t(date; cat; (sleep 2; cd /u/www/local-docs;\ncvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1\n\nThis will cause checkins to repository directory 'cyclic-pages' and\nits subdirectories to update the checked out tree in\n'/u/www/local-docs'.\n", "subsections": [] }, "File: cvs.info, Node: postadmin, Next: taginfo, Prev: loginfo, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'postadmin' file defines programs to execute after an 'admin'": { "content": "command modifies files. The 'postadmin' file has the standard form for\nscript hooks (*note Trigger Scripts::), where each line is a regular\nexpression followed by a command to execute. It supports the ALL and\nDEFAULT keywords.\n\nThe 'postadmin' file supports no format strings other than the common\nones (*note syntax::),\n", "subsections": [] }, "File: cvs.info, Node: taginfo, Next: posttag, Prev: postadmin, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'taginfo' file defines programs to execute when someone executes a": { "content": "'tag' or 'rtag' command. The 'taginfo' file has the standard form for\nscript hooks (*note Trigger Scripts::), where each line is a regular\nexpression followed by a command to execute. It supports the ALL and\nDEFAULT keywords.\n\nIn addition to the common format strings (*note syntax::), 'taginfo'\nsupports:\n\nb\ntag type ('T' for branch, 'N' for not-branch, or '?' for unknown,\nas during delete operations)\no\noperation ('add' for 'tag', 'mov' for 'tag -F', or 'del' for 'tag\n-d')\nt\nnew tag name\n{sTVv}\nfile attributes, where:\ns\nfile name\nT\ntag name of destination, or the empty string when there is no\nassociated tag name (this usually means the trunk)\nV\nold version number (for a move or delete operation)\nv\nnew version number (for an add or move operation)\n\nFor example, some valid format strings are '%%', '%p', '%t', '%s',\n'%{s}', and '%{sVv}'.\n\nCurrently, if no format strings are specified, a default string of '\n%t %o %p %{sv}' will be appended to the command line template before\nreplacement is performed, but this feature is deprecated. It is simply\nin place so that legacy repositories will remain compatible with the new\nCVS application. For information on updating, *note Updating Commit\nFiles::.\n\nA non-zero exit of the filter program will cause the tag to be\naborted.\n\nHere is an example of using 'taginfo' to log 'tag' and 'rtag'\ncommands. In the 'taginfo' file put:\n\nALL /usr/local/cvsroot/CVSROOT/loggit %t %b %o %p %{sVv}\n\nWhere '/usr/local/cvsroot/CVSROOT/loggit' contains the following script:\n\n#!/bin/sh\necho \"$@\" >>/home/kingdon/cvsroot/CVSROOT/taglog\n", "subsections": [] }, "File: cvs.info, Node: posttag, Next: postwatch, Prev: taginfo, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'posttag' file defines programs to execute after a 'tag' or 'rtag'": { "content": "command modifies files. The 'posttag' file has the standard form for\nscript hooks (*note Trigger Scripts::), where each line is a regular\nexpression followed by a command to execute. It supports the ALL and\nDEFAULT keywords.\n\nThe 'posttag' admin file supports the same format strings as the\n'taginfo' file (*note taginfo::),\n", "subsections": [] }, "File: cvs.info, Node: postwatch, Next: preproxy, Prev: posttag, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'postwatch' file defines programs to execute after any command (for": { "content": "instance, 'watch', 'edit', 'unedit', or 'commit') modifies any\n'CVS/fileattr' file in the repository (*note Watches::). The\n'postwatch' file has the standard form for script hooks (*note Trigger", "subsections": [] }, "Scripts::), where each line is a regular expression followed by a": { "content": "command to execute. It supports the ALL and DEFAULT keywords.\n\nThe 'postwatch' file supports no format strings other than the common\nones (*note syntax::), but it is worth noting that the '%c' format\nstring may not be replaced as you might expect. Client runs of 'edit'\nand 'unedit' can sometimes skip contacting the CVS server and cache the\nnotification of the file attribute change to be sent the next time the\nclient contacts the server for whatever other reason,\n", "subsections": [] }, "File: cvs.info, Node: preproxy, Next: postproxy, Prev: postwatch, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'preproxy' file defines programs to execute after a secondary server": { "content": "receives a write request from a client, just before it starts up the\nprimary server and becomes a write proxy. This hook could be used to\ndial a modem, launch an SSH tunnel, establish a VPN, or anything else\nthat might be necessary to do before contacting the primary server.\n\n'preproxy' scripts are called once, at the time of the write request,\nwith the repository argument (if requested) set from the topmost\ndirectory sent by the client.\n\nThe 'preproxy' file has the standard form for script hooks (*note", "subsections": [] }, "File: cvs.info, Node: postproxy, Prev: preproxy, Up: Trigger Scripts": { "content": "", "subsections": [] }, "The 'postproxy' file defines programs to execute after a secondary": { "content": "server notes that the connection to the primary server has shut down and\nbefore it releases the client by shutting down the connection to the\nclient. This could hook could be used to disconnect a modem, an SSH\ntunnel, a VPN, or anything else that might be necessary to do after\ncontacting the primary server. This hook should also be used to pull\nupdates from the primary server before allowing the client which did the\nwrite to disconnect since otherwise the client's next read request may\ngenerate error messages and fail upon encountering an out of date\nrepository on the secondary server.\n\n'postproxy' scripts are called once per directory.\n\nThe 'postproxy' file has the standard form for script hooks (*note", "subsections": [] }, "File: cvs.info, Node: rcsinfo, Next: cvsignore, Prev: Trigger Scripts, Up: Administrative files": { "content": "", "subsections": [ { "name": "C.4 Rcsinfo", "content": "" } ] }, "The 'rcsinfo' file can be used to specify a form to edit when filling": { "content": "out the commit log. The 'rcsinfo' file has a syntax similar to the\n'verifymsg', 'commitinfo' and 'loginfo' files. *Note syntax::. Unlike\nthe other files the second part is not a command-line template.", "subsections": [] }, "Instead, the part after the regular expression should be a full pathname": { "content": "to a file containing the log message template.\n\nIf the repository name does not match any of the regular expressions\nin this file, the 'DEFAULT' line is used, if it is specified.\n\nAll occurrences of the name 'ALL' appearing as a regular expression\nare used in addition to the first matching regular expression or\n'DEFAULT'.\n\nThe log message template will be used as a default log message. If\nyou specify a log message with 'cvs commit -m MESSAGE' or 'cvs commit -f\nFILE' that log message will override the template.\n\n*Note verifymsg::, for an example 'rcsinfo' file.\n\nWhen CVS is accessing a remote repository, the contents of 'rcsinfo'\nat the time a directory is first checked out will specify a template.", "subsections": [] }, "This template will be updated on all 'cvs update' commands. It will": { "content": "also be added to new directories added with a 'cvs add new-directory'\ncommand. In versions of CVS prior to version 1.12, the 'CVS/Template'\nfile was not updated. If the CVS server is at version 1.12 or higher an\nolder client may be used and the 'CVS/Template' will be updated from the\nserver.\n", "subsections": [] }, "File: cvs.info, Node: cvsignore, Next: checkoutlist, Prev: rcsinfo, Up: Administrative files": { "content": "", "subsections": [ { "name": "C.5 Ignoring files via cvsignore", "content": "" } ] }, "There are certain file names that frequently occur inside your working": { "content": "copy, but that you don't want to put under CVS control. Examples are\nall the object files that you get while you compile your sources.", "subsections": [] }, "Normally, when you run 'cvs update', it prints a line for each file it": { "content": "encounters that it doesn't know about (*note update output::).\n\nCVS has a list of files (or sh(1) file name patterns) that it should\nignore while running 'update', 'import' and 'release'. This list is\nconstructed in the following way.\n\n* The list is initialised to include certain file name patterns:\nnames associated with CVS administration, or with other common\nsource control systems; common names for patch files, object files,\narchive files, and editor backup files; and other names that are\nusually artifacts of assorted utilities. Currently, the default\nlist of ignored file name patterns is:\n\nRCS SCCS CVS CVS.adm\nRCSLOG cvslog.*\ntags TAGS\n.make.state .nsedepinfo\n*~ #* .#* ,* $* *$\n*.old *.bak *.BAK *.orig *.rej .del-*\n*.a *.olb *.o *.obj *.so *.exe\n*.Z *.elc *.ln\ncore\n\n* The per-repository list in '$CVSROOT/CVSROOT/cvsignore' is appended\nto the list, if that file exists.\n\n* The per-user list in '.cvsignore' in your home directory is\nappended to the list, if it exists.\n\n* Any entries in the environment variable '$CVSIGNORE' is appended to\nthe list.\n\n* Any '-I' options given to CVS is appended.\n\n* As CVS traverses through your directories, the contents of any\n'.cvsignore' will be appended to the list. The patterns found in\n'.cvsignore' are only valid for the directory that contains them,\nnot for any sub-directories.\n\nIn any of the 5 places listed above, a single exclamation mark ('!')\nclears the ignore list. This can be used if you want to store any file\nwhich normally is ignored by CVS.\n\nSpecifying '-I !' to 'cvs import' will import everything, which is\ngenerally what you want to do if you are importing files from a pristine\ndistribution or any other source which is known to not contain any\nextraneous files. However, looking at the rules above you will see\nthere is a fly in the ointment; if the distribution contains any\n'.cvsignore' files, then the patterns from those files will be processed\neven if '-I !' is specified. The only workaround is to remove the\n'.cvsignore' files in order to do the import. Because this is awkward,\nin the future '-I !' might be modified to override '.cvsignore' files in\neach directory.\n\nNote that the syntax of the ignore files consists of a series of\nlines, each of which contains a space separated list of filenames. This\noffers no clean way to specify filenames which contain spaces, but you\ncan use a workaround like 'foo?bar' to match a file named 'foo bar' (it\nalso matches 'fooxbar' and the like). Also note that there is currently\nno way to specify comments.\n", "subsections": [] }, "File: cvs.info, Node: checkoutlist, Next: history file, Prev: cvsignore, Up: Administrative files": { "content": "", "subsections": [ { "name": "C.6 The checkoutlist file", "content": "" } ] }, "It may be helpful to use CVS to maintain your own files in the 'CVSROOT'": { "content": "directory. For example, suppose that you have a script 'logcommit.pl'\nwhich you run by including the following line in the 'commitinfo'\nadministrative file:\n\nALL $CVSROOT/CVSROOT/logcommit.pl %r/%p %s\n\nTo maintain 'logcommit.pl' with CVS you would add the following line\nto the 'checkoutlist' administrative file:\n\nlogcommit.pl\n\nThe format of 'checkoutlist' is one line for each file that you want\nto maintain using CVS, giving the name of the file, followed optionally\nby more whitespace and any error message that should print if the file\ncannot be checked out into CVSROOT after a commit:\n\nlogcommit.pl\tCould not update CVSROOT/logcommit.pl.\n\nAfter setting up 'checkoutlist' in this fashion, the files listed\nthere will function just like CVS's built-in administrative files. For\nexample, when checking in one of the files you should get a message such\nas:\n\ncvs commit: Rebuilding administrative file database\n\nand the checked out copy in the 'CVSROOT' directory should be updated.\n\nNote that listing 'passwd' (*note Password authentication server::)\nin 'checkoutlist' is not recommended for security reasons.\n\nFor information about keeping a checkout out copy in a more general\ncontext than the one provided by 'checkoutlist', see *note Keeping a\nchecked out copy::.\n", "subsections": [] }, "File: cvs.info, Node: history file, Next: Variables, Prev: checkoutlist, Up: Administrative files": { "content": "", "subsections": [ { "name": "C.7 The history file", "content": "By default, the file '$CVSROOT/CVSROOT/history' is used to log\ninformation for the 'history' command (*note history::). This file name\nmay be changed with the 'HistoryLogPath' and 'HistorySearchPath' config\noptions (*note config::).\n\nThe file format of the 'history' file is documented only in comments\nin the CVS source code, but generally programs should use the 'cvs\nhistory' command to access it anyway, in case the format changes with\nfuture releases of CVS.\n" } ] }, "File: cvs.info, Node: Variables, Next: config, Prev: history file, Up: Administrative files": { "content": "", "subsections": [ { "name": "C.8 Expansions in administrative files", "content": "" } ] }, "Sometimes in writing an administrative file, you might want the file to": { "content": "be able to know various things based on environment CVS is running in.\nThere are several mechanisms to do that.\n\nTo find the home directory of the user running CVS (from the 'HOME'\nenvironment variable), use '~' followed by '/' or the end of the line.\nLikewise for the home directory of USER, use '~USER'. These variables\nare expanded on the server machine, and don't get any reasonable\nexpansion if pserver (*note Password authenticated::) is in use;\ntherefore user variables (see below) may be a better choice to customise\nbehavior based on the user running CVS.\n\nOne may want to know about various pieces of information internal to\nCVS. A CVS internal variable has the syntax '${VARIABLE}', where\nVARIABLE starts with a letter and consists of alphanumeric characters\nand ''. If the character following VARIABLE is a non-alphanumeric\ncharacter other than '', the '{' and '}' can be omitted. The CVS\ninternal variables are:\n\n'CVSROOT'\nThis is the absolute path to the current CVS root directory. *Note\nRepository::, for a description of the various ways to specify\nthis, but note that the internal variable contains just the\ndirectory and not any of the access method information.\n\n'RCSBIN'\nIn CVS 1.9.18 and older, this specified the directory where CVS was\nlooking for RCS programs. Because CVS no longer runs RCS programs,\nspecifying this internal variable is now an error.\n\n'CVSEDITOR'\n'EDITOR'\n'VISUAL'\nThese all expand to the same value, which is the editor that CVS is\nusing. *Note Global options::, for how to specify this.\n\n'USER'\nUsername of the user running CVS (on the CVS server machine). When\nusing pserver, this is the user specified in the repository\nspecification which need not be the same as the username the server\nis running as (*note Password authentication server::). Do not\nconfuse this with the environment variable of the same name.\n\n'SESSIONID'\nUnique Session ID of the CVS process. This is a random string of\nprintable characters of at least 16 characters length. Users\nshould assume that it may someday grow to at most 256 characters in\nlength.\n\n'COMMITID'\nUnique Session ID of the CVS process. This is a random string of\nprintable characters of at least 16 characters length. Users\nshould assume that it may someday grow to at most 256 characters in\nlength. Currently, Debian and MirBSD CVS uses 19 characters.\n\nIf you want to pass a value to the administrative files which the\nuser who is running CVS can specify, use a user variable. To expand a\nuser variable, the administrative file contains '${=VARIABLE}'. To set\na user variable, specify the global option '-s' to CVS, with argument\n'VARIABLE=VALUE'. It may be particularly useful to specify this option\nvia '.cvsrc' (*note ~/.cvsrc::).\n\nFor example, if you want the administrative file to refer to a test\ndirectory you might create a user variable 'TESTDIR'. Then if CVS is\ninvoked as\n\ncvs -s TESTDIR=/work/local/tests\n\nand the administrative file contains 'sh ${=TESTDIR}/runtests', then\nthat string is expanded to 'sh /work/local/tests/runtests'.\n\nAll other strings containing '$' are reserved; there is no way to\nquote a '$' character so that '$' represents itself.\n\nEnvironment variables passed to administrative files are:\n\n'CVSUSER'\nThe CVS-specific username provided by the user, if it can be\nprovided (currently just for the pserver access method), and to the\nempty string otherwise. ('CVSUSER' and 'USER' may differ when\n'$CVSROOT/CVSROOT/passwd' is used to map CVS usernames to system\nusernames.)\n\n'LOGNAME'\nThe username of the system user.\n\n'USER'\nSame as 'LOGNAME'. Do not confuse this with the internal variable\nof the same name.\n", "subsections": [] }, "File: cvs.info, Node: config, Prev: Variables, Up: Administrative files": { "content": "", "subsections": [ { "name": "C.9 The CVSROOT/config configuration file", "content": "Usually, the 'config' file is found at '$CVSROOT/CVSROOT/config', but\nthis may be overridden on the 'pserver' and 'server' command lines\n(*note server & pserver::).\n\nThe administrative file 'config' contains various miscellaneous\nsettings which affect the behavior of CVS. The syntax is slightly\ndifferent from the other administrative files.\n\nLeading white space on any line is ignored, though the syntax is very\nstrict and will reject spaces and tabs almost anywhere else.\n\nEmpty lines, lines containing nothing but white space, and lines\nwhich start with '#' (discounting any leading white space) are ignored.\n\nOther lines consist of the optional leading white space, a keyword,\n'=', and a value. Please note again that this syntax is very strict." } ] }, "Extraneous spaces or tabs, other than the leading white space, are not": { "content": "permitted on these lines.\n\nAs of CVS 1.12.13, lines of the form '[CVSROOT]' mark the subsequent\nsection of the config file as applying only to certain repositories.\nMultiple '[CVSROOT]' lines without intervening 'KEYWORD=VALUE' pairs\ncause processing to fall through, processing subsequent keywords for any\nroot in the list. Finally, keywords and values which appear before any\n'[CVSROOT]' lines are defaults, and may to apply to any repository. For\nexample, consider the following file:\n\n# Defaults\nLogHistory=TMAR\n\n[/cvsroots/team1]\nLockDir=/locks/team1\n\n[/cvsroots/team2]\nLockDir=/locks/team2\n\n[/cvsroots/team3]\nLockDir=/locks/team3\n\n[/cvsroots/team4]\nLockDir=/locks/team4\n\n[/cvsroots/team3]\n[/cvsroots/team4]\n# Override logged commands for teams 3 & 4.\nLogHistory=all\n\nThis example file sets up separate lock directories for each project,\nas well as a default set of logged commands overridden for the example's\nteam 3 & team 4. This syntax could be useful, for instance, if you\nwished to share a single config file, for instance '/etc/cvs.conf',\namong several repositories.\n\nCurrently defined keywords are:\n\n'HistorySearchPath=PATTERN'\nRequest that CVS look for its history information in files matching\nPATTERN, which is a standard UNIX file glob. If PATTERN matches\nmultiple files, all will be searched in lexicographically sorted\norder. *Note history::, and *note history file::, for more.\n\nIf no value is supplied for this option, it defaults to\n'$CVSROOT/CVSROOT/history'.\n\n'HistoryLogPath=PATH'\nControl where CVS logs its history. If the file does not exist,\nCVS will attempt to create it. Format strings, as available to the\nGNU C 'strftime' function and often the UNIX date command, and the\nstring $CVSROOT will be substituted in this path. For example,\nconsider the line:\n\nHistoryLogPath=$CVSROOT/CVSROOT/history/%Y-%m-%d\n\nThis line would cause CVS to attempt to create its history file in\na subdirectory ('history') of the configuration directory\n('CVSROOT') with a name equal to the current date representation in\nthe ISO8601 format (for example, on May 11, 2005, CVS would attempt\nto log its history under the repository root directory in a file\nnamed 'CVSROOT/history/2005-05-11'). *Note history::, and *note\nhistory file::, for more.\n\nIf no value is supplied for this option, it defaults to\n'$CVSROOT/CVSROOT/history'.\n\n'ImportNewFilesToVendorBranchOnly=VALUE'\nSpecify whether 'cvs import' should always behave as if the '-X'\nflag was specified on the command line. VALUE may be either 'yes'\nor 'no'. If set to 'yes', all uses of 'cvs import' on the\nrepository will behave as if the '-X' flag was set. The default\nvalue is 'no'.\n\n'KeywordExpand=VALUE'\nSpecify 'i' followed by a list of keywords to be expanded (for\nexample, 'KeywordExpand=iMYCVS,Name,Date,Mdocdate'), or 'e'\nfollowed by a list of keywords not to be expanded (for example,\n'KeywordExpand=eCVSHeader'). For more on keyword expansion, see\n*note Configuring keyword expansion::.\n\n'LocalKeyword=VALUE'\nSpecify a local alias for a standard keyword. See *note Keyword\nsubstitution:: for more information in local keywords. Example:\n'LocalKeyword=MYCVS=CVSHeader'\n\n'LockDir=DIRECTORY'\nPut CVS lock files in DIRECTORY rather than directly in the\nrepository. This is useful if you want to let users read from the\nrepository while giving them write access only to DIRECTORY, not to\nthe repository. It can also be used to put the locks on a very\nfast in-memory filesystem to speed up locking and unlocking the\nrepository. You need to create DIRECTORY, but CVS will create\nsubdirectories of DIRECTORY as it needs them. For information on\nCVS locks, see *note Concurrency::.\n\nBefore enabling the LockDir option, make sure that you have tracked\ndown and removed any copies of CVS 1.9 or older. Such versions\nneither support LockDir, nor will give an error indicating that\nthey don't support it. The result, if this is allowed to happen,\nis that some CVS users will put the locks one place, and others\nwill put them another place, and therefore the repository could\nbecome corrupted. CVS 1.10 does not support LockDir but it will\nprint a warning if run on a repository with LockDir enabled.\n\n'LogHistory=VALUE'\nControl what is logged to the 'CVSROOT/history' file (*note\nhistory::). Default of 'TOEFWUPCGMAR' (or simply 'all') will log\nall transactions. Any subset of the default is legal. (For\nexample, to only log transactions that modify the '*,v' files, use\n'LogHistory=TMAR' which is nowadays set by 'cvs init' by default.)\nTo disable history logging completely, use 'LogHistory='.\n\n'MaxCommentLeaderLength=LENGTH'\nSet to some length, in bytes, where a trailing 'k', 'M', 'G', or\n'T' causes the preceding nubmer to be interpreted as kilobytes,\nmegabytes, gigabytes, or terrabytes, respectively, will cause\n'$Log$' keywords (*note Keyword substitution::), with more than\nLENGTH bytes preceding it on a line to be ignored (or to fall back\non the comment leader set in the RCS archive file - see\n'UseArchiveCommentLeader' below). Defaults to 20 bytes to allow\ncheckouts to proceed normally when they include binary files\ncontaining '$Log$' keywords and which users have neglected to mark\nas binary.\n\n'MinCompressionLevel=VALUE'\n'MaxCompressionLevel=VALUE'\nRestricts the level of compression used by the CVS server to a\nVALUE between 0 and 9. VALUEs 1 through 9 are the same ZLIB\ncompression levels accepted by the '-z' option (*note Global\noptions::), and 0 means no compression. When one or both of these\nkeys are set and a client requests a level outside the specified\nrange, the server will simply use the closest permissable level.\nClients will continue compressing at the level requested by the\nuser.\n\nThe exception is when level 0 (no compression) is not available and\nthe client fails to request any compression. The CVS server will\nthen exit with an error message when it becomes apparent that the\nclient is not going to request compression. This will not happen\nwith clients version 1.12.13 and later since these client versions\nallow the server to notify them that they must request some level\nof compression.\n\n'PrimaryServer=CVSROOT'\nWhen specified, and the repository specified by CVSROOT is not the\none currently being accessed, then the server will turn itself into\na transparent proxy to CVSROOT for write requests. The HOSTNAME\nconfigured as part of CVSROOT must resolve to the same string\nreturned by the 'uname' command on the primary server for this to\nwork. Host name resolution is performed via some combination of\n'named', a broken out line from '/etc/hosts', and the Network\nInformation Service (NIS or YP), depending on the configuration of\nthe particular system.\n\nOnly the ':ext:' method is currently supported for primaries\n(actually, ':fork:' is supported as well, but only for testing - if\nyou find another use for accessing a primary via the ':fork:'\nmethod, please send a note to about it). See\n*note Write proxies:: for more on configuring and using write\nproxies.\n\n'RCSBIN=BINDIR'\nFor CVS 1.9.12 through 1.9.18, this setting told CVS to look for\nRCS programs in the BINDIR directory. Current versions of CVS do\nnot run RCS programs; for compatibility this setting is accepted,\nbut it does nothing.\n\n'RereadLogAfterVerify=VALUE'\nModify the 'commit' command such that CVS will reread the log\nmessage after running the program specified by 'verifymsg'. VALUE\nmay be one of 'yes' or 'always', indicating that the log message\nshould always be reread; 'no' or 'never', indicating that it should\nnever be reread; or VALUE may be 'stat', indicating that the file\nshould be checked with the filesystem 'stat()' function to see if\nit has changed (see warning below) before rereading. The default\nvalue is 'always'.\n\nNote: the 'stat' mode can cause CVS to pause for up to one extra\nsecond per directory committed. This can be less IO and CPU\nintensive but is not recommended for use with large repositories\n\n*Note verifymsg::, for more information on how verifymsg may be\nused.\n\n'SystemAuth=VALUE'\nIf VALUE is 'yes', then pserver should check for users in the\nsystem's user database if not found in 'CVSROOT/passwd'. If it is\n'no', then all pserver users must exist in 'CVSROOT/passwd'. The\ndefault is 'yes'. For more on pserver, see *note Password\nauthenticated::.\n\n'TmpDir=PATH'\nSpecify PATH as the directory to create temporary files in. *Note\nGlobal options::, for more on setting the path to the temporary\ndirectory. This option first appeared with CVS release 1.12.13.\n\n'TopLevelAdmin=VALUE'\nModify the 'checkout' command to create a 'CVS' directory at the\ntop level of the new working directory, in addition to 'CVS'\ndirectories created within checked-out directories. The default\nvalue is 'no'.\n\nThis option is useful if you find yourself performing many commands\nat the top level of your working directory, rather than in one of\nthe checked out subdirectories. The 'CVS' directory created there\nwill mean you don't have to specify 'CVSROOT' for each command. It\nalso provides a place for the 'CVS/Template' file (*note Working\ndirectory storage::).\n\n'UseArchiveCommentLeader=VALUE'\nSet to 'true', if the text preceding a '$Log$' keyword is found to\nexceed 'MaxCommentLeaderLength' (above) bytes, then the comment\nleader set in the RCS archive file (*note admin::), if any, will be\nused instead. If there is no comment leader set in the archive\nfile or VALUE is set to 'false', then the keyword will not be\nexpanded (*note Keyword list::). To force the comment leader in\nthe RCS archive file to be used exclusively (and '$Log$' expansion\nskipped in files where the comment leader has not been set in the\narchive file), set VALUE and set 'MaxCommentLeaderLength' to '0'.\n\n'UseNewInfoFmtStrings=VALUE'\nSpecify whether CVS should support the new or old command line\ntemplate model for the commit support files (*note commit files::).\nThis configuration variable began life in deprecation and is only\nhere in order to give people time to update legacy repositories to\nuse the new format string syntax before support for the old syntax\nis removed. For information on updating your repository to support\nthe new model, please see *note Updating Commit Files::.\n\nNote that new repositories (created with the 'cvs init' command)\nwill have this value set to 'yes', but the default value is 'no'.\n\n'UserAdminOptions=VALUE'\nControl what options will be allowed with the 'cvs admin' command\n(*note admin::) for users not in the 'cvsadmin' group. The VALUE\nstring is a list of single character options which should be\nallowed. If a user who is not a member of the 'cvsadmin' group\ntries to execute any 'cvs admin' option which is not listed they\nwill will receive an error message reporting that the option is\nrestricted.\n\nIf no 'cvsadmin' group exists on the server, CVS will ignore the\n'UserAdminOptions' keyword (*note admin::).\n\nWhen not specified, 'UserAdminOptions' defaults to 'k'. In other\nwords, it defaults to allowing users outside of the 'cvsadmin'\ngroup to use the 'cvs admin' command only to change the default\nkeyword expansion mode for files.\n\nAs an example, to restrict users not in the 'cvsadmin' group to\nusing 'cvs admin' to change the default keyword substitution mode,\nlock revisions, unlock revisions, and replace the log message, use\n'UserAdminOptions=klum'.\n", "subsections": [] }, "File: cvs.info, Node: Environment variables, Next: Compatibility, Prev: Administrative files, Up: Top": { "content": "", "subsections": [] }, "Appendix D All environment variables which affect CVS": { "content": "", "subsections": [] }, "This is a complete list of all environment variables that affect CVS": { "content": "(Windows users, please bear with this list; $VAR is equivalent to %VAR%\nat the Windows command prompt).\n\n'$CVSIGNORE'\nA whitespace-separated list of file name patterns that CVS should\nignore. *Note cvsignore::.\n\n'$CVSWRAPPERS'\nA whitespace-separated list of file name patterns that CVS should\ntreat as wrappers. *Note Wrappers::.\n\n'$CVSREAD'\nIf this is set, 'checkout' and 'update' will try hard to make the\nfiles in your working directory read-only. When this is not set,\nthe default behavior is to permit modification of your working\nfiles.\n\n'$CVSREADONLYFS'\nTurns on read-only repository mode. This allows one to check out\nfrom a read-only repository, such as within an anoncvs server, or\nfrom a CD-ROM repository.\n\nSetting this has the same effect as if the '-R' command-line option\nis used. This can also allow the use of read-only NFS\nrepositories.\n\n'$CVSUMASK'\nControls permissions of files in the repository. See *note File\npermissions::.\n\n'$CVSROOT'\nShould contain the full pathname to the root of the CVS source\nrepository (where the RCS files are kept). This information must\nbe available to CVS for most commands to execute; if '$CVSROOT' is\nnot set, or if you wish to override it for one invocation, you can\nsupply it on the command line: 'cvs -d cvsroot cvscommand...' Once\nyou have checked out a working directory, CVS stores the\nappropriate root (in the file 'CVS/Root'), so normally you only\nneed to worry about this when initially checking out a working\ndirectory.\n\n'$CVSEDITOR'\n'$EDITOR'\n'$VISUAL'\nSpecifies the program to use for recording log messages during\ncommit. '$CVSEDITOR' overrides '$EDITOR', which overrides\n'$VISUAL'. See *note Committing your changes:: for more or *note\nGlobal options:: for alternative ways of specifying a log editor.\n\n'$PATH'\nIf '$RCSBIN' is not set, and no path is compiled into CVS, it will\nuse '$PATH' to try to find all programs it uses.\n\n'$HOME'\n'$HOMEPATH'\n'$HOMEDRIVE'\nUsed to locate the directory where the '.cvsrc' file, and other\nsuch files, are searched. On Unix, CVS just checks for 'HOME'. On\nWindows NT, the system will set 'HOMEDRIVE', for example to 'd:'\nand 'HOMEPATH', for example to '\\joe'. On Windows 95, you'll\nprobably need to set 'HOMEDRIVE' and 'HOMEPATH' yourself.\n\n'$CVSRSH'\nSpecifies the external program which CVS connects with, when\n':ext:' access method is specified. *note Connecting via rsh::.\n\n'$CVSSERVER'\nUsed in client-server mode when accessing a remote repository using\nRSH. It specifies the name of the program to start on the server\nside (and any necessary arguments) when accessing a remote\nrepository using the ':ext:', ':fork:', or ':server:' access\nmethods. The default value for ':ext:' and ':server:' is 'cvs';\nthe default value for ':fork:' is the name used to run the client.\n*note Connecting via rsh::\n\n'$CVSPASSFILE'\nUsed in client-server mode when accessing the 'cvs login server'.\nDefault value is '$HOME/.cvspass'. *note Password authentication\nclient::\n\n'$CVSCLIENTPORT'\nUsed in client-server mode to set the port to use when accessing\nthe server via Kerberos, GSSAPI, or CVS's password authentication\nprotocol if the port is not specified in the CVSROOT. *note Remote\nrepositories::\n\n'$CVSPROXYPORT'\nUsed in client-server mode to set the port to use when accessing a\nserver via a web proxy, if the port is not specified in the\nCVSROOT. Works with GSSAPI, and the password authentication\nprotocol. *note Remote repositories::\n\n'$CVSRCMDPORT'\nUsed in client-server mode. If set, specifies the port number to\nbe used when accessing the RCMD demon on the server side.\n(Currently not used for Unix clients).\n\n'$CVSCLIENTLOG'\nUsed for debugging only in client-server mode. If set and not\nempty, everything sent to the server is logged into\n'$CVSCLIENTLOG.in', and everything received from the server is\nlogged into '$CVSCLIENTLOG.out'.\n\n'$CVSSECONDARYLOG'\nUsed for debugging only in secondary write proxy mode. If set and\nnot empty, everything sent to the primary server is logged into\n'$CVSSECONDARYLOG.in', and everything received from the primary\nserver is logged into '$CVSSECONDARYLOG.out'.\n\n'$CVSSERVERLOG'\nUsed for debugging only in client-server mode. If set and not\nempty, everything sent to the client is logged into\n'$CVSSERVERLOG.in', and everything received from the client is\nlogged into '$CVSSERVERLOG.out'.\n\n'$CVSSERVERSLEEP'\nUsed only for debugging the server side in client-server mode. If\nset, delays the start of the server child process the specified\namount of seconds so that you can attach to it with a debugger.\n\n'$CVSIGNOREREMOTEROOT'\nFor CVS 1.10 and older, setting this variable prevents CVS from\noverwriting the 'CVS/Root' file when the '-d' global option is\nspecified. Later versions of CVS do not rewrite 'CVS/Root', so\n'CVSIGNOREREMOTEROOT' has no effect.\n\n'$CVSLOCALBRANCHNUM'\nSetting this variable allows some control over the branch number\nthat is assigned. This is specifically to support the local commit\nfeature of CVSup. If one sets 'CVSLOCALBRANCHNUM' to (say) 1000\nthen branches the local repository, the revision numbers will look\nlike 1.66.1000.xx. There is almost a dead-set certainty that there\nwill be no conflicts with version numbers.\n\n'$COMSPEC'\nUsed under OS/2 only. It specifies the name of the command\ninterpreter and defaults to CMD.EXE.\n\n'$TMPDIR'\nDirectory in which temporary files are located. *Note Global\noptions::, for more on setting the temporary directory.\n\n'$CVSPID'\nThis is the process identification (aka pid) number of the CVS\nprocess. It is often useful in the programs and/or scripts\nspecified by the 'commitinfo', 'verifymsg', 'loginfo' files.\n", "subsections": [] }, "File: cvs.info, Node: Compatibility, Next: Troubleshooting, Prev: Environment variables, Up: Top": { "content": "", "subsections": [] }, "Appendix E Compatibility between CVS Versions": { "content": "", "subsections": [] }, "The repository format is compatible going back to CVS 1.3. But see": { "content": "*note Watches Compatibility::, if you have copies of CVS 1.6 or older\nand you want to use the optional developer communication features.\n\nThe working directory format is compatible going back to CVS 1.5. It\ndid change between CVS 1.3 and CVS 1.5. If you run CVS 1.5 or newer on\na working directory checked out with CVS 1.3, CVS will convert it, but\nto go back to CVS 1.3 you need to check out a new working directory with\nCVS 1.3.\n\nThe remote protocol is interoperable going back to CVS 1.5, but no\nfurther (1.5 was the first official release with the remote protocol,\nbut some older versions might still be floating around). In many cases\nyou need to upgrade both the client and the server to take advantage of\nnew features and bug fixes, however.\n", "subsections": [] }, "File: cvs.info, Node: Troubleshooting, Next: Credits, Prev: Compatibility, Up: Top": { "content": "", "subsections": [] }, "Appendix F Troubleshooting": { "content": "", "subsections": [] }, "If you are having trouble with CVS, this appendix may help. If there is": { "content": "a particular error message which you are seeing, then you can look up\nthe message alphabetically. If not, you can look through the section on\nother problems to see if your problem is mentioned there.\n\n* Menu:\n\n* Error messages:: Partial list of CVS errors\n* Connection:: Trouble making a connection to a CVS server\n* Other problems:: Problems not readily listed by error message\n", "subsections": [] }, "File: cvs.info, Node: Error messages, Next: Connection, Up: Troubleshooting": { "content": "", "subsections": [ { "name": "F.1 Partial list of error messages", "content": "" } ] }, "Here is a partial list of error messages that you may see from CVS. It": { "content": "is not a complete list--CVS is capable of printing many, many error\nmessages, often with parts of them supplied by the operating system, but\nthe intention is to list the common and/or potentially confusing error\nmessages.\n\nThe messages are alphabetical, but introductory text such as 'cvs\nupdate: ' is not considered in ordering them.\n\nIn some cases the list includes messages printed by old versions of\nCVS (partly because users may not be sure which version of CVS they are\nusing at any particular moment).\n\n'FILE:LINE: Assertion 'TEXT' failed'\nThe exact format of this message may vary depending on your system.\nIt indicates a bug in CVS, which can be handled as described in\n*note BUGS::.\n\n'cvs COMMAND: authorization failed: server HOST rejected access'\nThis is a generic response when trying to connect to a pserver\nserver which chooses not to provide a specific reason for denying\nauthorization. Check that the username and password specified are\ncorrect and that the 'CVSROOT' specified is allowed by\n'--allow-root' or '--allow-root-regexp' in 'inetd.conf'. See *note\nPassword authenticated::.\n\n'cvs COMMAND: conflict: removed FILE was modified by second party'\nThis message indicates that you removed a file, and someone else\nmodified it. To resolve the conflict, first run 'cvs add FILE'.\nIf desired, look at the other party's modification to decide\nwhether you still want to remove it. If you don't want to remove\nit, stop here. If you do want to remove it, proceed with 'cvs\nremove FILE' and commit your removal.\n\n'cannot change permissions on temporary directory'\nOperation not permitted\nThis message has been happening in a non-reproducible, occasional\nway when we run the client/server testsuite, both on Red Hat Linux\n3.0.3 and 4.1. We haven't been able to figure out what causes it,\nnor is it known whether it is specific to Linux (or even to this\nparticular machine!). If the problem does occur on other unices,\n'Operation not permitted' would be likely to read 'Not owner' or\nwhatever the system in question uses for the unix 'EPERM' error.\nIf you have any information to add, please let us know as described\nin *note BUGS::. If you experience this error while using CVS,\nretrying the operation which produced it should work fine.\n\n'cvs [server aborted]: Cannot check out files into the repository itself'\nThe obvious cause for this message (especially for\nnon-client/server CVS) is that the CVS root is, for example,\n'/usr/local/cvsroot' and you try to check out files when you are in\na subdirectory, such as '/usr/local/cvsroot/test'. However, there\nis a more subtle cause, which is that the temporary directory on\nthe server is set to a subdirectory of the root (which is also not\nallowed). If this is the problem, set the temporary directory to\nsomewhere else, for example '/var/tmp'; see 'TMPDIR' in *note\nEnvironment variables::, for how to set the temporary directory.\n\n'cannot commit files as 'root''\nSee ''root' is not allowed to commit files'.\n\n'cannot open CVS/Entries for reading: No such file or directory'\nThis generally indicates a CVS internal error, and can be handled\nas with other CVS bugs (*note BUGS::). Usually there is a\nworkaround--the exact nature of which would depend on the situation\nbut which hopefully could be figured out.\n\n'cvs [init aborted]: cannot open CVS/Root: No such file or directory'\nThis message is harmless. Provided it is not accompanied by other\nerrors, the operation has completed successfully. This message\nshould not occur with current versions of CVS, but it is documented\nhere for the benefit of CVS 1.9 and older.\n\n'cvs server: cannot open /root/.cvsignore: Permission denied'\n'cvs [server aborted]: can't chdir(/root): Permission denied'\nSee *note Connection::.\n\n'cvs [checkout aborted]: cannot rename file FILE to CVS/,,FILE: Invalid argument'\nThis message has been reported as intermittently happening with CVS\n1.9 on Solaris 2.5. The cause is unknown; if you know more about\nwhat causes it, let us know as described in *note BUGS::.\n\n'cvs [COMMAND aborted]: cannot start server via rcmd'\nThis, unfortunately, is a rather nonspecific error message which\nCVS 1.9 will print if you are running the CVS client and it is\nhaving trouble connecting to the server. Current versions of CVS\nshould print a much more specific error message. If you get this\nmessage when you didn't mean to run the client at all, you probably\nforgot to specify ':local:', as described in *note Repository::.\n\n'ci: FILE,v: bad diff output line: Binary files - and /tmp/T2a22651 differ'\nCVS 1.9 and older will print this message when trying to check in a\nbinary file if RCS is not correctly installed. Re-read the\ninstructions that came with your RCS distribution and the INSTALL\nfile in the CVS distribution. Alternately, upgrade to a current\nversion of CVS, which checks in files itself rather than via RCS.\n\n'cvs checkout: could not check out FILE'\nWith CVS 1.9, this can mean that the 'co' program (part of RCS)\nreturned a failure. It should be preceded by another error\nmessage, however it has been observed without another error message\nand the cause is not well-understood. With the current version of\nCVS, which does not run 'co', if this message occurs without\nanother error message, it is definitely a CVS bug (*note BUGS::).\n\n'cvs [login aborted]: could not find out home directory'\nThis means that you need to set the environment variables that CVS\nuses to locate your home directory. See the discussion of 'HOME',\n'HOMEDRIVE', and 'HOMEPATH' in *note Environment variables::.\n\n'cvs update: could not merge revision REV of FILE: No such file or directory'\nCVS 1.9 and older will print this message if there was a problem\nfinding the 'rcsmerge' program. Make sure that it is in your\n'PATH', or upgrade to a current version of CVS, which does not\nrequire an external 'rcsmerge' program.\n\n'cvs [update aborted]: could not patch FILE: No such file or directory'\nThis means that there was a problem finding the 'patch' program.\nMake sure that it is in your 'PATH'. Note that despite appearances\nthe message is not referring to whether it can find FILE. If\nboth the client and the server are running a current version of\nCVS, then there is no need for an external patch program and you\nshould not see this message. But if either client or server is\nrunning CVS 1.9, then you need 'patch'.\n\n'cvs update: could not patch FILE; will refetch'\nThis means that for whatever reason the client was unable to apply\na patch that the server sent. The message is nothing to be\nconcerned about, because inability to apply the patch only slows\nthings down and has no effect on what CVS does.\n\n'dying gasps from SERVER unexpected'\nThere is a known bug in the server for CVS 1.9.18 and older which\ncan cause this. For me, this was reproducible if I used the '-t'\nglobal option. It was fixed by Andy Piper's 14 Nov 1997 change to\nsrc/filesubr.c, if anyone is curious. If you see the message, you\nprobably can just retry the operation which failed, or if you have\ndiscovered information concerning its cause, please let us know as\ndescribed in *note BUGS::.\n\n'end of file from server (consult above messages if any)'\nThe most common cause for this message is if you are using an\nexternal 'rsh' program and it exited with an error. In this case\nthe 'rsh' program should have printed a message, which will appear\nbefore the above message. For more information on setting up a CVS\nclient and server, see *note Remote repositories::.\n\n'cvs [update aborted]: EOF in key in RCS file FILE,v'\n'cvs [checkout aborted]: EOF while looking for end of string in RCS file FILE,v'\nThis means that there is a syntax error in the given RCS file.\nNote that this might be true even if RCS can read the file OK; CVS\ndoes more error checking of errors in the RCS file. That is why\nyou may see this message when upgrading from CVS 1.9 to CVS 1.10.\nThe likely cause for the original corruption is hardware, the\noperating system, or the like. Of course, if you find a case in\nwhich CVS seems to corrupting the file, by all means report it,\n(*note BUGS::). There are quite a few variations of this error\nmessage, depending on exactly where in the RCS file CVS finds the\nsyntax error.\n\n'cvs commit: Executing 'mkmodules''\nThis means that your repository is set up for a version of CVS\nprior to CVS 1.8. When using CVS 1.8 or later, the above message\nwill be preceded by\n\ncvs commit: Rebuilding administrative file database\n\nIf you see both messages, the database is being rebuilt twice,\nwhich is unnecessary but harmless. If you wish to avoid the\nduplication, and you have no versions of CVS 1.7 or earlier in use,\nremove '-i mkmodules' every place it appears in your 'modules'\nfile. For more information on the 'modules' file, see *note\nmodules::.\n\n'missing author'\nTypically this can happen if you created an RCS file with your\nusername set to empty. CVS will, bogusly, create an illegal RCS\nfile with no value for the author field. The solution is to make\nsure your username is set to a non-empty value and re-create the\nRCS file.\n\n'cvs [checkout aborted]: no such tag TAG'\nThis message means that CVS isn't familiar with the tag TAG.\nUsually the root cause is that you have mistyped a tag name.\nOcassionally this can also occur because the users creating tags do\nnot have permissions to write to the 'CVSROOT/val-tags' file (*note\nFile permissions::, for more).\n\nPrior to CVS version 1.12.10, there were a few relatively obscure\ncases where a given tag could be created in an archive file in the\nrepository but CVS would require the user to try a few other CVS\ncommands involving that tag until one was found whch caused CVS to\nupdate the 'val-tags' file, at which point the originally failing\ncommand would begin to work. This same method can be used to\nrepair a 'val-tags' file that becomes out of date due to the\npermissions problem mentioned above. This updating is only\nrequired once per tag - once a tag is listed in 'val-tags', it\nstays there.\n\nNote that using 'tag -f' to not require tag matches did not and\ndoes not override this check (*note Common options::).\n\n'*PANIC* administration files missing'\nThis typically means that there is a directory named CVS but it\ndoes not contain the administrative files which CVS puts in a CVS\ndirectory. If the problem is that you created a CVS directory via\nsome mechanism other than CVS, then the answer is simple, use a\nname other than CVS. If not, it indicates a CVS bug (*note\nBUGS::).\n\n'rcs error: Unknown option: -x,v/'\nThis message will be followed by a usage message for RCS. It means\nthat you have an old version of RCS (probably supplied with your\noperating system), as well as an old version of CVS. CVS 1.9.18\nand earlier only work with RCS version 5 and later; current\nversions of CVS do not run RCS programs.\n\n'cvs [server aborted]: received broken pipe signal'\nThis message can be caused by a loginfo program that fails to read\nall of the log information from its standard input. If you find it\nhappening in any other circumstances, please let us know as\ndescribed in *note BUGS::.\n\n''root' is not allowed to commit files'\nWhen committing a permanent change, CVS makes a log entry of who\ncommitted the change. If you are committing the change logged in\nas \"root\" (not under \"su\" or other root-priv giving program), CVS\ncannot determine who is actually making the change. As such, by\ndefault, CVS disallows changes to be committed by users logged in\nas \"root\". (You can disable this option by passing the\n'--enable-rootcommit' option to 'configure' and recompiling CVS.\nOn some systems this means editing the appropriate 'config.h' file\nbefore building CVS.)\n\n'cvs [server aborted]: Secondary out of sync with primary!'\n\nThis usually means that the version of CVS running on a secondary\nserver is incompatible with the version running on the primary\nserver (*note Write proxies::). This will not occur if the client\nsupports redirection.\n\nIt is not the version number that is significant here, but the list\nof supported requests that the servers provide to the client. For\nexample, even if both servers were the same version, if the\nsecondary was compiled with GSSAPI support and the primary was not,\nthe list of supported requests provided by the two servers would be\ndifferent and the secondary would not work as a transparent proxy\nto the primary. Conversely, even if the two servers were radically\ndifferent versions but both provided the same list of valid\nrequests to the client, the transparent proxy would succeed.\n\n'Terminated with fatal signal 11'\nThis message usually indicates that CVS (the server, if you're\nusing client/server mode) has run out of (virtual) memory.\nAlthough CVS tries to catch the error and issue a more meaningful\nmessage, there are many circumstances where that is not possible.\nIf you appear to have lots of memory available to the system, the\nproblem is most likely that you're running into a system-wide limit\non the amount of memory a single process can use or a similar\nprocess-specific limit. The mechanisms for displaying and setting\nsuch limits vary from system to system, so you'll have to consult\nan expert for your particular system if you don't know how to do\nthat.\n\n'Too many arguments!'\nThis message is typically printed by the 'log.pl' script which is\nin the 'contrib' directory in the CVS source distribution. In some\nversions of CVS, 'log.pl' has been part of the default CVS\ninstallation. The 'log.pl' script gets called from the 'loginfo'\nadministrative file. Check that the arguments passed in 'loginfo'\nmatch what your version of 'log.pl' expects. In particular, the\n'log.pl' from CVS 1.3 and older expects the log file as an argument\nwhereas the 'log.pl' from CVS 1.5 and newer expects the log file to\nbe specified with a '-f' option. Of course, if you don't need\n'log.pl' you can just comment it out of 'loginfo'.\n\n'cvs [update aborted]: unexpected EOF reading FILE,v'\nSee 'EOF in key in RCS file'.\n\n'cvs [login aborted]: unrecognized auth response from SERVER'\nThis message typically means that the server is not set up\nproperly. For example, if 'inetd.conf' points to a nonexistent cvs\nexecutable. To debug it further, find the log file which inetd\nwrites ('/var/log/messages' or whatever inetd uses on your system).\nFor details, see *note Connection::, and *note Password\nauthentication server::.\n\n'cvs commit: Up-to-date check failed for `FILE''\nThis means that someone else has committed a change to that file\nsince the last time that you did a 'cvs update'. So before\nproceeding with your 'cvs commit' you need to 'cvs update'. CVS\nwill merge the changes that you made and the changes that the other\nperson made. If it does not detect any conflicts it will report 'M\nFILE' and you are ready to 'cvs commit'. If it detects conflicts\nit will print a message saying so, will report 'C FILE', and you\nneed to manually resolve the conflict. For more details on this\nprocess see *note Conflicts example::.\n\n'Usage:\tdiff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3'\nOnly one of [exEX3] allowed\nThis indicates a problem with the installation of 'diff3' and\n'rcsmerge'. Specifically 'rcsmerge' was compiled to look for GNU\ndiff3, but it is finding unix diff3 instead. The exact text of the\nmessage will vary depending on the system. The simplest solution\nis to upgrade to a current version of CVS, which does not rely on\nexternal 'rcsmerge' or 'diff3' programs.\n\n'warning: unrecognized response `TEXT' from cvs server'\nIf TEXT contains a valid response (such as 'ok') followed by an\nextra carriage return character (on many systems this will cause\nthe second part of the message to overwrite the first part), then\nit probably means that you are using the ':ext:' access method with\na version of rsh, such as most non-unix rsh versions, which does\nnot by default provide a transparent data stream. In such cases\nyou probably want to try ':server:' instead of ':ext:'. If TEXT is\nsomething else, this may signify a problem with your CVS server.\nDouble-check your installation against the instructions for setting\nup the CVS server.\n\n'cvs commit: [TIME] waiting for USER's lock in DIRECTORY'\nThis is a normal message, not an error. See *note Concurrency::,\nfor more details.\n\n'cvs commit: warning: editor session failed'\nThis means that the editor which CVS is using exits with a nonzero\nexit status. Some versions of vi will do this even when there was\nnot a problem editing the file. If so, point the 'CVSEDITOR'\nenvironment variable to a small script such as:\n\n#!/bin/sh\nvi $*\nexit 0\n\n'cvs update: warning: FILE was lost'\nThis means that the working copy of FILE has been deleted but it\nhas not been removed from CVS. This is nothing to be concerned\nabout, the update will just recreate the local file from the\nrepository. (This is a convenient way to discard local changes to\na file: just delete it and then run 'cvs update'.)\n\n'cvs update: warning: FILE is not (any longer) pertinent'\nThis means that the working copy of FILE has been deleted, it has\nnot been removed from CVS in the current working directory, but it\nhas been removed from CVS in some other working directory. This is\nnothing to be concerned about, the update would have removed the\nlocal file anyway.\n", "subsections": [] }, "File: cvs.info, Node: Connection, Next: Other problems, Prev: Error messages, Up: Troubleshooting": { "content": "", "subsections": [ { "name": "F.2 Trouble making a connection to a CVS server", "content": "" } ] }, "This section concerns what to do if you are having trouble making a": { "content": "connection to a CVS server. If you are running the CVS command line\nclient running on Windows, first upgrade the client to CVS 1.9.12 or\nlater. The error reporting in earlier versions provided much less\ninformation about what the problem was. If the client is non-Windows,\nCVS 1.9 should be fine.\n\nIf the error messages are not sufficient to track down the problem,\nthe next steps depend largely on which access method you are using.\n\n':ext:'\nTry running the rsh program from the command line. For example:\n\"rsh servername cvs -v\" should print CVS version information. If\nthis doesn't work, you need to fix it before you can worry about\nCVS problems.\n\n':server:'\nYou don't need a command line rsh program to use this access\nmethod, but if you have an rsh program around, it may be useful as\na debugging tool. Follow the directions given for :ext:.\n\n':pserver:'\nErrors along the lines of \"connection refused\" typically indicate\nthat inetd isn't even listening for connections on port 2401\nwhereas errors like \"connection reset by peer\", \"received broken\npipe signal\", \"recv() from server: EOF\", or \"end of file from\nserver\" typically indicate that inetd is listening for connections\nbut is unable to start CVS (this is frequently caused by having an\nincorrect path in 'inetd.conf' or by firewall software rejecting\nthe connection). \"unrecognized auth response\" errors are caused by\na bad command line in 'inetd.conf', typically an invalid option or\nforgetting to put the 'pserver' command at the end of the line.\nAnother less common problem is invisible control characters that\nyour editor \"helpfully\" added without you noticing.\n\nOne good debugging tool is to \"telnet servername 2401\". After\nconnecting, send any text (for example \"foo\" followed by return).\nIf CVS is working correctly, it will respond with\n\ncvs [pserver aborted]: bad auth protocol start: foo\n\nIf instead you get:\n\nUsage: cvs [cvs-options] command [command-options-and-arguments]\n...\n\nthen you're missing the 'pserver' command at the end of the line in\n'inetd.conf'; check to make sure that the entire command is on one\nline and that it's complete.\n\nLikewise, if you get something like:\n\nUnknown command: `pserved'\n\nCVS commands are:\nadd Add a new file/directory to the repository\n...\n\nthen you've misspelled 'pserver' in some way. If it isn't obvious,\ncheck for invisible control characters (particularly carriage\nreturns) in 'inetd.conf'.\n\nIf it fails to work at all, then make sure inetd is working right.\nChange the invocation in 'inetd.conf' to run the echo program\ninstead of cvs. For example:\n\n2401 stream tcp nowait root /bin/echo echo hello\n\nAfter making that change and instructing inetd to re-read its\nconfiguration file, \"telnet servername 2401\" should show you the\ntext hello and then the server should close the connection. If\nthis doesn't work, you need to fix it before you can worry about\nCVS problems.\n\nOn AIX systems, the system will often have its own program trying\nto use port 2401. This is AIX's problem in the sense that port\n2401 is registered for use with CVS. I hear that there is an AIX\npatch available to address this problem.\n\nAnother good debugging tool is the '-d' (debugging) option to\ninetd. Consult your system documentation for more information.\n\nIf you seem to be connecting but get errors like:\n\ncvs server: cannot open /root/.cvsignore: Permission denied\ncvs [server aborted]: can't chdir(/root): Permission denied\n\nthen you probably haven't specified '-f' in 'inetd.conf'. (In\nreleases prior to CVS 1.11.1, this problem can be caused by your\nsystem setting the '$HOME' environment variable for programs being\nrun by inetd. In this case, you can either have inetd run a shell\nscript that unsets '$HOME' and then runs CVS, or you can use 'env'\nto run CVS with a pristine environment.)\n\nIf you can connect successfully for a while but then can't, you've\nprobably hit inetd's rate limit. (If inetd receives too many\nrequests for the same service in a short period of time, it assumes\nthat something is wrong and temporarily disables the service.)\nCheck your inetd documentation to find out how to adjust the rate\nlimit (some versions of inetd have a single rate limit, others\nallow you to set the limit for each service separately.)\n", "subsections": [] }, "File: cvs.info, Node: Other problems, Prev: Connection, Up: Troubleshooting": { "content": "", "subsections": [ { "name": "F.3 Other common problems", "content": "Here is a list of problems which do not fit into the above categories.\nThey are in no particular order.\n\n* On Windows, if there is a 30 second or so delay when you run a CVS\ncommand, it may mean that you have your home directory set to\n'C:/', for example (see 'HOMEDRIVE' and 'HOMEPATH' in *note\nEnvironment variables::). CVS expects the home directory to not\nend in a slash, for example 'C:' or 'C:\\cvs'.\n\n* If you are running CVS 1.9.18 or older, and 'cvs update' finds a\nconflict and tries to merge, as described in *note Conflicts\nexample::, but doesn't tell you there were conflicts, then you may\nhave an old version of RCS. The easiest solution probably is to\nupgrade to a current version of CVS, which does not rely on\nexternal RCS programs.\n" } ] }, "File: cvs.info, Node: Credits, Next: BUGS, Prev: Troubleshooting, Up: Top": { "content": "", "subsections": [] }, "Appendix G Credits": { "content": "Roland Pesch, then of Cygnus Support wrote the manual\npages which were distributed with CVS 1.3. Much of their text was\ncopied into this manual. He also read an early draft of this manual and\ncontributed many ideas and corrections.\n\nThe mailing-list 'info-cvs' is sometimes informative. I have\nincluded information from postings made by the following persons: David\nG. Grubbs .\n\nSome text has been extracted from the man pages for RCS.\n\nThe CVS FAQ by David G. Grubbs has provided useful material. The FAQ\nis no longer maintained, however, and this manual is about the closest\nthing there is to a successor (with respect to documenting how to use\nCVS, at least).\n\nIn addition, the following persons have helped by telling me about\nmistakes I've made:\n\nRoxanne Brunskill ,\nKathy Dyer ,\nKarl Pingle ,\nThomas A Peterson ,\nInge Wallin ,\nDirk Koschuetzki \nand Michael Brown .\n\nThe list of contributors here is not comprehensive; for a more\ncomplete list of who has contributed to this manual see the file\n'doc/ChangeLog' in the CVS source distribution.\n\nMirBSD is the de-facto (if not de-iure yet) new upstream of GNU CVS\nsince 2012 or so; this version is provided in Debian as well.\nResponsible is:\n\nmirabilos \n\nCVS Homepage: \n", "subsections": [] }, "File: cvs.info, Node: BUGS, Next: CVS command list, Prev: Credits, Up: Top": { "content": "", "subsections": [] }, "Appendix H Dealing with bugs in CVS or this manual": { "content": "Neither CVS nor this manual is perfect, and they probably never will be.", "subsections": [] }, "If you are having trouble using CVS, or think you have found a bug,": { "content": "there are a number of things you can do about it. Note that if the\nmanual is unclear, that can be considered a bug in the manual, so these\nproblems are often worth doing something about as well as problems with\nCVS itself.\n\n* If you want someone to help you and fix bugs that you report, there\nare companies which will do that for a fee. One such company is:\n\nXimbiot\n319 S. River St.\nHarrisburg, PA 17104-1657\nUSA\nEmail: info@ximbiot.com\nPhone: (717) 579-6168\nFax: (717) 234-3125\n\n\n\n* If you got CVS through a distributor, such as an operating system\nvendor or a vendor of freeware CD-ROMs, you may wish to see whether\nthe distributor provides support. Often, they will provide no\nsupport or minimal support, but this may vary from distributor to\ndistributor.\n\n* If you have the skills and time to do so, you may wish to fix the\nbug yourself. If you wish to submit your fix for inclusion in\nfuture releases of CVS, see the file HACKING in the CVS source\ndistribution. It contains much more information on the process of\nsubmitting fixes.\n\n* There may be resources on the net which can help. A good place to\nstart is:\n\n\n\nIf you are so inspired, increasing the information available on the\nnet is likely to be appreciated. For example, before the standard\nCVS distribution worked on Windows 95, there was a web page with\nsome explanation and patches for running CVS on Windows 95, and\nvarious people helped out by mentioning this page on mailing lists\nor newsgroups when the subject came up.\n\n* It is also possible to report bugs to . Note\nthat someone may or may not want to do anything with your bug\nreport--if you need a solution consider one of the options\nmentioned above. People probably do want to hear about bugs which\nare particularly severe in consequences and/or easy to fix,\nhowever. You can also increase your odds by being as clear as\npossible about the exact nature of the bug and any other relevant\ninformation. The way to report bugs is to send email to\n. Note that submissions to\n may be distributed under the terms of the GNU\nGeneral Public License, so if you don't like this, don't submit\nthem. There is usually no justification for sending mail directly\nto one of the CVS maintainers rather than to ;\nthose maintainers who want to hear about such bug reports read\n. Also note that sending a bug report to other\nmailing lists or newsgroups is not a substitute for sending it to\n. It is fine to discuss CVS bugs on whatever\nforum you prefer, but there are not necessarily any maintainers\nreading bug reports sent anywhere except .\n\nPeople often ask if there is a list of known bugs or whether a\nparticular bug is a known one. The file BUGS in the CVS source\ndistribution is one list of known bugs, but it doesn't necessarily try\nto be comprehensive. Perhaps there will never be a comprehensive,\ndetailed list of known bugs.\n", "subsections": [] }, "File: cvs.info, Node: CVS command list, Next: Index, Prev: BUGS, Up: Top": { "content": "", "subsections": [] }, "Appendix I Alphabetical list of all CVS commands": { "content": "*Note the introduction into the manual: Cederqvist.\n\n* Menu:\n\n* add:: Add a new file/directory to the repository\n* admin:: Administration front-end for RCS\n* annotate:: Show last revision where each line was modified\n* checkout:: Checkout sources for editing\n* commit:: Check files into the repository\n* diff:: Show differences between revisions\n* edit:: Get ready to edit a watched file\n* editors:: See who is editing a watched file\n* export:: Export sources from CVS, similar to checkout\n* history:: Show repository access history\n* import:: Import sources into CVS, using vendor branches\n* init:: Create a CVS repository\n* kserver:: Act in Kerberos server mode\n* log:: Print out history information for files\n* login:: Prompt for password for authenticating server\n* logout:: Removes entry in .cvspass for remote repository\n* ls:: List files available from CVS\n* pserver:: Act in password server mode\n* rannotate:: Show last revision where each line of module was modified\n* rdiff:: Create 'patch' format diffs between revisions\n* release:: Indicate that a work subdirectory is no longer in use\n* remove:: Remove an entry from the repository\n* rlog:: Print out history information for a module\n* rls:: List files in a module\n* rtag:: Add a symbolic tag to a module\n* server:: Act in server mode\n* suck:: Download RCS ,v file raw\n* status:: Display status information on checked out files\n* tag:: Add a symbolic tag to checked out version of files\n* unedit:: Undo an edit command\n* update:: Bring work tree in sync with repository\n* version:: Show current CVS version(s)\n* watch:: Set watches\n* watchers:: See who is watching a file\n", "subsections": [] }, "File: cvs.info, Node: Index, Prev: CVS command list, Up: Top": { "content": "", "subsections": [] }, "Index": { "content": "* Menu:\n\n* files (VMS): update output. (line 49)\n* -a, in modules file: Alias modules. (line 6)\n* -d, in modules file: Module options. (line 9)\n* -e, in modules file: Module options. (line 12)\n* -e, in modules file <1>: Module program options.\n(line 6)\n* -j (merging branches): Merging a branch. (line 6)\n* -j (merging branches), and keyword substitution: Merging and keywords.\n(line 6)\n* -k (keyword substitution): Substitution modes. (line 6)\n* -kk, to avoid conflicts during a merge: Merging and keywords.\n(line 6)\n* -o, in modules file: Module options. (line 16)\n* -o, in modules file <1>: Module program options.\n(line 6)\n* -s, in modules file: Module options. (line 22)\n* -t, in modules file: Module options. (line 30)\n* -t, in modules file <1>: Module program options.\n(line 6)\n* !, in modules file: Excluding directories.\n(line 6)\n* .# files: update output. (line 49)\n* .bashrc, setting CVSROOT in: Specifying a repository.\n(line 12)\n* .cshrc, setting CVSROOT in: Specifying a repository.\n(line 12)\n* .cvsrc file: ~/.cvsrc. (line 6)\n* .profile, setting CVSROOT in: Specifying a repository.\n(line 12)\n* .tcshrc, setting CVSROOT in: Specifying a repository.\n(line 12)\n* /usr/local/cvsroot, as example repository: Repository. (line 6)\n* &, in modules file: Ampersand modules. (line 6)\n* #cvs.lock, removing: Concurrency. (line 11)\n* #cvs.lock, technical details: Locks. (line 6)\n* #cvs.pfl, technical details: Locks. (line 6)\n* #cvs.rfl, and backups: Backing up. (line 10)\n* #cvs.rfl, removing: Concurrency. (line 11)\n* #cvs.rfl, technical details: Locks. (line 6)\n* #cvs.tfl: Locks. (line 14)\n* #cvs.wfl, removing: Concurrency. (line 11)\n* #cvs.wfl, technical details: Locks. (line 6)\n* <<<<<<<: Conflicts example. (line 96)\n* =======: Conflicts example. (line 96)\n* >>>>>>>: Conflicts example. (line 96)\n* Abandoning work: Editing files. (line 42)\n* abbreviations for months: Calendar date items. (line 38)\n* Access a branch: Accessing branches. (line 6)\n* add (subcommand): Adding files. (line 34)\n* Adding a tag: Tags. (line 45)\n* Adding files: Adding files. (line 6)\n* Admin (subcommand): admin. (line 6)\n* Admin commands, logging: postadmin. (line 6)\n* Administrative files (intro): Intro administrative files.\n(line 6)\n* Administrative files (reference): Administrative files.\n(line 6)\n* Administrative files, editing them: Intro administrative files.\n(line 33)\n* Alias modules: Alias modules. (line 6)\n* ALL keyword, in lieu of regular expressions in script hooks: syntax.\n(line 12)\n* Ampersand modules: Ampersand modules. (line 6)\n* annotate (subcommand): annotate. (line 6)\n* Atomic transactions, lack of: Concurrency. (line 27)\n* Attic: Attic. (line 6)\n* Authenticated client, using: Password authentication client.\n(line 6)\n* Authenticating server, setting up: Password authentication server.\n(line 10)\n* Authentication, stream: Global options. (line 16)\n* Author keyword: Keyword list. (line 8)\n* authors of getdate: Authors of getdate. (line 6)\n* Automatically ignored files: cvsignore. (line 23)\n* Avoiding editor invocation: Common options. (line 86)\n* Backing up, repository: Backing up. (line 6)\n* Base directory, in CVS directory: Working directory storage.\n(line 176)\n* BASE, as reserved tag name: Tags. (line 25)\n* BASE, special date: Common options. (line 121)\n* BASE, special tag: Common options. (line 121)\n* Baserev file, in CVS directory: Working directory storage.\n(line 182)\n* Baserev.tmp file, in CVS directory: Working directory storage.\n(line 190)\n* beginning of time, for POSIX: Seconds since the Epoch.\n(line 15)\n* Bellovin, Steven M.: Authors of getdate. (line 6)\n* Berets, Jim: Authors of getdate. (line 6)\n* Berry, K.: Authors of getdate. (line 14)\n* Bill of materials: Builds. (line 25)\n* Binary files: Binary files. (line 6)\n* Branch merge example: Merging a branch. (line 15)\n* Branch number: Revision numbers. (line 6)\n* Branch number <1>: Branches and revisions.\n(line 6)\n* Branch tags, deleting: Modifying tags. (line 19)\n* Branch tags, moving: Modifying tags. (line 37)\n* Branch, accessing: Accessing branches. (line 6)\n* Branch, check out: Accessing branches. (line 6)\n* Branch, creating a: Creating a branch. (line 6)\n* Branch, identifying: Accessing branches. (line 6)\n* Branch, retrieving: Accessing branches. (line 6)\n* Branch, vendor-: Tracking sources. (line 10)\n* Branches motivation: Branches motivation. (line 6)\n* Branches, copying changes between: Branching and merging.\n(line 6)\n* Branches, sticky: Accessing branches. (line 37)\n* Branching: Branching and merging.\n(line 6)\n* Bringing a file up to date: Updating a file. (line 6)\n* Bugs in this manual or CVS: BUGS. (line 6)\n* Bugs, reporting: BUGS. (line 13)\n* Builds: Builds. (line 6)\n* calendar date item: Calendar date items. (line 6)\n* case, ignored in dates: General date syntax. (line 65)\n* Changes, copying between branches: Branching and merging.\n(line 6)\n* Changing a log message: admin options. (line 73)\n* Check out a branch: Accessing branches. (line 6)\n* Checked out copy, keeping: Keeping a checked out copy.\n(line 6)\n* Checking out source: Getting the source. (line 6)\n* checkout (subcommand): checkout. (line 6)\n* Checkout program: Module options. (line 16)\n* Checkout, as term for getting ready to edit: Editing files. (line 6)\n* Checkout, example: Getting the source. (line 6)\n* checkoutlist: checkoutlist. (line 6)\n* Choosing, reserved or unreserved checkouts: Choosing a model.\n(line 6)\n* Cleaning up: Cleaning up. (line 6)\n* Client/Server Operation: Remote repositories. (line 6)\n* Client/Server Operation, port specification: Remote repositories.\n(line 6)\n* Client/Server Operation, port specification <1>: Password authentication server.\n(line 10)\n* co (subcommand): checkout. (line 6)\n* Command reference: Invoking CVS. (line 6)\n* Command structure: Structure. (line 6)\n* Comment leader: admin options. (line 27)\n* comments, in dates: General date syntax. (line 65)\n* commit (subcommand): commit. (line 6)\n* commit files, see Info files: commit files. (line 6)\n* COMMITID, internal variable: Variables. (line 50)\n* COMMITID, internal variable <1>: Variables. (line 56)\n* commitinfo: commitinfo. (line 6)\n* commitinfo (admin file): commitinfo. (line 6)\n* commitinfo (admin file), exit status: commitinfo. (line 29)\n* commitinfo (admin file), updating legacy repositories: commitinfo.\n(line 22)\n* commitinfo, command environment: commitinfo. (line 33)\n* commitinfo, working directory: commitinfo. (line 33)\n* Commits, administrative support files: commit files. (line 6)\n* Commits, precommit verification of: commitinfo. (line 6)\n* Committing changes to files: Committing your changes.\n(line 6)\n* Committing, when to: When to commit. (line 6)\n* Common options: Common options. (line 6)\n* Common syntax of info files, format strings: syntax. (line 35)\n* Common syntax of info files, updating legacy repositories: Updating Commit Files.\n(line 6)\n* compatibility notes, commitinfo admin file: commitinfo. (line 22)\n* compatibility notes, config admin file: config. (line 244)\n* compatibility notes, loginfo admin file: loginfo. (line 47)\n* compatibility notes, taginfo admin file: taginfo. (line 38)\n* compatibility notes, verifymsg admin file: verifymsg. (line 32)\n* Compatibility, between CVS versions: Compatibility. (line 6)\n* Compression: Global options. (line 164)\n* Compression <1>: Invoking CVS. (line 84)\n* Compression levels, restricting on server: config. (line 148)\n* COMSPEC, environment variable: Environment variables.\n(line 141)\n* config (admin file), import: config. (line 90)\n* config (admin file), updating legacy repositories: config. (line 244)\n* config, in CVSROOT: config. (line 6)\n* configuration file: server & pserver. (line 24)\n* configuration file <1>: config. (line 6)\n* Configuring keyword expansion: Configuring keyword expansion.\n(line 6)\n* Conflict markers: Conflicts example. (line 96)\n* Conflict resolution: Conflicts example. (line 100)\n* Conflicts (merge example): Conflicts example. (line 68)\n* connection method options: The connection method.\n(line 16)\n* Contributors (CVS program): What is CVS?. (line 28)\n* Contributors (manual): Credits. (line 6)\n* Copying a repository: Moving a repository. (line 6)\n* Copying changes: Branching and merging.\n(line 6)\n* Correcting a log message: admin options. (line 73)\n* Creating a branch: Creating a branch. (line 6)\n* Creating a project: Starting a new project.\n(line 6)\n* Creating a repository: Creating a repository.\n(line 6)\n* Credits (CVS program): What is CVS?. (line 28)\n* Credits (manual): Credits. (line 6)\n* CVS 1.6, and watches: Watches Compatibility.\n(line 6)\n* CVS command structure: Structure. (line 6)\n* CVS directory, in repository: CVS in repository. (line 6)\n* CVS directory, in working directory: Working directory storage.\n(line 6)\n* CVS passwd file: Password authentication server.\n(line 70)\n* CVSCLIENTLOG, environment variable: Environment variables.\n(line 104)\n* CVSCLIENTPORT: Environment variables.\n(line 87)\n* CVSIGNOREREMOTEROOT, environment variable: Environment variables.\n(line 127)\n* CVSLOCALBRANCHNUM, environment variable: Environment variables.\n(line 133)\n* CVSPASSFILE, environment variable: Password authentication client.\n(line 46)\n* CVSPID, environment variable: Environment variables.\n(line 149)\n* CVSPROXYPORT: The connection method.\n(line 26)\n* CVSPROXYPORT <1>: Environment variables.\n(line 93)\n* CVSRCMDPORT, environment variable: Environment variables.\n(line 99)\n* CVSRSH method option: The connection method.\n(line 51)\n* CVSRSH, environment variable: Environment variables.\n(line 69)\n* CVSSECONDARYLOG, environment variable: Environment variables.\n(line 110)\n* CVSSERVER method option: The connection method.\n(line 65)\n* CVSSERVERLOG, environment variable: Environment variables.\n(line 116)\n* CVSSERVERSLEEP, environment variable: Environment variables.\n(line 122)\n* CVSSERVER, and fork method: Connecting via fork. (line 24)\n* CVSSERVER, environment variable: Connecting via rsh. (line 22)\n* CVSUSER, environment variable: Variables. (line 83)\n* CVS, history of: What is CVS?. (line 28)\n* CVS, introduction to: What is CVS?. (line 6)\n* CVS, versions of: Compatibility. (line 6)\n* CVS/Base directory: Working directory storage.\n(line 176)\n* CVS/Baserev file: Working directory storage.\n(line 182)\n* CVS/Baserev.tmp file: Working directory storage.\n(line 190)\n* CVS/Entries file: Working directory storage.\n(line 60)\n* CVS/Entries.Backup file: Working directory storage.\n(line 143)\n* CVS/Entries.Log file: Working directory storage.\n(line 120)\n* CVS/Entries.Static file: Working directory storage.\n(line 148)\n* CVS/Notify file: Working directory storage.\n(line 166)\n* CVS/Notify.tmp file: Working directory storage.\n(line 171)\n* CVS/Repository file: Working directory storage.\n(line 32)\n* CVS/Root file: Specifying a repository.\n(line 25)\n* CVS/Tag file: Working directory storage.\n(line 155)\n* CVS/Template file: Working directory storage.\n(line 196)\n* cvsadmin: admin. (line 16)\n* CVSEDITOR, environment variable: Committing your changes.\n(line 17)\n* CVSEDITOR, environment variable <1>: Environment variables.\n(line 49)\n* CVSEDITOR, internal variable: Variables. (line 37)\n* CVSHeader keyword: Keyword list. (line 11)\n* cvsignore (admin file), global: cvsignore. (line 6)\n* CVSIGNORE, environment variable: Environment variables.\n(line 10)\n* CVSREAD, environment variable: Environment variables.\n(line 18)\n* CVSREAD, overriding: Global options. (line 148)\n* CVSREADONLYFS, environment variable: Environment variables.\n(line 24)\n* cvsroot: Repository. (line 6)\n* CVSROOT (file): Administrative files.\n(line 6)\n* CVSROOT, environment variable: Specifying a repository.\n(line 12)\n* CVSROOT, internal variable: Variables. (line 26)\n* CVSROOT, module name: Intro administrative files.\n(line 6)\n* CVSROOT, multiple repositories: Multiple repositories.\n(line 6)\n* CVSROOT, overriding: Global options. (line 52)\n* CVSROOT, storage of files: CVSROOT storage. (line 6)\n* CVSROOT/config: config. (line 6)\n* CVSROOT/Emptydir directory: Working directory storage.\n(line 58)\n* CVSROOT/val-tags file, and read-only access to projects: File permissions.\n(line 26)\n* CVSROOT/val-tags file, forcing tags into: Error messages. (line 198)\n* CVSUMASK, environment variable: File permissions. (line 34)\n* cvswrappers (admin file): Wrappers. (line 6)\n* CVSWRAPPERS, environment variable: Wrappers. (line 6)\n* CVSWRAPPERS, environment variable <1>: Environment variables.\n(line 14)\n* date format, ISO 8601: Calendar date items. (line 30)\n* date input formats: Date input formats. (line 6)\n* Date keyword: Keyword list. (line 25)\n* Dates: Common options. (line 18)\n* day of week item: Day of week items. (line 6)\n* Dead state: Attic. (line 17)\n* Decimal revision number: Revision numbers. (line 6)\n* DEFAULT keyword, in lieu of regular expressions in script hooks: syntax.\n(line 12)\n* Defining a module: Defining the module. (line 6)\n* Defining modules (intro): Intro administrative files.\n(line 6)\n* Defining modules (reference manual): modules. (line 6)\n* Deleting branch tags: Modifying tags. (line 19)\n* Deleting files: Removing files. (line 6)\n* Deleting revisions: admin options. (line 95)\n* Deleting sticky tags: Sticky tags. (line 31)\n* Deleting tags: Modifying tags. (line 19)\n* Descending directories: Recursive behavior. (line 6)\n* Device nodes: Special Files. (line 6)\n* Diff: Viewing differences. (line 6)\n* diff (subcommand): diff. (line 6)\n* Differences, merging: Merging two revisions.\n(line 6)\n* Directories, moving: Moving directories. (line 6)\n* Directories, removing: Removing directories.\n(line 6)\n* Directory, descending: Recursive behavior. (line 6)\n* Disjoint repositories: Multiple repositories.\n(line 6)\n* displacement of dates: Relative items in date strings.\n(line 6)\n* Distributing log messages: loginfo. (line 6)\n* driver.c (merge example): Conflicts example. (line 6)\n* edit (subcommand): Editing files. (line 13)\n* Editing administrative files: Intro administrative files.\n(line 33)\n* Editing the modules file: Defining the module. (line 6)\n* Editor, avoiding invocation of: Common options. (line 86)\n* EDITOR, environment variable: Committing your changes.\n(line 17)\n* EDITOR, environment variable <1>: Environment variables.\n(line 50)\n* EDITOR, internal variable: Variables. (line 38)\n* EDITOR, overriding: Global options. (line 57)\n* editors (subcommand): Watch information. (line 15)\n* Eggert, Paul: Authors of getdate. (line 6)\n* emerge: Conflicts example. (line 139)\n* Emptydir, in CVSROOT directory: Working directory storage.\n(line 58)\n* Encryption: Global options. (line 154)\n* Entries file, in CVS directory: Working directory storage.\n(line 60)\n* Entries.Backup file, in CVS directory: Working directory storage.\n(line 143)\n* Entries.Log file, in CVS directory: Working directory storage.\n(line 120)\n* Entries.Static file, in CVS directory: Working directory storage.\n(line 148)\n* Environment variables: Environment variables.\n(line 6)\n* environment variables, passed to administrative files: Variables.\n(line 82)\n* epoch, for POSIX: Seconds since the Epoch.\n(line 15)\n* Errors, reporting: BUGS. (line 13)\n* Example of a work-session: A sample session. (line 6)\n* Example of merge: Conflicts example. (line 6)\n* Example, branch merge: Merging a branch. (line 15)\n* Excluding directories, in modules file: Excluding directories.\n(line 6)\n* Exit status, of commitinfo: commitinfo. (line 29)\n* Exit status, of CVS: Exit status. (line 6)\n* Exit status, of editor: Error messages. (line 330)\n* Exit status, of taginfo admin file: taginfo. (line 45)\n* Exit status, of verifymsg: verifymsg. (line 44)\n* export (subcommand): export. (line 6)\n* Export program: Module options. (line 12)\n* ext method, setting up: Connecting via rsh. (line 35)\n* ext method, troubleshooting: Connection. (line 16)\n* Fetching source: Getting the source. (line 6)\n* File had conflicts on merge: File status. (line 46)\n* File locking: Multiple developers. (line 6)\n* File permissions, general: File permissions. (line 6)\n* File permissions, Windows-specific: Windows permissions. (line 6)\n* File status: File status. (line 6)\n* Files, moving: Moving files. (line 6)\n* Files, reference manual: Administrative files.\n(line 6)\n* Fixing a log message: admin options. (line 73)\n* Forcing a tag match: Common options. (line 43)\n* fork method, setting up: Connecting via fork. (line 6)\n* fork, access method: Connecting via fork. (line 6)\n* Form for log message: rcsinfo. (line 6)\n* Format of CVS commands: Structure. (line 6)\n* format strings: syntax. (line 35)\n* format strings, commitinfo admin file: commitinfo. (line 16)\n* format strings, common syntax: syntax. (line 35)\n* format strings, config admin file: config. (line 244)\n* format strings, loginfo admin file: loginfo. (line 32)\n* format strings, postadmin admin file: postadmin. (line 12)\n* format strings, postproxy admin file: postproxy. (line 23)\n* format strings, posttag admin file: posttag. (line 12)\n* format strings, postwatch admin file: postwatch. (line 13)\n* format strings, preproxy admin file: preproxy. (line 20)\n* format strings, taginfo admin file: taginfo. (line 12)\n* format strings, verifymsg admin file: verifymsg. (line 20)\n* general date syntax: General date syntax. (line 6)\n* Getting started: A sample session. (line 6)\n* Getting the source: Getting the source. (line 6)\n* Global cvsignore: cvsignore. (line 6)\n* Global options: Global options. (line 6)\n* Group, UNIX file permissions, in repository: File permissions.\n(line 6)\n* gserver (client/server connection method), port specification: Remote repositories.\n(line 6)\n* gserver (client/server connection method), port specification <1>: Password authentication server.\n(line 10)\n* gserver method, setting up: GSSAPI authenticated.\n(line 6)\n* GSSAPI: GSSAPI authenticated.\n(line 6)\n* Gzip: Global options. (line 164)\n* Gzip <1>: Invoking CVS. (line 84)\n* Hard links: Special Files. (line 6)\n* HEAD, as reserved tag name: Tags. (line 25)\n* HEAD, special tag: Common options. (line 121)\n* Header keyword: Keyword list. (line 34)\n* history (subcommand): history. (line 6)\n* History browsing: History browsing. (line 6)\n* History file: history file. (line 6)\n* History files: Repository files. (line 68)\n* History of CVS: What is CVS?. (line 28)\n* HistoryLogPath, in CVSROOT/config: config. (line 61)\n* HistorySearchPath, in CVSROOT/config: config. (line 70)\n* HOME, environment variable: Environment variables.\n(line 60)\n* HOMEDRIVE, environment variable: Environment variables.\n(line 62)\n* HOMEPATH, environment variable: Environment variables.\n(line 61)\n* HTTP proxies, connecting via: The connection method.\n(line 26)\n* Id keyword: Keyword list. (line 40)\n* Ident (shell command): Using keywords. (line 19)\n* Identifying a branch: Accessing branches. (line 6)\n* Identifying files: Keyword substitution.\n(line 6)\n* Ignored files: cvsignore. (line 23)\n* Ignoring files: cvsignore. (line 6)\n* import (subcommand): import. (line 6)\n* import, config admin file: config. (line 90)\n* Importing files: From files. (line 6)\n* Importing files, from other version control systems: From other version control systems.\n(line 6)\n* Importing modules: First import. (line 6)\n* ImportNewFilesToVendorBranchOnly, in CVSROOT/config: config.\n(line 90)\n* Index: Index. (line 6)\n* inetd, configuring for pserver: Password authentication server.\n(line 10)\n* info files: Trigger Scripts. (line 6)\n* info files, commitinfo: commitinfo. (line 6)\n* info files, common syntax: syntax. (line 6)\n* info files, common syntax, format strings: syntax. (line 35)\n* info files, common syntax, updating legacy repositories: Updating Commit Files.\n(line 6)\n* info files, precommit verification of commits: commitinfo. (line 6)\n* info files, security: Trigger Script Security.\n(line 6)\n* Informing others: Informing others. (line 6)\n* init (subcommand): Creating a repository.\n(line 43)\n* Installed images (VMS): File permissions. (line 58)\n* Internal variables: Variables. (line 6)\n* Introduction to CVS: What is CVS?. (line 6)\n* Invoking CVS: Invoking CVS. (line 6)\n* ISO 8601 date format: Calendar date items. (line 30)\n* Isolation: History browsing. (line 6)\n* items in date strings: General date syntax. (line 6)\n* Join: Merging a branch. (line 13)\n* Keeping a checked out copy: Keeping a checked out copy.\n(line 6)\n* Kerberos, using gserver method: GSSAPI authenticated.\n(line 6)\n* Kerberos, using kerberized rsh: Connecting via rsh. (line 35)\n* Kerberos, using kserver method: Kerberos authenticated.\n(line 6)\n* Keyword expansion: Keyword substitution.\n(line 6)\n* Keyword List: Keyword list. (line 6)\n* Keyword substitution: Keyword substitution.\n(line 6)\n* Keyword substitution, and merging: Merging and keywords.\n(line 6)\n* Keyword substitution, changing modes: Substitution modes. (line 6)\n* KeywordExpand, in CVSROOT/config: config. (line 97)\n* Kflag: Substitution modes. (line 6)\n* kinit: Kerberos authenticated.\n(line 27)\n* Known bugs in this manual or CVS: BUGS. (line 70)\n* kserver (client/server connection method), port specification: Remote repositories.\n(line 6)\n* kserver (client/server connection method), port specification <1>: Password authentication server.\n(line 10)\n* kserver method, setting up: Kerberos authenticated.\n(line 6)\n* language, in dates: General date syntax. (line 35)\n* language, in dates <1>: General date syntax. (line 39)\n* Layout of repository: Repository. (line 6)\n* Left-hand options: Global options. (line 6)\n* Linear development: Revision numbers. (line 6)\n* Link, symbolic, importing: import output. (line 23)\n* List, mailing list: What is CVS?. (line 44)\n* Local keyword: Keyword list. (line 102)\n* local method, setting up: Repository. (line 19)\n* LocalKeyword, in CVSROOT/config: config. (line 104)\n* Locally Added: File status. (line 19)\n* Locally Modified: File status. (line 16)\n* Locally Removed: File status. (line 23)\n* LockDir, in CVSROOT/config: config. (line 109)\n* Locker keyword: Keyword list. (line 49)\n* Locking files: Multiple developers. (line 6)\n* Locks, cvs, and backups: Backing up. (line 10)\n* Locks, cvs, introduction: Concurrency. (line 6)\n* Locks, cvs, technical details: Locks. (line 6)\n* log (subcommand): log. (line 6)\n* Log information, saving: history file. (line 6)\n* Log keyword: Keyword list. (line 53)\n* Log keyword, configuring substitution behavior: Keyword list.\n(line 53)\n* Log keyword, configuring substitution behavior <1>: config. (line 136)\n* Log keyword, configuring substitution behavior <2>: config. (line 233)\n* Log message entry: Committing your changes.\n(line 6)\n* Log message template: rcsinfo. (line 6)\n* Log message, correcting: admin options. (line 73)\n* Log message, verifying: verifymsg. (line 6)\n* Log messages: loginfo. (line 6)\n* logging, commits: verifymsg. (line 6)\n* logging, commits <1>: loginfo. (line 6)\n* logging, commits <2>: rcsinfo. (line 6)\n* LogHistory, in CVSROOT/config: config. (line 128)\n* Login (subcommand): Password authentication client.\n(line 6)\n* loginfo (admin file): loginfo. (line 6)\n* loginfo (admin file), updating legacy repositories: loginfo.\n(line 47)\n* LOGNAME, environment variable: Variables. (line 90)\n* Logout (subcommand): Password authentication client.\n(line 70)\n* ls (subcommand): ls & rls. (line 6)\n* MacKenzie, David: Authors of getdate. (line 6)\n* Mail, automatic mail on commit: Informing others. (line 6)\n* Mailing list: What is CVS?. (line 44)\n* Mailing log messages: loginfo. (line 6)\n* Main trunk and branches: Branching and merging.\n(line 6)\n* make: Builds. (line 6)\n* Many repositories: Multiple repositories.\n(line 6)\n* Markers, conflict: Conflicts example. (line 96)\n* MaxCommentLeaderLength: Keyword list. (line 53)\n* MaxCommentLeaderLength, in CVSROOT/config: config. (line 136)\n* MaxCompressionLevel, in CVSROOT/config: config. (line 148)\n* Mdocdate keyword: Keyword list. (line 28)\n* Merge, an example: Conflicts example. (line 6)\n* Merge, branch example: Merging a branch. (line 15)\n* Merging: Branching and merging.\n(line 6)\n* Merging a branch: Merging a branch. (line 6)\n* Merging a file: Updating a file. (line 6)\n* Merging two revisions: Merging two revisions.\n(line 6)\n* Merging, and keyword substitution: Merging and keywords.\n(line 6)\n* Meyering, Jim: Authors of getdate. (line 6)\n* MinCompressionLevel, in CVSROOT/config: config. (line 148)\n* minutes, time zone correction by: Time of day items. (line 28)\n* mkmodules: Error messages. (line 166)\n* Modifications, copying between branches: Branching and merging.\n(line 6)\n* Module status: Module options. (line 22)\n* Module, defining: Defining the module. (line 6)\n* Modules (admin file): modules. (line 6)\n* Modules file: Intro administrative files.\n(line 6)\n* Modules file program options: Module program options.\n(line 6)\n* Modules file, changing: Defining the module. (line 6)\n* modules.db: CVSROOT storage. (line 25)\n* modules.dir: CVSROOT storage. (line 25)\n* modules.pag: CVSROOT storage. (line 25)\n* month names in date strings: Calendar date items. (line 38)\n* months, written-out: General date syntax. (line 31)\n* Motivation for branches: Branches motivation. (line 6)\n* Moving a repository: Moving a repository. (line 6)\n* Moving branch tags: Modifying tags. (line 37)\n* Moving directories: Moving directories. (line 6)\n* Moving files: Moving files. (line 6)\n* Moving tags: Modifying tags. (line 37)\n* Multiple developers: Multiple developers. (line 6)\n* Multiple repositories: Multiple repositories.\n(line 6)\n* Name keyword: Keyword list. (line 43)\n* Name, symbolic (tag): Tags. (line 25)\n* Needs Checkout: File status. (line 27)\n* Needs Merge: File status. (line 37)\n* Needs Patch: File status. (line 32)\n* Newsgroups: What is CVS?. (line 44)\n* notify (admin file): Getting Notified. (line 58)\n* Notify file, in CVS directory: Working directory storage.\n(line 166)\n* Notify.tmp file, in CVS directory: Working directory storage.\n(line 171)\n* Number, branch: Revision numbers. (line 6)\n* Number, branch <1>: Branches and revisions.\n(line 6)\n* Number, revision-: Revision numbers. (line 6)\n* numbers, written-out: General date syntax. (line 21)\n* Option defaults: ~/.cvsrc. (line 6)\n* options, connection method: The connection method.\n(line 16)\n* Options, global: Global options. (line 6)\n* Options, in modules file: Module options. (line 6)\n* ordinal numbers: General date syntax. (line 21)\n* Outdating revisions: admin options. (line 95)\n* Overlap: Updating a file. (line 24)\n* Overriding CVSREAD: Global options. (line 148)\n* Overriding CVSROOT: Global options. (line 52)\n* Overriding EDITOR: Global options. (line 57)\n* Overriding RCSBIN: Global options. (line 24)\n* Overview: Overview. (line 6)\n* Ownership, saving in CVS: Special Files. (line 6)\n* Parallel repositories: Multiple repositories.\n(line 6)\n* passwd (admin file): Password authentication server.\n(line 70)\n* Password client, using: Password authentication client.\n(line 6)\n* Password server, setting up: Password authentication server.\n(line 10)\n* PATH, environment variable: Environment variables.\n(line 56)\n* Per-directory sticky tags/dates: Working directory storage.\n(line 155)\n* Permissions, general: File permissions. (line 6)\n* Permissions, saving in CVS: Special Files. (line 6)\n* Permissions, Windows-specific: Windows permissions. (line 6)\n* Pinard, F.: Authors of getdate. (line 14)\n* Policy: When to commit. (line 6)\n* port, specifying for remote repositories: Remote repositories.\n(line 6)\n* port, specifying for remote repositories <1>: Password authentication server.\n(line 10)\n* postadmin (admin file): postadmin. (line 6)\n* postproxy (admin file): postproxy. (line 6)\n* posttag (admin file): posttag. (line 6)\n* postwatch (admin file): postwatch. (line 6)\n* preproxy (admin file): preproxy. (line 6)\n* Primary server: Write proxies. (line 6)\n* Primary server <1>: config. (line 167)\n* PrimaryServer, in CVSROOT/config: Write proxies. (line 6)\n* PrimaryServer, in CVSROOT/config <1>: config. (line 167)\n* proxies, HTTP, connecting via: The connection method.\n(line 26)\n* proxies, web, connecting via: The connection method.\n(line 26)\n* proxy, method option: The connection method.\n(line 26)\n* proxy, write: Write proxies. (line 6)\n* proxy, write <1>: config. (line 167)\n* proxyport, method option: The connection method.\n(line 26)\n* pserver (client/server connection method), port specification: Remote repositories.\n(line 6)\n* pserver (client/server connection method), port specification <1>: Password authentication server.\n(line 10)\n* pserver (subcommand): Password authentication server.\n(line 10)\n* pserver (subcommand) <1>: server & pserver. (line 6)\n* pserver method, setting up: Password authentication client.\n(line 6)\n* pserver method, troubleshooting: Connection. (line 27)\n* pure numbers in date strings: Pure numbers in date strings.\n(line 6)\n* PVCS, importing files from: From other version control systems.\n(line 44)\n* RCS history files: Repository files. (line 68)\n* RCS revision numbers: Tags. (line 10)\n* RCS-style locking: Multiple developers. (line 6)\n* RCS, importing files from: From other version control systems.\n(line 10)\n* RCSBIN, in CVSROOT/config: config. (line 185)\n* RCSBIN, internal variable: Variables. (line 32)\n* RCSBIN, overriding: Global options. (line 24)\n* RCSfile keyword: Keyword list. (line 89)\n* rcsinfo (admin file): rcsinfo. (line 6)\n* rdiff (subcommand): rdiff. (line 6)\n* Read-only files, and -r: Global options. (line 130)\n* Read-only files, and CVSREAD: Environment variables.\n(line 18)\n* Read-only files, and watches: Setting a watch. (line 11)\n* Read-only files, in repository: File permissions. (line 6)\n* Read-only mode: Global options. (line 111)\n* Read-only repository access: Read-only access. (line 6)\n* Read-only repository mode: Global options. (line 103)\n* readers (admin file): Read-only access. (line 6)\n* Recursive (directory descending): Recursive behavior. (line 6)\n* Redirect, method option: The connection method.\n(line 86)\n* Reference manual (files): Administrative files.\n(line 6)\n* Reference manual for variables: Environment variables.\n(line 6)\n* Reference, commands: Invoking CVS. (line 6)\n* Regular expression syntax: syntax. (line 10)\n* Regular modules: Regular modules. (line 6)\n* relative items in date strings: Relative items in date strings.\n(line 6)\n* release (subcommand): release. (line 6)\n* Releases, revisions and versions: Versions revisions releases.\n(line 6)\n* Releasing your working copy: Cleaning up. (line 6)\n* Remote repositories: Remote repositories. (line 6)\n* Remote repositories, port specification: Remote repositories.\n(line 6)\n* Remote repositories, port specification <1>: Password authentication server.\n(line 10)\n* Remove (subcommand): Removing files. (line 34)\n* Removing a change: Merging two revisions.\n(line 9)\n* Removing branch tags: Modifying tags. (line 19)\n* Removing directories: Removing directories.\n(line 6)\n* Removing files: Removing files. (line 6)\n* Removing tags: Modifying tags. (line 19)\n* Removing your working copy: Cleaning up. (line 6)\n* Renaming directories: Moving directories. (line 6)\n* Renaming files: Moving files. (line 6)\n* Renaming tags: Modifying tags. (line 57)\n* Replacing a log message: admin options. (line 73)\n* Reporting bugs: BUGS. (line 13)\n* Repositories, multiple: Multiple repositories.\n(line 6)\n* Repositories, remote: Remote repositories. (line 6)\n* Repositories, remote, port specification: Remote repositories.\n(line 6)\n* Repositories, remote, port specification <1>: Password authentication server.\n(line 10)\n* Repository (intro): Repository. (line 6)\n* Repository file, in CVS directory: Working directory storage.\n(line 32)\n* Repository, backing up: Backing up. (line 6)\n* Repository, example: Repository. (line 6)\n* Repository, how data is stored: Repository storage. (line 6)\n* Repository, moving: Moving a repository. (line 6)\n* Repository, setting up: Creating a repository.\n(line 6)\n* RereadLogAfterVerify, in CVSROOT/config: config. (line 191)\n* Reserved checkouts: Multiple developers. (line 6)\n* Resetting sticky tags: Sticky tags. (line 31)\n* Resolving a conflict: Conflicts example. (line 100)\n* Restoring old version of removed file: Merging two revisions.\n(line 19)\n* Resurrecting old version of dead file: Merging two revisions.\n(line 19)\n* Retrieve a branch: Accessing branches. (line 6)\n* Retrieving an old revision using tags: Tags. (line 85)\n* Reverting to repository version: Editing files. (line 42)\n* Revision keyword: Keyword list. (line 92)\n* Revision management: Revision management. (line 6)\n* Revision numbers: Revision numbers. (line 6)\n* Revision numbers (branches): Branches and revisions.\n(line 6)\n* Revision tree: Revision numbers. (line 6)\n* Revision tree, making branches: Branching and merging.\n(line 6)\n* Revisions, merging differences between: Merging two revisions.\n(line 6)\n* Revisions, versions and releases: Versions revisions releases.\n(line 6)\n* Right-hand options: Common options. (line 6)\n* rls (subcommand): ls & rls. (line 6)\n* Root file, in CVS directory: Specifying a repository.\n(line 25)\n* rsh: Connecting via rsh. (line 6)\n* rsh replacements (Kerberized, SSH, &c): Connecting via rsh. (line 35)\n* rtag (subcommand): Tagging by date/tag. (line 6)\n* rtag (subcommand), creating a branch using: Creating a branch.\n(line 6)\n* Salz, Rich: Authors of getdate. (line 6)\n* Saving space: admin options. (line 95)\n* SCCS, importing files from: From other version control systems.\n(line 37)\n* script hook, postadmin: postadmin. (line 6)\n* script hook, postproxy: postproxy. (line 6)\n* script hook, posttag: posttag. (line 6)\n* script hook, postwatch: postwatch. (line 6)\n* script hook, preproxy: preproxy. (line 6)\n* script hook, taginfo: taginfo. (line 6)\n* script hooks: Trigger Scripts. (line 6)\n* script hooks, commitinfo: commitinfo. (line 6)\n* script hooks, common syntax: syntax. (line 6)\n* script hooks, precommit verification of commits: commitinfo.\n(line 6)\n* script hooks, security: Trigger Script Security.\n(line 6)\n* Secondary server: Write proxies. (line 6)\n* Secondary server <1>: config. (line 167)\n* secondary server, pull updates: postproxy. (line 6)\n* Security, file permissions in repository: File permissions. (line 6)\n* Security, GSSAPI: GSSAPI authenticated.\n(line 6)\n* Security, Kerberos: Kerberos authenticated.\n(line 6)\n* Security, of pserver: Password authentication security.\n(line 6)\n* Security, setuid: File permissions. (line 58)\n* server (subcommand): server & pserver. (line 6)\n* server method, setting up: Connecting via rsh. (line 35)\n* server method, troubleshooting: Connection. (line 22)\n* Server, CVS: Remote repositories. (line 6)\n* Server, temporary directories: Server temporary directory.\n(line 6)\n* Setgid: File permissions. (line 58)\n* Setting up a repository: Creating a repository.\n(line 6)\n* Setuid: File permissions. (line 58)\n* Source keyword: Keyword list. (line 95)\n* Source, getting CVS source: What is CVS?. (line 38)\n* Source, getting from CVS: Getting the source. (line 6)\n* Special files: Special Files. (line 6)\n* Specifying dates: Common options. (line 18)\n* Spreading information: Informing others. (line 6)\n* SSH (rsh replacement): Connecting via rsh. (line 35)\n* Starting a project with CVS: Starting a new project.\n(line 6)\n* State keyword: Keyword list. (line 98)\n* Status of a file: File status. (line 6)\n* Status of a module: Module options. (line 22)\n* Sticky date: Sticky tags. (line 37)\n* Sticky tags: Sticky tags. (line 6)\n* Sticky tags, resetting: Sticky tags. (line 31)\n* Sticky tags/dates, per-directory: Working directory storage.\n(line 155)\n* Storing log messages: loginfo. (line 6)\n* Stream authentication: Global options. (line 16)\n* Structure: Structure. (line 6)\n* Subdirectories: Recursive behavior. (line 6)\n* suck (subcommand): suck. (line 6)\n* Support, getting CVS support: BUGS. (line 16)\n* Symbolic link, importing: import output. (line 23)\n* Symbolic links: Special Files. (line 6)\n* Symbolic name (tag): Tags. (line 25)\n* Syntax of info files, updating legacy repositories: Updating Commit Files.\n(line 6)\n* syntax of trigger script hooks: syntax. (line 6)\n* SystemAuth, in CVSROOT/config: config. (line 208)\n* tag (subcommand): Tagging the working directory.\n(line 6)\n* tag (subcommand), creating a branch using: Creating a branch.\n(line 6)\n* tag (subcommand), introduction: Tags. (line 25)\n* Tag file, in CVS directory: Working directory storage.\n(line 155)\n* Tag program: Module options. (line 30)\n* taginfo (admin file): taginfo. (line 6)\n* taginfo (admin file), exit status: taginfo. (line 45)\n* taginfo (admin file), updating legacy repositories: taginfo.\n(line 38)\n* Tags: Tags. (line 6)\n* Tags, deleting: Modifying tags. (line 19)\n* Tags, example: Tags. (line 45)\n* Tags, logging: taginfo. (line 6)\n* Tags, logging <1>: posttag. (line 6)\n* Tags, moving: Modifying tags. (line 37)\n* Tags, renaming: Modifying tags. (line 57)\n* Tags, retrieving old revisions: Tags. (line 85)\n* Tags, sticky: Sticky tags. (line 6)\n* Tags, symbolic name: Tags. (line 25)\n* Tags, verifying: taginfo. (line 6)\n* tc, Trivial Compiler (example): A sample session. (line 6)\n* Team of developers: Multiple developers. (line 6)\n* Template file, in CVS directory: Working directory storage.\n(line 196)\n* Template for log message: rcsinfo. (line 6)\n* Temporary directories, and server: Server temporary directory.\n(line 6)\n* temporary directory, set in config: config. (line 215)\n* temporary file directory, set via command line: Global options.\n(line 30)\n* temporary file directory, set via config: Global options. (line 30)\n* temporary file directory, set via environment variable: Global options.\n(line 30)\n* temporary file directory, set via environment variable <1>: Environment variables.\n(line 145)\n* temporary files, location of: Global options. (line 30)\n* temporary files, location of <1>: config. (line 215)\n* temporary files, location of <2>: Environment variables.\n(line 145)\n* Third-party sources: Tracking sources. (line 6)\n* Time: Common options. (line 18)\n* time of day item: Time of day items. (line 6)\n* time zone correction: Time of day items. (line 28)\n* time zone item: General date syntax. (line 39)\n* time zone item <1>: Time zone items. (line 6)\n* Timezone, in output: log. (line 17)\n* Timezone, in output <1>: log examples. (line 6)\n* TMPDIR, environment variable: Global options. (line 30)\n* TMPDIR, environment variable <1>: Environment variables.\n(line 145)\n* TmpDir, in config: config. (line 215)\n* TopLevelAdmin, in CVSROOT/config: config. (line 220)\n* Trace: Global options. (line 139)\n* Traceability: History browsing. (line 6)\n* Tracking sources: Tracking sources. (line 6)\n* Transactions, atomic, lack of: Concurrency. (line 27)\n* trigger script hooks, common syntax: syntax. (line 6)\n* trigger scripts: Trigger Scripts. (line 6)\n* trigger scripts, commitinfo: commitinfo. (line 6)\n* trigger scripts, precommit verification of commits: commitinfo.\n(line 6)\n* trigger scripts, security: Trigger Script Security.\n(line 6)\n* Trivial Compiler (example): A sample session. (line 6)\n* Typical repository: Repository. (line 6)\n* Umask, for repository files: File permissions. (line 34)\n* Undoing a change: Merging two revisions.\n(line 9)\n* unedit (subcommand): Editing files. (line 42)\n* Unknown: File status. (line 51)\n* Unreserved checkouts: Multiple developers. (line 6)\n* Unresolved Conflict: File status. (line 41)\n* Up-to-date: File status. (line 11)\n* update (subcommand): update. (line 6)\n* Update, introduction: Updating a file. (line 6)\n* update, to display file status: File status. (line 73)\n* Updating a file: Updating a file. (line 6)\n* UseArchiveCommentLeader: Keyword list. (line 53)\n* UseArchiveCommentLeader, in CVSROOT/config: config. (line 233)\n* UseNewInfoFmtStrings, in CVSROOT/config: config. (line 244)\n* User aliases: Password authentication server.\n(line 99)\n* User variables: Variables. (line 62)\n* USER, environment variable: Variables. (line 93)\n* USER, internal variable: Variables. (line 43)\n* UserAdminOptions, in CVSROOT/config: admin. (line 16)\n* UserAdminOptions, in CVSROOT/config <1>: config. (line 256)\n* users (admin file): Getting Notified. (line 73)\n* val-tags file, and read-only access to projects: File permissions.\n(line 26)\n* val-tags file, forcing tags into: Error messages. (line 198)\n* Variables: Variables. (line 6)\n* Vendor: Tracking sources. (line 10)\n* Vendor branch: Tracking sources. (line 10)\n* verifymsg (admin file): verifymsg. (line 6)\n* verifymsg (admin/commit file), updating legacy repositories: verifymsg.\n(line 32)\n* verifymsg, changing the log message: verifymsg. (line 47)\n* verifymsg, changing the log message <1>: config. (line 191)\n* verifymsg, example: verifymsg example. (line 6)\n* version (subcommand): Invoking CVS. (line 884)\n* Versions, of CVS: Compatibility. (line 6)\n* Versions, revisions and releases: Versions revisions releases.\n(line 6)\n* Viewing differences: Viewing differences. (line 6)\n* VISUAL, environment variable: Committing your changes.\n(line 23)\n* VISUAL, environment variable <1>: Environment variables.\n(line 51)\n* VISUAL, internal variable: Variables. (line 39)\n* watch add (subcommand): Getting Notified. (line 11)\n* Watch family of commands, logging: postwatch. (line 6)\n* watch off (subcommand): Setting a watch. (line 25)\n* watch on (subcommand): Setting a watch. (line 9)\n* watch remove (subcommand): Getting Notified. (line 52)\n* watchers (subcommand): Watch information. (line 6)\n* Watches: Watches. (line 6)\n* wdiff (import example): First import. (line 19)\n* Web pages, maintaining with CVS: Keeping a checked out copy.\n(line 6)\n* web proxies, connecting via: The connection method.\n(line 26)\n* What (shell command): Using keywords. (line 32)\n* What branches are good for: Branches motivation. (line 6)\n* What is CVS not?: What is CVS not?. (line 6)\n* What is CVS?: What is CVS?. (line 6)\n* When to commit: When to commit. (line 6)\n* Windows, and permissions: Windows permissions. (line 6)\n* Work-session, example of: A sample session. (line 6)\n* Working copy: Multiple developers. (line 6)\n* Working copy, removing: Cleaning up. (line 6)\n* Wrappers: Wrappers. (line 6)\n* write proxy: Write proxies. (line 6)\n* write proxy <1>: config. (line 167)\n* Write proxy, logging: preproxy. (line 6)\n* Write proxy, logging <1>: postproxy. (line 6)\n* Write proxy, pull updates: postproxy. (line 6)\n* Write proxy, verifying: preproxy. (line 6)\n* writers (admin file): Read-only access. (line 6)\n* Ximbiot: BUGS. (line 16)\n* xinetd, configuring for pserver: Password authentication server.\n(line 10)\n* Zone, time, in output: log. (line 17)\n* Zone, time, in output <1>: log examples. (line 6)\n\n", "subsections": [] } } } }