Last modified: Nov 20, 2013
Localized Version Control
The earliest version control systems in wide use were sccs and the open source rcs.
We’ll focus on rcs
The “repository” of historical information is kept as a “special” subdirectory, named RCS
Basic rcs Operations
ci Check In a file from the working directory into the repository
co Check Out a file from the repository into the working directory
rcsdiff Compare two versions of a file.
rcsmerge
mkdir RCS
Creates an RCS repository for the files in the current directory (only)
ci filename
Checks files in to the repository
If the file is not in there yet, it is added
If it is in there, then this becomes the new/current revision
Each check in is assigned a new, ascending revision number
Somewhat surprisingly, deletes the file from the current directory
co -l filename
Checks out the most recent version of that file from the repository, storing it in the working directory.
Revision Numbers
A special option allows you to force a change to the leading digit,
e.g., to move from version 1.12 to 2.0
Versions can be checked out by date instead:
“check out whatever version was current as of 12/13/2012”
Naming Revisions
Revisions can be named:
ci -N "v1.2" -t "Public release 1.2" *.h *.cpp
and later checked out by name instead of by exact revision number
Implementation
rcs is essentially a systematic way of creating and organizing patches.
The repository always contains the current version of the file plus enough diffs/patches to move back to any prior revision.
Exploring Alternatives
We can start a branch to explore our idea while others continue work on the main trunk.
ci -r1.3.1 _filename_
Checks in our current version of filename as a new branch of development, numbered 1.3.1.1
1.3.1.1 is the trunk version from which we branched out
1.3.1.1 is the branch number
1.3.1.1 is the revision number within the branch
Working in a Branch
Subsequent check-ins of both the main trunk (1.3) and of our branch version will maintain separate revision numbers:
Merging a Branch
If the idea in the branch does not pay off, the branch can simply be abandoned.
Multiple Merges
After a merge
We might opt to discontinue using the branch
Or we might continue working along it, eventually generating more changes to be merged into the system
Combating Drift
Over time, a long-running branch can get so far out of sync with changes being made to the trunk that the final merge becomes difficult or even impossible.
rcs supports collaboration by locking files
Most checkouts like this
co filename
obtain a read-only copy of the file. * nix permissions 400 Can be used to compile system, but cannot be changed * (Of course, you can always chmod, but that’s cheating.
Locks
A checkout like this
co -l filename
requests a locked version of the file. * Request fails if a locked version already exists somewhere. * If successful, programmer receives a copy with write permission. * Lock persists until the programmer checks in changes or explicitly releases the lock (which deletes the file from their directory, forcing them to check out an unlocked, read-only version again).
rcs addresses history, exploration, & collaboration concerns
but has weaknesses in each area
History
Exploration Issues
Collaboration Issues