- •Overview
- •What is CVS?
- •What is CVS not?
- •A sample session
- •Getting the source
- •Committing your changes
- •Cleaning up
- •The Repository
- •Telling CVS where your repository is
- •How data is stored in the repository
- •File permissions
- •The attic
- •The CVS directory in the repository
- •CVS locks in the repository
- •How data is stored in the working directory
- •Multiple repositories
- •Creating a repository
- •Backing up a repository
- •Moving a repository
- •Remote repositories
- •Server requirements
- •Connecting with rsh
- •Direct connection with password authentication
- •Setting up the server for password authentication
- •Using the client with password authentication
- •Security considerations with password authentication
- •Direct connection with GSSAPI
- •Direct connection with Kerberos
- •Connecting with fork
- •Distributing load across several CVS servers
- •Read-only repository access
- •Temporary directories for the server
- •Starting a project with CVS
- •Creating Files From Other Version Control Systems
- •Creating a directory tree from scratch
- •Revisions
- •Revision numbers
- •Versions, revisions and releases
- •Assigning revisions
- •Specifying what to tag from the working directory
- •Specifying what to tag by date or revision
- •Deleting, moving, and renaming tags
- •Sticky tags
- •Branching and merging
- •What branches are good for
- •Creating a branch
- •Accessing branches
- •Branches and revisions
- •Magic branch numbers
- •Merging an entire branch
- •Merging from a branch several times
- •Merging and keywords
- •Recursive behavior
- •Removing directories
- •The Normal way to Rename
- •Moving and renaming directories
- •History browsing
- •Log messages
- •The history database
- •Multiple developers
- •File status
- •Informing others about commits
- •Several developers simultaneously attempting to run CVS
- •Telling CVS to notify you
- •Information about who is watching and editing
- •Using watches with old versions of CVS
- •Choosing between reserved or unreserved checkouts
- •Revision management
- •When to commit?
- •Keyword substitution
- •Keyword List
- •Using keywords
- •Avoiding substitution
- •Substitution modes
- •Problems with the $Log$ keyword.
- •Tracking third-party sources
- •Updating with the import command
- •Reverting to the latest vendor release
- •How to handle keyword substitution with cvs import
- •Multiple vendor branches
- •How your build system interacts with CVS
- •Special Files
- •Calendar date items
- •Index
84 |
CVS—Concurrent Versions System v1.12.13 |
# Do not expand any RCS keywords KeywordExpand=i
this could be confusing to users that expect RCS keywords like $Id$ to be expanded properly, so care should be taken to properly set user expectations for a repository so configured.
It should be noted that a patch to provide both the KeywordExpand and LocalKeyword features has been around a long time. However, that patch implemented these features using tag= and tagexpand= keywords and those keywords are NOT recognized.
12.6 Problems with the $Log$ keyword.
The $Log$ keyword is somewhat controversial. As long as you are working on your development system the information is easily accessible even if you do not use the $Log$ keyword—just do a cvs log. Once you export the file the history information might be useless anyhow.
A more serious concern is that cvs is not good at handling $Log$ entries when a branch is merged onto the main trunk. Conflicts often result from the merging operation.
People also tend to "fix" the log entries in the file (correcting spelling mistakes and maybe even factual errors). If that is done the information from cvs log will not be consistent with the information inside the file. This may or may not be a problem in real life.
It has been suggested that the $Log$ keyword should be inserted last in the file, and not in the files header, if it is to be used at all. That way the long list of change messages will not interfere with everyday source file browsing.