co

co [options] file ...

-rrev
    Check out specified revision rev. If rev is a branch, the latest revision on that branch is retrieved.

-l
    Lock the retrieved revision. This checks out a writable copy and locks the revision, preventing others from simultaneously checking out and locking the same revision for editing.

-u
    Unlock the retrieved revision. If a revision is currently locked by the user, this option checks out an unlocked (read-only) copy and removes the lock.

-f
    Force overwrite. Overwrites the working file even if it exists and is writable.

-p
    Print to standard output. Instead of creating a working file, the retrieved revision is printed to stdout.

-q
    Quiet mode. Suppresses diagnostic messages, useful in scripts.

-ksubst
    Keyword expansion style. Controls how RCS keywords (e.g., $Revision$, $Date$) are expanded in the checked-out file. Common styles include kv (name and value, default), kvl (name, value, locker), o (old value), b (new value), v (value only), l (locker only), n (no expansion).

-M
    Set modification time. Sets the modification time of the working file to the checkout time.

co (check out) is a fundamental command within the Revision Control System (RCS), a mature version control system designed primarily for managing revisions of individual files. Its core function is to retrieve a specific revision of a file from its RCS archive, which is typically a file ending with the `,v` suffix (e.g., `myfile.c,v`).

When co is executed, it creates a working copy of the chosen revision in the current directory, making it accessible for viewing, compilation, or editing. By default, co fetches the latest revision of the file. A key aspect of co's operation is its ability to interact with the locking mechanism of RCS. Files can be checked out as read-only (unlocked), which is suitable for simply viewing or compiling a specific version, or they can be checked out with a lock (using the -l option), which signifies an intent to modify the file and prevents other users from concurrently locking and modifying the same revision. This locking mechanism is crucial for maintaining data integrity in a concurrent environment where multiple users might be working on the same files. After editing, the changes are typically committed back to the archive using the ci (check in) command.

co operates directly on RCS archive files (those ending in `,v`) and is designed for single-file version control, unlike modern systems that manage entire projects or repositories recursively.

RCS's locking mechanism is crucial for preventing conflicting changes. If a file is checked out for editing (with -l) and then the user forgets to check it back in or unlock it, others will be prevented from locking it. The rcs -u command can be used by an administrator to break locks.

While co and RCS are robust for their intended purpose, they have largely been superseded by distributed version control systems like Git for larger, collaborative software development due to RCS's lack of integrated branching, merging, and network capabilities, and its file-by-file operational model.

co supports keyword expansion, where specific strings embedded in the working file (e.g., $Revision$, $Date$, $Author$, $Id$) are automatically replaced with relevant metadata from the RCS archive during checkout. This feature is commonly used to embed version information directly into source code or documentation.

When a file is checked out with a lock (-l), the resulting working file is typically made writable by the user who performed the checkout. If checked out without a lock (or with -u), the working file is usually created as read-only. This permission control is an integral part of RCS's locking mechanism.

The Revision Control System (RCS), including the co command, was developed by Walter F. Tichy at Purdue University in the early 1980s, with its initial release around 1982. It emerged as an influential tool for managing changes to files, particularly source code, in Unix-like environments. co's design reflects the era's computing landscape, focusing on efficiency for individual file versioning and local disk-based operation. Its simplicity and effectiveness for managing single files or small collections of files ensured its widespread adoption and continued presence in standard Unix utilities, even as more complex and collaborative version control systems like CVS, Subversion, and Git gained prominence in the decades that followed. co remains valuable for simple revision tracking tasks.

ci(1), rcs(1), rcsclean(1), rcsdiff(1), ident(1)