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
Sharing of repositories is possible only via the operating system’s underlying mechanism for sharing access to directories
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.
mkdir RCS
Creates an RCS repository for the files in the current directory (only)
ci filename
Checks files in to the repository
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.
-r v
option allows check out of a specific revision numberRevision Numbers
Clearly there was an intent that revision numbers also serve as version numbers.
e.g., to move from version 1.12 to 2.0
Problem is that each file’s revision number changes independently
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
Note also the option to add explanatory text at the time of the checkout
Implementation
rcs is essentially a systematic way of creating and organizing patches.
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.
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.
The current version is always available immediately.
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.
The current version is always available immediately.
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.
The current version is always available immediately.
Originally considered an important point in supporting efficient access to the most commonly needed file.
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.
The current version is always available immediately.
Originally considered an important point in supporting efficient access to the most commonly needed file.
Now, probably not so important
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.
If you decide to adopt the changes in the branch, you can elect to merge it back into the trunk.
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
co filename
obtain a read-only copy of the file.
Locks
co -l filename
requests a locked version of the file.
rcs addresses history, exploration, & collaboration concerns
but has weaknesses in each area
History
rcs tracks files in a directory.
No support for deletion of file
No support for creation of new files
No support for renaming files
Each directory is tracked separately
Exploration Issues
Collaboration Issues
Locks are frequently abused
Cheating on locks is easy