Software Configuration Management |

Overview

What is CVS?

CVS is a version control system. Using it, you can record the history of your source files.
— Helpful in going back to fix the bug.
— Group work simultaneously
— Works on copy-merge concept.

What CVS is not?

— CVS is not a build system (Though the structure of your repository and modules file interact with the build system, they are independent).
— Not a substitute for management.
— Not a substitute for developer communication.
— CVS does not have change control (e.g., bug tracking, atomic transcations, ability to keep track of status of each change)
— CVS is not an automated testing program.
— CVS does not have built-in process model.

Hands-on (Sample Session)

1. Checkout the module
The first thing you must do is to get your own working copy of the source for

tc

. For this, you use the

checkout

command:$ cvs checkout tcThis will create a new directory called

tc

and populate it with the source files, along with CVS directory. The

CVS

directory is used internally by CVS. Normally, you should not modify or remove any of the files in it.2. Checkin the files that you changed
This will store your new

backend.c

in the repository and make it available to anyone else who is using that same repository.
$ cvs commit backend.c3. Viewing differencescvs diff command runs

diff

to compare the version of filethat you checked out with your working copy.
4. Clean up (Remove the working copy of the module)
use the

release

command The

release

command checks that all your modifications have been
committed. If history logging is enabled it also makes a note in the
history file.
When you use the

-d

flag with

release

, it also removes your working copy.
The

release

command always finishes by telling you how many modified files you have in your working copy of the sources, and then asks you for confirmation
before deleting any files or making any note in the history file.

The Repository

The CVS

repository

stores a complete copy of all the files and directories which are under version control.
Normally, you never access any of the files in the repository directly. Instead, you use CVS commands to get your own copy of the files into a

working directory

and then work on that copy. When you’ve finished a set of changes, you check (or

commit

) them back into the repository.The repository also contains:
— The changes that you have made,
— as well as recording exactly what you changed,
— when you changed it, and other such information.Note that the repository is not a subdirectory of the working directory, or vice versa; they should be in separate locations.

Accessing Repository

CVS can access a repository by a variety of means.– local computer (

:local:

, e.g.,

:local:/usr/local/cvsroot

)
— computer across the other networkIf the access method is omitted, then if the repository starts with

, then

:local:

is assumed. If it does not start with

, then either

:ext:

:server:

is assumed. But in Windows you can’t omit :local: (

:local:c:/src/cvsroot

)

Parts of Repository

The repository is split in two parts.

$CVSROOT/CVSROOT

contains administrative files for CVS. The other directories contain the actual user-defined modules.
Telling CVS where your repository is1. Using -d (for directory) option of CVS
cvs -d /usr/local/cvsroot checkout yoyodyne/tc2. Setting $CVSROOT environment variable to an absolute path to root of the repository.

Note:

1. A repository specified with

-d

will override the

$CVSROOT

environment variable.
2. Once you’ve checked a working copy out from the repository, it will remember where its repository is (the information is recorded in the

CVS/Root

file in the working copy).
3. The

-d

option and the

CVS/Root

file both override the

$CVSROOT

environment variable. If -d option differs from

CVS/Root

, the former is used.

How Data is Stored in the Repository?

Where files are stored in the Repository?

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

/usr/local/cvsroot

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

With the directories are

history files

for each file under version control. The name of the history file is the name of the corresponding file with

appended to the end. Here is what the repository for the

yoyodyne/tc

directory might look like:

The history files (known as

RCS files)

contain, among other things,– enough information to recreate any revision of the file
— a log of all commit messages
— and the user-name of the person who committed the revision.

File Permissions

All

files are created read-only, and you should not change the permissions of those files. Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories.
The directories inside the repository should be writable by the persons that have permission to modify the files in each directory.This means that you can only control access to files on a per-directory basis.Note that users must also have write access to check out files because CVS needs to create lock files. You can use

LockDir

CVSROOT/config

to put the lock files somewhere other than in the repository if you want to allow read-only access to some directoriesCVS uses

CVSROOT/val-tags

to keep track of what tags are valid tag names, hence you must have write permissions to it.
CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory. If you set the

CVSUMASK

environment variable, that will control the file permissions which CVS uses in creating directories and/or files in the repository.

The Attic

You will notice that sometimes CVS stores an RCS file in the

Attic

. For example, if the CVSROOT is

/usr/local/cvsroot

and we are talking about the file

backend.c

in the directory

yoyodyne/tc

, then the file normally would be in

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

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

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

instead. It should not matter from a user’s point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to. But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state

dead

. A

dead

state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in

dead

state and a branch revision in a non

dead

state.

The CVS directory in the repository

The

CVS

directory in each repository directory contains information, such as file attributes (

CVS/fileattr

)
In the future additional files may be added to this directory, so implementations should silently ignore additional files.The format of the

fileattr

