LinuxCommandLibrary

cvs

Manage concurrent access to source code

TLDR

Create a new repository (requires the CVSROOT environment variable to be set externally)

$ cvs -d [path/to/repository] init
copy

Add a project to the repository
$ cvs import -m "[message]" [project_name] [version] [vendor]
copy

Checkout a project
$ cvs checkout [project_name]
copy

Show changes made to files
$ cvs diff [path/to/file]
copy

Add a file
$ cvs add [path/to/file]
copy

Commit a file
$ cvs commit -m "[message]" [path/to/file]
copy

Update the working directory from the remote repository
$ cvs update
copy

SYNOPSIS

cvs [global_options] command [command_options] [arguments]

Examples:
cvs checkout module_name
cvs commit -m "Initial commit"
cvs update -Pd

PARAMETERS

-d repository_path
    Use the specified CVS repository path.

-q
    Run quietly, suppressing informational messages.

-r
    Read-only mode, prevents modifications to the repository.

-t
    Trace, show all data sent between client and server.

-z level
    Compress all network traffic at the specified level (0-9).

add
    Add a new file or directory to the repository.

checkout (co)
    Create a local working copy of a module or files from the repository.

commit (ci)
    Check local changes into the repository.

diff (di)
    Show differences between revisions in the repository or local working copy.

log
    Display revision history and log messages for files.

remove (rm)
    Mark a file for removal from the repository.

status (st)
    Display the status of files in the working directory (e.g., needs update, locally modified).

update (up)
    Bring the local working copy up-to-date with the repository.

tag (tg)
    Apply a symbolic tag (or sticky tag) to files in the working directory.

rtag (rt)
    Apply a symbolic tag to modules or files directly in the repository.

import
    Import a new project or set of files into the repository for the first time.

export
    Export a clean copy of a module without CVS administrative files.

init
    Initialize a new, empty CVS repository.

-m message
    Specify a log message directly on the command line for commit operations.

-r revision_or_tag
    Operate on or retrieve a specific revision or tag.

-D date
    Operate on or retrieve the revision as of a specific date.

-P
    Prune empty directories (commonly used with update).

-l
    Local operation, restrict to the current directory only, not recursive.

-R
    Recursive operation, act on all subdirectories (this is the default).

-f
    Force an operation, e.g., overwrite local files during update or commit empty directories.

DESCRIPTION

The cvs command, short for Concurrent Versions System, is a widely used client-server version control system designed to manage source code and other files among multiple developers. It allows users to keep track of changes made to files over time, revert to previous versions, and merge modifications from different contributors. cvs operates on a centralized repository model, where a single master copy of the project resides on a server. Developers "check out" files from the repository, work on their local copies, and then "commit" their changes back to the repository. It handles conflicts when multiple users modify the same file section by requiring manual merging. Despite being largely superseded by modern distributed version control systems like Git, cvs was a foundational tool in software development for many years, facilitating collaborative coding efforts across various operating systems. It supports branching and tagging for managing different development lines and releases, and provides logging capabilities to review revision history.

CAVEATS

cvs has several significant limitations compared to modern version control systems:


* Non-Atomic Commits: A commit operation is not atomic; if it fails midway, the repository can be left in an inconsistent state, making recovery difficult.
* File Renaming/Moving: Renaming or moving files is cumbersome and effectively involves deleting the old file and adding a new one, losing its history.
* Merging Challenges: Its merge capabilities are less sophisticated, often leading to complex manual conflict resolution, especially with divergent branches.
* Binary Files: Handling binary files is inefficient; it stores full copies of each revision rather than deltas, leading to large repository sizes.
* Centralized Model: The reliance on a single central server can be a single point of failure and limits offline work.
* Outdated: It lacks many features considered standard today, such as distributed workflows, cryptographic signing, or advanced branching strategies.

CONFIGURATION FILES

.cvsrc: A user-specific file in the home directory that stores default global options for CVS commands, avoiding the need to type them repeatedly.
.cvsignore: A file in the working directory that lists patterns of files or directories to ignore during CVS operations (e.g., build artifacts, temporary files, editor backups).

ENVIRONMENT VARIABLES

CVSROOT: Specifies the path to the CVS repository, overriding the -d option and allowing CVS commands to locate the repository.
CVS_RSH: Specifies the remote shell program to use for connecting to the CVS server (e.g., ssh), enabling secure remote access.

HISTORY

Concurrent Versions System (CVS) originated in 1986 as a set of shell scripts written by Dick Grune, intended to be a front-end to RCS (Revision Control System). It gained significant traction and was rewritten in C by Brian Berliner in 1989, becoming a standalone system. It was widely adopted throughout the 1990s and early 2000s, becoming the de facto standard for open-source project management before the advent of Subversion (SVN) and later Git. Its client-server architecture allowed distributed teams to collaborate effectively. Despite its historical significance, development on cvs has largely ceased, and its usage has declined dramatically in favor of more robust and feature-rich systems.

SEE ALSO

git(1), svn(1), rcs(1)

Copied to clipboard