ci

ci [options] file ...
ci [options] -L|-U [file] ...
ci [options] -r[rev] -l|-u [file] ...

-r[rev]
    Specifies the revision number to check in. If omitted, ci determines the next revision number. For example, -r1.2 checks in revision 1.2.

-l
    Locks the new revision after checking it in. This keeps the working file available for further editing and prevents others from checking in to the same branch.

-u
    Unlocks the new revision after checking it in. This leaves the working file available but unlocked, allowing others to check in.

-mmessage
    Uses the provided message string as the log message for the new revision, bypassing the interactive editor.

-tfile
    Reads the log message for the new revision from the specified file.

-q
    Operates quietly, suppressing diagnostic output.

-f
    Forces the check-in even if no changes were detected or if the file was not checked out using co.

-Nname
    Assigns a symbolic name (tag) to the new revision. For example, -Nstable_release.

-sstate
    Sets the state attribute of the new revision. Common states include Exp (experimental), Rel (release), Stab (stable).

-ksubst
    Sets the default keyword substitution mode for future revisions checked out from this file.

-L
    Sets the default locking style to 'strict', meaning co requires a lock before editing.

-U
    Sets the default locking style to 'non-strict', meaning co does not require a lock before editing.

-w[username]
    Sets the author's login name for the new revision. If username is omitted, the current user's login name is used.

-d[date]
    Uses the specified date and time for the new revision. If omitted, the current time is used.

-z[zone]
    Specifies the time zone for the new revision. If omitted, the current time zone is used.

ci is the command used to check in changes from a working file into an RCS (Revision Control System) file. It creates a new revision of the file, storing the changes and associating them with a log message. When ci is invoked, it typically reads the working file, computes the differences from the previous revision, and stores these differences efficiently. It also records information such as the author, date, and a user-provided log message describing the changes made. After a successful check-in, ci usually removes the working file by default, leaving only the RCS file. This behavior can be altered using options like -l to keep the file locked for further editing or -u to keep it unlocked. ci is a fundamental part of the RCS workflow, enabling version control for individual files by managing their revision history within a special RCS directory.

RCS is designed for managing individual files, not entire projects with complex dependencies or directory structures. It lacks atomic commits across multiple files. Permissions on RCS files (e.g., file,v) are critical for proper operation. ci might prompt for a log message if -m or -t is not used, requiring an interactive session. Binary files often don't fare well with RCS's delta storage, though -kb can help for keyword substitution.

The EDITOR environment variable is used to determine which text editor ci invokes for the log message if -m or -t options are not provided. If EDITOR is not set, ci typically defaults to vi or ed.

By default, ci removes the working file after a successful check-in. This behavior emphasizes that the RCS file (file,v) is the canonical source. Use -l or -u to retain the working file.

RCS (Revision Control System) was originally developed by Walter F. Tichy at Purdue University in the early 1980s (first released around 1982-1985). ci is a core component, reflecting the system's focus on managing individual file revisions using a delta-storage mechanism. It was a prevalent version control system for Unix-like environments before more distributed and project-oriented systems like CVS, Subversion, and Git became popular. Despite its age, RCS is still found on many systems and remains useful for simple, single-file versioning tasks.

co(1), rcs(1), rcsdiff(1), rcsmerge(1), ident(1)