file is a series of entries of the following form (where

{‘ and `}

means the text between the braces can be repeated zero or more times):
ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>ent-type is

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

, and filename empty, to specify default attributes to be used for newly added files.
Other ent-type are reserved for future expansion. CVS 1.9 and older will delete them any time it writes file attributes. CVS 1.10 and later will preserve them. Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.By convention, attrname starting with `_’ is for an attribute given special meaning by CVS; other attrnames are for user-defined attributes (once implementations start supporting user-defined attributes).

Built-in attributes:

_watched –

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

_watchers –

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

_editors –

Users editing this file. Value is editor > val { , editor > val } where editor is a username and val is time+hostname+pathname, where time is when the

cvs edit

command (or equivalent) happened, and hostname and pathname are for the working directory.
CVS locks in the repository

Read Lock:

Any file in the repository with a name starting with

#cvs.rfl.

is a read lock.
To obtain a read lock, first create the

#cvs.lock

directory. This operation must be atomic. If it fails because the directory already existed, wait for a while and try again. After obtaining the

#cvs.lock

lock, create a file whose name is

#cvs.rfl.

followed by information of your choice. Then remove the

#cvs.lock

directory to release the master lock. Then proceed with reading the repository. When you are done, remove the

#cvs.rfl

file to release the read lock.

Promotable Read Lock:

Any file in the repository with a name starting with

#cvs.pfl

is a promotable read lock.

Purpose

-They are used to allow a two (or more) pass process to only lock a file for read on the first (read) pass(es), then upgrade its read locks to write locks if necessary for a final pass, still assured that the files have not changed since they were first read. CVS uses promotable read locks, for example, to prevent commit and tag verification passes from interfering with other reading processes. It can then lock only a single directory at a time for write during the write pass.

Process

– To obtain a promotable read lock, first create the

#cvs.lock

directory, as with a nonpromotable read lock. Then check that there are no files that start with

#cvs.pfl

. If there are, remove the master

#cvs.lock

directory, wait a while (CVS waits 30 seconds between lock attempts) and try again. If there are no other promotable locks, go ahead and create a file whose name is

#cvs.pfl

followed by information of your choice. Then remove the master

#cvs.lock

directory in order to allow other processes to obtain read locks.

Write Lock:

Any file in the repository with a name starting with

#cvs.wfl

is a write lock.

Process –

To obtain a write lock, first create the

#cvs.lock

directory, as with read locks. Then check that there are no files whose names start with

#cvs.rfl.

and no files whose names start with

#cvs.pfl

that are not owned by the process attempting to get the write lock. If either exist, remove

#cvs.lock

, wait for a while and try again. If there are no readers or promotable locks from other processes, then create a file whose name is

#cvs.wfl

followed by information of your choice. Remove your

#cvs.pfl

file, if present. Hang on to the

#cvs.lock

lock. Proceed with writing the repository. When you are done, first remove the

#cvs.wfl

file and then the

#cvs.lock

directory

Note –

Unlike the

#cvs.rfl

file, the

#cvs.wfl

file is just informational; it has no effect on the locking operation beyond what is provided by holding on to the

#cvs.lock

lock itself.

Directory Lock:

The directory

#cvs.lock

serves as a master lock. That is, one must obtain this lock first before creating any of the other locks.

NOTE:

Each lock (write lock or read lock) only locks a single directory in the repository, including

Attic

and

CVS

but not including subdirectories that represent other directories under version control. To lock an entire tree, you need to lock each directory. (Note that if you fail to obtain any lock you need, you must release the whole tree before waiting and trying again, to avoid deadlocks.)

How files are stored in CVSROOT [

$CVSROOT/CVSROOT

]directory

The

$CVSROOT/CVSROOT

directory contains the various administrative files.It contains RCS files whose names end in

, and many of the CVS commands operate on it the same way. However, there are a few differences.
For each administrative file, in addition to the RCS file, there is also a checked-out copy of the file. For example, there is an RCS file

loginfo,v

and a file

loginfo

which contains the latest revision contained in

loginfo,v

. When you check in an administrative file, CVS should print

cvs commit: Rebuilding administrative file database

and update the checked out copy in

$CVSROOT/CVSROOT

. If it does not, there is something wrong. To add your own files to the files to be updated in this fashion, you can add them to the

checkoutlist

administrative file.By default, the

modules

file behaves as described above. If the modules file is very large, storing it as a flat text file may make looking up modules slow. Therefore, by making appropriate edits to the CVS source code one can store the

modules

file in a database which implements the

ndbm

interface, such as Berkeley db or GDBM. If this option is in use, then the modules database will be stored in the files

modules.db

modules.pag

, and/or

modules.dir

How data is stored in the working directory

cvs creates a directory with name CVS in the working directories. The

`CVS'

directory contains several files. The files are stored according to the text file convention for the system in question. This means that working directories are not portable between systems with differing conventions for storing text files.

`Root'

This file contains the current CVS root

`Repository'

This file contains the directory within the repository which the current directory corresponds with. It can be either an absolute pathname or a relative pathname;The relative pathname is relative to the root (cvsroot), and is the more sensible approach, but the absolute pathname is quite common.If the particular working directory does not correspond to a directory in the repository, then

`Repository'

should contain

`CVSROOT/Emptydir'

`Entries'

This file lists the files and directories in the working directory. The first character of each line indicates what sort of line it is. If the character is unrecognized, programs reading the file should silently skip that line, to allow for future expansion.

If the first character is `/’, then the format is:/name/revision/timestamp[+conflict]/options/tagdate
- where `[‘ and `]’ are not part of the entry, but instead indicate that the `+’ and conflict marker are optional.
- name is the name of the file within the directory.
- revision is the revision that the file in the working derives from, or `0′ for an added file, or `-‘ followed by a revision for a removed file.
- timestamp is the timestamp of the file at the time that CVS created it; if the timestamp differs with the actual modification time of the file it means the file has been modified. It is stored in the format used by the ISO C asctime() function (for example, `Sun Apr 7 01:29:26 1996′). One may write a string which is not in that format, for example, `Result of merge’, to indicate that the file should always be considered to be modified. This is not a special case; to see whether a file is modified a program should take the timestamp of the file and simply do a string compare with timestamp. The timezone on the timestamp in CVS/Entries (local or universal) should be the same as the operating system stores for the timestamp of the file itself. This rule is so that files do not appear to be modified merely because the timezone changed
- If there was a conflict, conflict can be set to the modification time of the file after the file has been written with conflict markers. Thus if conflict is subsequently the same as the actual modification time of the file it means that the user has obviously not resolved the conflict.
- options contains sticky options
- tagdate contains `T’ followed by a tag name, or `D’ for a date, followed by a sticky tag or date.

If the first character of a line in

`Entries'

is `D’, then it indicates a subdirectory. The line looks like:

D/name/filler1/filler2/filler3/filler4

where name is the name of the subdirectory, and all the filler fields should be silently ignored, for future expansion. Programs which modify Entries files should preserve these fields. The lines in the

`Entries'

file can be in any order.

`Entries.Log'

This file does not record any information beyond that in

`Entries'

, but it does provide a way to update the information without having to rewrite the entire

`Entries'

file, including the ability to preserve the information even if the program writing

`Entries'

and

`Entries.Log'

abruptly aborts. Programs which are reading the

`Entries'

file should also check for

`Entries.Log'

. If the latter exists, they should read

`Entries'

and then apply the changes mentioned in

`Entries.Log'

. After applying the changes, the recommended practice is to rewrite

`Entries'

and then delete

`Entries.Log'

. The format of a line in

`Entries.Log'

is a single character command followed by a space followed by a line in the format specified for a line in

`Entries'

The single character command is `

A’

to indicate that the entry is being added, `

R’

to indicate that the entry is being removed, or any other character to indicate that the entire line in

`Entries.Log'

should be silently ignored. Programs which are writing rather than reading can safely ignore

`Entries.Log'

if they so choose.

`Entries.Backup'

This is a temporary file. Recommended usage is to write a new entries file to

`Entries.Backup'

, and then to rename it

`Entries.Static'

The only relevant thing about this file is whether it exists or not. If it exists, then it means that only part of a directory was gotten and CVS will not create additional files in that directory. To clear it, use the update command with the `-d’ option, which will get the additional files and remove

`Entries.Static'

`Tag'

This file contains per-directory sticky tags or dates. The first character is `T’ for a branch tag, `N’ for a non-branch tag, or `D’ for a date, or another character to mean the file should be silently ignored, for future expansion. This character is followed by the tag or date. Note that per-directory sticky tags or dates are used for things like applying to files which are newly added; they might not be the same as the sticky tags or dates on individual files.

`Notify'

This file stores notifications (for example, for edit or unedit) which have not yet been sent to the server.

`Notify.tmp'

This file is to

`Notify'

`Entries.Backup'

is to

`Entries'

. That is, to write

`Notify'

, first write the new contents to

`Notify.tmp'

and then (atomically where possible), rename it to

`Notify'

`Base'

If watches are in use, then an edit command stores the original copy of the file in the

`Base'

directory. This allows the unedit command to operate even if it is unable to communicate with the server.

`Baserev'

The file lists the revision for each of the files in the

`Base'

directory. The format is:

Bname/rev/expansion

where expansion should be ignored, to allow for future expansion.

`Baserev.tmp'

This file is to

`Baserev'

`Entries.Backup'

is to

`Entries'

. That is, to write

`Baserev'

, first write the new contents to

`Baserev.tmp'

and then (atomically where possible), rename it to

`Baserev'

`Template'

This file contains the template specified by the

`rcsinfo'

file (see section Rcsinfo ). It is only used by the client; the non-client/server CVS consults

`rcsinfo'

directly.

The Administrative Files

The directory

`$CVSROOT/CVSROOT'

contains some

administrative files

.You can use CVS without any of these files, but some commands work better when at least the

`modules'

file is properly set up.
The most important of these files is the

`modules'

file. It defines all modules in the repository. This is a sample

`modules'

file.

CVSROOT CVSROOT
modules CVSROOT modules
cvs gnu/cvs
rcs gnu/rcs
diff gnu/diff
tc yoyodyne/tc

The

`modules'

file is line oriented. In its simplest form each line contains the name of the module, whitespace, and the directory where the module resides. The directory is a path relative to $CVSROOT.
Editing administrative filesYou edit the administrative files in the same way that you would edit any other module. Use `cvs checkout CVSROOT’ to get a working copy, edit it, and commit your changes in the normal way.
Multiple repositoriesFor instance if you have two development groups that work on separate projects without sharing any code. All you have to do to have several repositories is to specify the appropriate repository, using the CVSROOT environment variable, the `-d’ option to CVS, or (once you have checked out a working directory) by simply allowing CVS to use the repository that was used to check out the working directoryThe big advantage of having multiple repositories is that they can reside on different servers. With CVS version 1.10, a single command cannot recurse into directories from different repositories. With development versions of CVS, you can check out code from multiple servers into your working directory. CVS will recurse and handle all the details of making connections to as many server machines as necessary to perform the requested command. Here is an example of how to set up a working directory:

cvs -d server1:/cvs co dir1
cd dir1
cvs -d server2:/root co sdir
cvs update

The cvs co commands set up the working directory, and then the cvs update command will contact server2, to update the dir1/sdir subdirectory, and server1, to update everything else.

Creating a Repository

To create a repository, run the cvs init command. It will set up an empty repository in the CVS root specified in the usual way (see section The Repository ). For example,

cvs -d /usr/local/cvsroot init

cvs init is careful to never overwrite any existing files in the repository, so no harm is done if you run cvs init on an already set-up repository.cvs init will enable history logging; if you don’t want that, remove the history file after running cvs init.Backing up a repositoryThere is nothing particularly magical about the files in the repository; for the most part it is possible to back them up just like any other files. However, there are a few issues to consider.
one should either not use CVS during the backup, or have the backup program lock CVS while doing the backup. To lock CVS, you would create

`#cvs.rfl'

locks in each repository directory.
Having said all this, if you just back up without any of these precautions, the results are unlikely to be particularly dire. Restoring from backup, the repository might be in an inconsistent state, but this would not be particularly hard to fix manually.When you restore a repository from backup, assuming that changes in the repository were made after the time of the backup, working directories which were not affected by the failure may refer to revisions which no longer exist in the repository. Trying to run CVS in such directories will typically produce an error message. One way to get those changes back into the repository is as follows:

Get a new working directory.
Copy the files from the working directory from before the failure over to the new working directory (do not copy the contents of the `CVS' directories, of course).
Working in the new working directory, use commands such as cvs update and cvs diff to figure out what has changed, and then when you are ready, commit the changes into the repository.

Moving a repositoryThe main thing to consider is that working directories point to the repository. The simplest way to deal with a moved repository is to just get a fresh working directory after the move. Of course, you’ll want to make sure that the old working directory had been checked in before the move, or you figured out some other way to make sure that you don’t lose any changes. If you really do want to reuse the existing working directory, it should be possible with manual surgery on the

`CVS/Repository'

files.Remote repositoriesYour working copy of the sources can be on a different machine than the repository.
You run CVS on a machine which can mount your working directory, known as the

client

, and tell it to communicate to a machine which can mount the repository, known as the

server

. Generally, using a remote repository is just like using a local one, except that the format of the repository name is:

[:method:][[user][:password]@]hostname[:[port]]/path/to/repository

Specifying a password in the repository name is not recommended during checkout, since this will cause CVS to store a cleartext copy of the password in each created directory. Use cvs login first instead (

Server Requirements: TODO

The Connection Method:

method portion of the repository string (see section Remote repositories ) may be one of `ext’, `fork’, `gserver’, `kserver’, `local’, `pserver’, and, on some platforms, `server’. If method is not specified, and the repository name starts with a `/’, then the default is local. If method is not specified, and the repository name does not start with a `/’, then the default is ext or server, depending on your platform; The ext, fork, gserver, and pserver connection methods all accept optional method options, specified as part of the method string, like so:

:method[;option=arg…]:other_connection_data

CVS is not sensitive to the case of method or option, though it may sometimes be sensitive to the case of arg. The possible method options are as follows:

proxy=

hostname

proxyport=

port

These two method options can be used to connect via an HTTP tunnel style web proxy.

CVS_RSH=

path

This method option can be used with the ext method to specify the path the CVS client will use to find the remote shell used to contact the CVS server and takes precedence over any path specified in the $CVS_RSH environment variable

CVS_SERVER=

path

This method option can be used with the ext and fork methods to specify the path CVS will use to find the CVS executable on the CVS server and takes precedence over any path specified in the $CVS_SERVER environment variable

Redirect=

boolean-state

The Redirect method option determines whether the CVS client will allow a CVS server to redirect it to a different CVS server, usually for write requests, as in a write proxy setup. boolean-state for the Redirect method option defaults to `on’.This option will have no effect when talking to any non-secondary CVS server.
Connecting with rsh :CVS uses the `rsh’ protocol to perform these operations, so the remote user host needs to have a

`.rhosts'

file which grants access to the local user. Note that the program that CVS uses for this purpose may be specified using the

`--with-rsh'

flag to configure.Then test that `rsh’ is working with

rsh -l bach faun.example.org ‘echo $PATH’

Next you have to make sure that rsh will be able to find the server. Make sure that the path which rsh printed in the above example includes the directory containing a program named cvs which is the server. You need to set the path in

`.bashrc'

`.cshrc'

, etc., not

`.login'

`.profile'

. Alternately, you can set the environment variable CVS_SERVER on the client machine to the filename of the server you want to use, for example

`/usr/local/bin/cvs-1.6'

. For the ext and fork methods, you may also specify CVS_SERVER as an option in the CVSROOT so that you may use different servers for different roots.There are two access methods that you use in CVSROOT for rsh. :server: specifies an internal rsh client, which is supported only by some CVS ports. :ext: specifies an external rsh program. By default this is rsh (unless otherwise specified by the

`--with-rsh'

flag to configure) but you may set the CVS_RSH environment variable to invoke another program which can access the remote serverYou may choose to specify the CVS_RSH option as a method option in the CVSROOT string to allow you to use different connection tools for different roots For example, allowing some roots to use CVS_RSH=remsh and some to use CVS_RSH=ssh for the ext method.Direct connection with password authenticationThe CVS client can also connect to the server using a password protocol. This is particularly useful if using rsh is not feasible (for example, the server is behind a firewall), and Kerberos also is not available. To use this method, it is necessary to make some adjustments on both the server and client sides.
1. Setting up the server for password authenticationOn the server side, the file

`/etc/inetd.conf'

needs to be edited so inetd knows to run the command cvs pserver when it receives a connection on the right port. By default, the port number is 2401; it would be different if your client were compiled with CVS_AUTH_PORT defined to something else, though. This can also be specified in the CVSROOT variable or overridden with the CVS_CLIENT_PORT environment variable

a) inetd

If your inetd allows raw port numbers in

`/etc/inetd.conf'

, then the following (all on a single line in

`inetd.conf'

) should be sufficient:

2401 stream tcp nowait root /usr/local/bin/cvs
cvs -f –allow-root=/usr/cvsroot pserver

The `–allow-root’ option specifies the allowable CVSROOT directory. Clients which attempt to use a different CVSROOT directory will not be allowed to connect. If there is more than one CVSROOT directory which you want to allow, repeat the option.
If your inetd wants a symbolic service name instead of a raw port number, then put this in

`/etc/services'

cvspserver 2401/tcp

and put cvspserver instead of 2401 in

`inetd.conf'

. Once the above is taken care of, restart your inetd, or do whatever is necessary to force it to reread its initialization files.

b) xinetd <TODO>
c) passwords and usernames

Because the client stores and transmits passwords in cleartext a separate CVS password file is generally used, so people don’t compromise their regular passwords when they access the repository. This file is

`$CVSROOT/CVSROOT/passwd'.

It uses a colon-separated format, similar to

`/etc/passwd'

on Unix systems, except that it has fewer fields: CVS username, optional password, and an optional system username for CVS to run as if authentication succeeds.
You could create a single, shared system user for each project in your repository, and give each developer their own line in the

`$CVSROOT/CVSROOT/passwd'

file. The CVS username on each line would be different, but the system username would be the same. The reason to have different CVS usernames is that CVS will log their actions under those names: when melissa commits a change to a project, the checkin is recorded in the project’s history under the name melissa, not pubcvs. And the reason to have them share a system username is so that you can arrange permissions in the relevant area of the repository such that only that account has write-permission there.
The password and system-user fields can both be omitted
CVS can also fall back to use system authentication. When authenticating a password, the server first checks for the user in the

`$CVSROOT/CVSROOT/passwd'

file. If it finds the user, it will use that entry for authentication as described above. But if it does not find the user, or if the CVS

`passwd'

file does not exist, then the server can try to authenticate the username and password using the operating system’s user-lookup routines (this “fallback” behavior can be disabled by setting SystemAuth=no in the CVS

`config'

file,

2. Using the client with password authentication

To run a CVS command on a remote repository via the password-authenticating server, one specifies the pserver protocol, optional username, repository host, an optional port number, and path to the repository. For example:

cvs -d :pserver:faun.example.org:/usr/local/cvsroot checkout someproj

CVSROOT=:pserver:bach@faun.example.org:2401/usr/local/cvsroot
cvs checkout someproj

However, unless you’re connecting to a public-access repository (i.e., one where that username doesn’t require a password), you’ll need to supply a password or

log in

first. Logging in verifies your password with the repository and stores it in a file. It’s done with the login command, which will prompt you interactively for the password if you didn’t supply one as part of $CVSROOT:

cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login
CVS password:

cvs -d :pserver:bach:p4ss30rd@faun.example.org:/usr/local/cvsroot login

After you enter the password, CVS verifies it with the server. If the verification succeeds, then that combination of username, host, repository, and password is permanently recorded, so future transactions with that repository won’t require you to run cvs login
The records are stored, by default, in the file

`$HOME/.cvspass'

. That file’s format is human-readable, and to a degree human-editable, but note that the passwords are not stored in cleartext–they are trivially encoded to protect them from “innocent” compromise.
You can change the default location of this file by setting the CVS_PASSFILE environment variable. The password for a given remote repository can be removed from the CVS_PASSFILE by using the cvs logout command.
3. Security considerations with password authentication

The passwords are stored on the client side in a trivial encoding of the cleartext, and transmitted in the same encoding.
The separate CVS password file allows people to use a different password for repository access than for login access.
Once a user has non-read-only access to the repository, she can execute programs on the server system through a variety of means.

Direct connection with GSSAPI – TODO
Direct connection with Kerberos – TODO
Connecting with fork – TODO
Distributing load across several CVS servers – TODO
Using active-active replication to distribute reads

as well as write

load -TODO
Using active-passive setup to distribute read load – TODORead-only repository access- TODOTemporary directories for the server – TODO

Recursive Behavior

Almost all of the subcommands of CVS work recursively when you specify a directory as an argument. For Example,If

`tc'

is the current working directory, the following is true:

`cvs update testing’ is equivalent to

cvs update testing/testpgm.t testing/test2.t

`cvs update testing man’ updates all files in the subdirectories
`cvs update .’ or just `cvs update’ updates all files in the tc directory

The recursive behavior of the CVS subcommands can be turned off with the `-l’ option. Conversely, the `-R’ option can be used to force recursion if `-l’ is specified in

`~/.cvsrc'

History BrowsingOnce you have used CVS to store a version control history–what files have changed when, how, and by whom, there are a variety of mechanisms for looking through the history.Log messagesWhenever you commit a file you specify a log message.To look through the log messages which have been specified for every revision which has been committed, use the cvs log command
The history databaseYou can use the history file to log various CVS actions. To retrieve the information from the history file, use the cvs history commandNote: you can control what is logged to this file by using the `LogHistory’ keyword in the

`CVSROOT/config'

User-defined loggingYou can customize CVS to log various kinds of actions, in whatever manner you choose. These mechanisms operate by executing a script at various times. The script might append a message to a file listing the information and the programmer who created it, or send mail to a group of developers, or, perhaps, post a message to a particular newsgroup. To log commits, use the

`loginfo'

file and to log tagging operations, use the

`taginfo'

file
To log commits, checkouts, exports, and tags, respectively, you can also use the `-i’, `-o’, `-e’, and `-t’ options in the modules file. For a more flexible way of giving notifications to various users, which requires less in the way of keeping centralized scripts up to date, use the cvs watch add command; this command is useful even if you are not using cvs watch on.

Runtime Notes (From Forums and other….. including self learnings)

use the commitinfo , loginfo , rcsinfo , or verifymsg files to require that certain steps be performed before cvs will allow a checkin
The environment variable $CVSEDITOR determines which editor is started. If $CVSEDITOR is not set, then if the environment variable $EDITOR is set, it will be used. If both $CVSEDITOR and $EDITOR are not set, then there is a default which will vary with your operating system, for example, vi for unix or notepad for Windows NT/95 In addition, CVS checks the $VISUAL environment variable. Opinions vary on whether this behavior is desirable and whether future releases of CVS should check $VISUAL or ignore it. You will be OK either way if you make sure that $VISUAL is either unset or set to the same thing as $EDITOR .
If a file’s modification time has changed but its contents have not, it will show up as modified. The simplest way to handle this is simply not to worry about it–if you proceed with the commit CVS will detect that the contents are not modified and treat it as an unmodified file. The next update will clue CVS in to the fact that the file is unmodified, and it will reset its stored timestamp so that the file will not show up in future editor sessions.
use LockDir in CVSROOT/config to put the lock files somewhere other than in the repository if you want to allow read-only access to some directories
CVS has never allowed tags that begin with numbers
cvs does not build or change management (it is Version control tool and not Configuration Management system)
-D takes a single date, not a range of dates, so the “>” is not valid in command such as cvs -d D:CVS<customer_name> checkout -P -t -D “>22 Aug 2007” -d <customer_name> — <customer_name>.
tag will not move an existing tag without the -F option.
cvs option -t gives more descriptive output

Can I remove / rename a CVS directory

Is there a way to eliminate, hide or keep the “./CVS” directory away from the current directory ? (Nope )
Either hide it with a ., under “.CVS” or keep it at some other place like ~user/CVSdirs/<some_relative_path> ? Nope, CVS does not allow that particular customization.That said, the sources are open and you may pervert them in any way you desire.

Can I insert directory between existing directory structure (change of directory structure)?

Is there any way to add a new directory between already existing directory structure IN CVS . Like I have directory structure “MyRepository/ConfigFile/origional” etc. Now i want to add one more directory between “ConfigFile and origional ” say newDir so that my new directory structure should be “MyRepository/ConfigFile/newDir/origional ” CVS does not perform revision control on directories, so if you have direct access to the repository files on the server, then you can do that by simply moving the directores around. However, be aware that any change you make will affect everyone who already has “MyRepository/ConfigFile/origional” checked out, who will very likely have to check out “MyRepository/ConfigFile” from scratch after you make the change. Also note that the history information for files in the “origional” folder (and its descendants) will have no record of the change. Finally, if you have any scripts, build tools, or anything that depends on the existing directory structure, you will be unable to go back and use earlier revisions. So, in other words, be very careful, and only do it if none of these cautions I’ve mentioned will be an issue (such as a brand new repository for example).
As an alternative, you could just add “NewDir/origional”, and then add the contents of the “ConfigFile/origional” folder to “NewDir/origional” folder, and then remove the contents of the original “origional” folder. That would preserve the history, and would allow you to check out an earlier revision if you ever needed it.

Unexpected character during checkout

I couldn’t find any explanations on the following error which occurs once in a while during a directory checkout in a cron job. If a manual check out again right after it, it would work fine. I don’t believe there was any error in it. When this error appears, the checkout aborts. cvs [checkout aborted]: unexpected ‘x65’ reading revision number in RCS file file,v Either your repository is on a network drive and the network file system is unreliable, the hard drive containing the repository is going bad, or the connection to the hard drive containg the repository is unreliable. Whichever is the case, you have a serious problem that may corrupt your entire repository, if it hasn’t already. I strongly suggest running the validate_repo (for CVS 1.12) or check_cvs (for cvs 1.11) script from the contrib directory to check the repository for corruption after fixing the problem.

How do I remove a Branch Tag from the repository?

At the risk of being flamed to a crisp for answering this question:
cvs tag -d -B <tag>
or
cvs rtag -d -B <tag> <module>
However, carefully note the precautionary usage statement:
“-B Allows -F and -d to disturb branch tags. Use with extreme care.”
If you remove a branch tag, you lose the ability to refer to the sources in that branch (unless you also happen to have a symbolic tag). So, the questions you should ask yourself are:
1) why do I want to remove a branch tag?
2) is it really necessary to remove the tag?
I ask a slightly different question: why not keep the tag? It does no harm and takes up almost no space.

Add new file to tag

How can i add a new file in an existing tag? I want to add a .java file in a package in a tag cf_t_20070512.

I am getting following *error*:The server reported an error while performing the “cvs add” command.
cloneFone_20070512: cvs add: cannot add file on non-branch tag `cf_t_20070512′ Add and commit the file to the repository in a working directory checked out from the head, not from the tag, then add the tag to the file with ‘cvs tag cf_t_20070512 your_file’.

Permissions on branch

I need some help with CVS branches. Essentially you have a project with many branches. I want to set up things so that a user has write permissions to just one branch and read-only permissions for the other branches. How do I set this up?

For cvs-1.11.x or cvs-11.12.x,
read this URL:

http://cvs.savannah.nongnu.org/viewvc/*checkout*/ccvs/contrib/cvs_acl…

If it does what you want, then download and configure (fix @PERL@ references to use your /usr/bin/perl path) and install it in your $CVSROOT/CVSROOT along with a CVSROOT/avail file and then add it to your
CVSROOT/commitinfo trigger.

http://cvs.savannah.nongnu.org/viewvc/*checkout*/ccvs/contrib/cvs_acl…

Can I share file between Modules?

I’m migrating and reorganizing src from RCS to CVS. There is one common file for two modules, which is simply a symlink in src tree under RCS. I understand CVS allows a common module that is shared between two modules (ampersand modules), but how do I share a single file? I don’t want to make a subdirectory for one file. You can’t, but you can have it shared in a subdirectory and symlink it to the place you want. You can let your build system plant the link.

Can I install client part of CVS only?

You certainly can, but most people just install the standard executable that can be used as a client, a server, or standalone.
I don’t know of any pre-built client-only executables. You can download the source code, configure it for client-only, and build it yourself, or you can download a pre-built standard executable and just use it as a client. You can get either from: <

http://download.savannah.gnu.org/releases/cvs/

Command to get latest revision on the branch

Was looking for a cvs command line, where Given a file name and branch name, want the *log message* of the latest revision on that branch.Tried some of the cvs log commands , but couldn’t get what i was looking for
CVSROOT :ext:host.dom.main:/path/to/repository filename module/subdir1/subdir2/file1.c branch mybranch
cvs -d :ext:host.dom.main:/path/to/repository
rlog -rmybranch. -N module/subdir1/subdir2/file1.c
will give you the log message LAST revision for the ‘mybranch’ branch. The ‘.’ at the end asks CVS for just the last revision. The -N supresses all of the other tags. The module/subdir1/subdir2/file1.c is the pathname you might use to checkout just the file1.c sources in your local tree.
If you are already in a checked out tree, then going to the module/subdir1/subdir2 directory you should be able to use:

cvs log -rmybranch. -N file1.c

to get the same information.

CVS and CVSNT are different

I am looking for some information on providing file ownership in CVS. By that, I would like to have the ability to block changes to certain files or directories unless the user has been granted access by the file owner.Is there a way to do this within CVS?
No. CVSNT (GPL/Free, linux/mac/unix/win – just like CVS) has this though – see the “chacl” command. Note: if you are using CVSNT there is a separate newsgroup.
If for some reason you cannot upgrade, in CVS 1.11 sources apparently there is a perl script in the contrib directory that provides some of these features.
One of the reasons why there are “two projects” is that these sort of features are considered by some people to not “belong” in CVS, hence why there is CVSNT for those who believe that SCM should do more, like: failsafe audit, commit identifiers, change sets/user defined commit identifiers, merge tracking etc…

Deleting a directory from repository

I want to commint ANY changes inside a folder (yes, they do exist in the IT world since very long times), which means subfolders, files and so on. Any changes means any modifications, including deletions of files and folders inside this folder. Now I am looking for a CVS command which conveniently commits all the changes inside that folder. CVS does not know anything of folders? Nevertheless I ask for a solution how to commit every change in this folder, any change in all files and subfolders. Does it work with CVS, yes or no, and if yes, how?This is what “cvs commit” (or “cvs ci”, the synonym) does. At least, it commits ANY changes CVS even cares about. CVS (and, btw, Subversion, too) does not care at all about folders. Thery are just present if they were generated at any time back in history.
Any, you might want to add the -P command for the “cvs update” and the “cvs checkout” commands into your .cvsrc. This way, CVS will not show empty directories when doing an update or a checkout. Note, however,
that this option gets tricky when doing branches (with “cvs tag”). In this case, I suggest using “cvs rtag”.
Additionally, this option is tricky when you want to “recreate” a directory that was once empty.
But you already know most of this, Larry already explained it. This is the only way to work with CVS here, as it is the way CVS works.The only other options I see are:
1. Check out if meta-cvs (or other tools on top of CVS) support directories (I do not know, you have to check yourself).
2. If the directory is realy, really, REALLY not needed anymore, you might consider deleting it from the repository (that is, from the server). Note that you loose anything that was once inside that; thus, I do not recommend this unless the directory was created by accident only.

Rollback Changes of some specific Devs … of N days before

I have 2 devs working in the same repository. Dev1 made a pretty big mistake and asked me if it was possible to revert all the files he modified back to 2 days ago (Monday) without touching to the files that dev2 modified. And this is for everything in that repository. I know how to revert everything to a specific day but I do not know how to only revert files checked in by a specific dev.What are my options?

Get Bonsai (

http://www.mozilla.org/projects/bonsai/

) and set it up, have it build its database from the cvs history. Then use it to query everything dev1 did in the specified time frame. When it’s showing you a list of commits that includes everything you want to rollback and nothing that you don’t, hit the magic link at the top entitled “show the
commands to back out these changes” save the resulting text to a .bat or .sh file, execute it…. Viola!
Of course, if there are overlapping commits, you’re probably going to have to do those by hand, but this should get a bunch of it done….

pserver – using 2 repositories

I got pserver running on my linux server using xinetd. That is working fine. My cvspserver file for reference:
service cvspserver {
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/local/bin/cvs
server_args = -f –allow-root=/usr/local/sceip pserver
} The problem is that I need to access 2 repositories using pserver. Anyone know how I could do this?

I don’t have xinetd, but for inetd.conf, you do this:
cvspserver stream tcp nowait root /usr/bin/cvs
cvs –allow_root=/repository/abc –allow-root=/repository/xyz pserver
So for your case it can be.
server_args = -f –allow-root=/usr/local/sceip
–allow-root=/some/other/repository
pserver Now I getthe following error when I try to connect to either repo: No connection could be made because the target machine actively refused it.I’ll try to modify it again.

If your repositories are on the same filesystem with the same parent folder, you could give the –allow-root= argument the parent folder’s path.

*grasping at straws* .. try it all one line?

Thanks for all the help guys, that worked!

All on one line is the solution

Finding files in repository based on comment

How do I find all the files in a repository whose comments contain a specific text block (in my case an issue number)?

cvs rlog . | egrep “(RCS file|issue number)” | grep -B1 “issue number” | grep “RCS file”
Notes:
1) that this should be all one command – ignore any line wrapping that may occur.
2) “issue number” is a placeholder for your actual issue number. This is another of the (many) reasons why we put the historylog in a database of your choice (oracle, mysql etc) in CVSNT (yes it runs on linux too, yes it’s GPL just like CVS).

Branch Recreation

We recently had a production release that was developed on a branch we’ll call “aug07_branch”. After the release was successfully deployed the aug07_branch was merged into the trunk. The trunk was then tagged
“trunk_aug07_postrelease” Then a patch branch named “aug07_patch_branch” was created based on the tag “trunk_aug07_postrelease”. So far so good.
Then it was discovered that some files from the merge were messed up. So the files were fixed and committed to the trunk. The trunk was then tagged again with tag “trunk_aug07_postrelease_2”. So the question is – how do we get the patch branch updated with the new changes to the trunk ?
I think I can just recreate the patch branch using the new tag “trunk_aug07_postrelease_2” and the -F and -B options. Can anyone confirm this ? It was not obvious from the documentation.Would it be better to merge the changes between the 2 trunk tags into the branch ?
That just moves the branch tag, it doesn’t do any merging. As long as there haven’t been any changes checked in to the patch branch yet, that’s sufficient.
If there have been any changes checked in on the patch branch, you need to do merge. Or create a new patch branch off the new trunk tag and merge the changes from the old patch branch into the new patch branch.

Preserve annotations when you merge branches – HOWTO?

Is it possible to preserve annotations when you merge branches?
For example, I have two branches A and B. B has bug fixes made to it and A has new features. We want to merge B to A, but I’d like to have the annotation history merged also. Currently when we do the merge the person doing the merge that commits the changes into A, is shown and the modifier for all the changes in the annotations for branch A. I don’t think this is possible, but I thought I’d ask just to make sure.
You’re right, it is not possible to preserve “annotations” when merging. Or else you may ask developers to commit each patch on the branch A and on the branch B and also on the head with its own account. Not reasonable.
In case of doubt on a line, you need to look at the revision log message for that line saying “merge from branch B from tagX to tagY on branch A”, then checkout tagY on branch B and do another cvs annotate to know who have written that line.
I’m not sure but I think this information is not kept in Subversion either. Maybe the future merge tracking will provide enough information to annotate source properly.

Checkout a module with files from other modules — Alias

I’m trying to create configuration (using the CVSROOT/modules file) that I’ll be able to checkout all the files a module need. This module has most of its files under the module directory in the repository but also has some files under other modules in the repository. Try an alias module:

http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_18.html#SEC160

Assuming your top-level directories are named ‘dir1’ and ‘dir2’, and ‘dir1’ is the one with most of the files, this would do something like what you want.
my_module -a dir1 dir2/other_dir …
Then
cvs checkout my_module
would put dir/… and dir2/other_dir/… in your working directory. Thanks for the reply. I did something a little bit different. Basically, I need some files from dir2/other1_dir to be under a certain directory that is under dir1 and some other files from dirs/other2_dir to be under another directory that is under dir1. What I did was:
test1 -d dir1/another1_dir dir2/other1_dir file1 file2…
test2 -d dir1/another2_dir dir2/other2_dir file3 file4…
test test &test1 &test2
The checkout output looked very good but I couldn’t find files 1-4 under dir1 😦
What I did wrong? The problem is that the ‘test’ module is an ampersand module, so it created a sub-directory named ‘test’ which contains
test/dir1/another1_dir/file1
test/dir1/another1_dir/file2
test/dir1/another2_dir/file3
test/dir1/another2_dir/file4
…
See this;

http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_18.html#SEC162

If you want the top-level module in your working directory to be ‘dir1’ then you should use an alias module instead, like this:
test -a dir1 test1 test2
Note two things:
1. If an alias module has the same name as the top-level directory You’ll get an infinite loop error, so the module name must be different than the directory name; that’s why my example uses ‘test’ and ‘dir1’. (I don’t know if this is a bug or expected behavior; perhaps the CVS gurus on the list can answer that.)
2. You must be sure to name your main directory (dir1) in the alias module first. If you don’t the dir1/CVS/Repository file will be set to dir2 rather than dir1, and then you will not be able to check out dir1 itself. This will be a problem for me. I’m moving Pvcs to Cvs and the developers will not like the fact that they have new modules names. Is there any workaround to solve that? Well, you could rename of the top-level directories in the repository, and then put the original names (ie, what the users want to check out) into the modules file, and use the -d option to rename them on checkout.
Suppose you renamed the top-level directory ‘dir1’ to ‘dir1.d’, and defined your modules like this:
dir1 -d dir1 dir1.d
dir2 -d dir2 dir2.d
test1 -d dir1/another1_dir dir2/other1_dir file1 file2…
test2 -d dir1/another2_dir dir2/other2_dir file3 file4…
test -a dir1 test1 test2
Then
cvs checkout dir1
would do what your users would expect, and
cvs checkout test
would check out the dir1 and dir2 sources into dir1 like you want. Yes but when I’ll open a GUI module browser, I’ll see test in the list of modules and not dir1. BTW, I’ve tried your suggestion and when I open the module browser I see something like that:
module1
module2
module3
+aliases
– test
module4
…
Is there a way to avoid this aliases entry? Well, you’ll have to decide whether you can live with that. Modules are not directories (although directories are modules.) Modules are a way of aggregating groups of directories and files into a single name. If your users won’t accept that, then I don’t know any other way of doing what you want. Perhaps someone else here has some other ideas. I did something that is working but I’m not sure it is a good thing to do. It was very easy though.
I’ve just copied in the repository (,v files) all the files I needed from one module to another and now everything seems to work just fine. Moving ‘,v’ files around in the repository is almost never the right thing to do. Copying ‘,v’ files around is never the right thing to do. Now you’ve got two copies of file1 in different modules; which one is the ‘correct’ one? If a user changes one, does he/she have to change the other as well? How will they know to do this? What happens if they don’t?
This is likely to just cause you and your users confusion. I would strongly recommend using modules to accomplish what you want.

Unicode filename support in CVS?

Is CVS capable of dealing with unicode filenames? If so, is it advisable to use those kinds of names when you are using some other tools that deal with CVS as well? (for instance Eclipse, incvs, cvsnt,…) I am asking because we seem to be getting some strange issues since someone committed files with an æ (that’s ae) and an euro sign in the file name. I could not find any info about this on the ximbiot.com web-site.No, its not. There is no conversion, meaning filenames and even worse, the file content, are transmitted as is. This will cause trouble if one sandbox runs on a iso-8859-1 filesystem and another one runs for ex. on a utf-8 fs. Files checked out from cvs server will be encoded identical to the encoding they were checked in with.

Finding changes on a branch

I have a branch with subbranch:

1.66
|
+-> 1.66.2.1 – main branch
…
1.66.2.9
|
+-> 1.66.2.9.2.1 ( Branch 1.66.2.9.2 ) – sub-branch
1.66.2.10
1.66.2.11

I need to apply the changes between 1.66.2.9 and 1.66.2.9.2.1 to 1.66.2.11. If I use the revision number, I can get a diff:

cvs diff -r 1.66.2.9 -r 1.66.2.9.2.1 somefile.cpp

cvs stat on somefile.cpp says:

Sticky Tag: patch1 (branch: 1.66.2.9.2)

If I try:

cvs diff -r patch1 somefile.cpp
or
cvs diff -r patch1 -r HEAD somefile.cpp

I don’t get and changes.I can’t figure out how to specify the revsions using the branch tags. I’m trying to express “take all the changes on my patch1 branch, and apply them to the head of the main branch”. You are using the wrong command. ‘diff’ only displays changes between revisions; it does not apply them. You need to use the ‘update’ command with the -j switch. For example, on your main branch (change to its directory), do:
cvs up -j 1.66.2.9 -j 1.66.2.9.2.1 somefile.cpp
This will cause the changes in somefile.cpp between 1.66.2.9 and 1.66.2.9.2.1 to be applied to somefile.cpp in the current directory (which should be your main branch).
If you want to do the same thing for all files in the branch, I hope you have a symbolic tag that points to the branch’s starting point (a branch tag moves as files are modified, so you cannot use a branch tag as its starting point). If you don’t have a symbolic tag, then you are going to have a difficult time applying all of the changes for all of the files using individual revision numbers! The best thing to do is create a symbolic tag using a time stamp (assuming you know when the branch was created). You can do this by using the ‘tag’ or ‘rtag’ command with the -D switch. For
example:cvs rtag -D 2007-08-01 15:00:00 branch_start module_name
Once you have a symbolic tag that references the branch’s starting point, you can do (from your main branch directory):
cvs up -j branch_start -j branch_tag
This will cause the changes in all files between branch_start (a symbolic tag) and branch_tag (a branch tag) to be applied to those same files in the current directory (which should be your main branch).

Some .cvsrc gyan

as far as I can see I can set the -q (quiet) option in “.cvsrc” only for _all_ commands not just for e.g. update. Is this correct?

Yes, that’s correct. There is no way to apply global options to individual commands.
I’m looking for a solution to make “cvs update” by default quiet and let all other commands untouched.
You could set up an alias (or batch script depending on your O/S), and use it instead. Something like:
alias cvs_update=’cvs -q update’
Extra question: cvs -q update does not show the directory listing, but it lists unknown files in the sandbox anyway. Can I supress this? But I want to get output for all things cvs does (Updates, Patches, Conflicts, warnings, errors…) On a UNIX-like command (including Cygwin) pipe the output through:
egrep -v ‘^?’

List all the files which are not branched in git

Learned Git

About CVS

Recent Posts

Blog Stats

Archives

Tags

Categories

Subscribe