Source Configuration Management

Source Configuration Management
        Why
        Solution 1 - Copies of files
        Solution 2 - Source Management Tools
        Tool 1 - RCS
        Tool 2 - CVS

Reading: None

Why

How do you keep straight production vs. development code?
How can you easily refer back to a previous version of a piece of code?
If several people are working together on the same code, how can you keep straight who is editing what?

What if two people want to make changes to the same file?

Solution 1 - Copies of files

You could do all of this just by making appropriate copies of files.
Easy to do - no special software required.
Can take a bit of disk space.

But you can compress things.

Doesn't address the concurrency issue.

Barney and Betty both start editing foo.c, perhaps by making copies.
Barney finishes first, and replaces foo.c with his version.
Then Betty finishes and replaces foo.c with her version.

Her version does not have Barney's changes.
Unless Barney has a copy somewhere, his changes are lost.

Solution 2 - Source Management Tools

The tools handle the versioning for you.
They also support "check out" and "check in" operations.

You can only make changes if the file is "checked out" to you
Now you know who can edit the file, and you know what changes will be made

Usually support branching

Handy for maintaining parallel development lines
Can merge branches back together if you want/need to.

Store versions in some sort of compact format, usually something like diff.

Tool 1 - RCS

RCS (Revision Control System) was developed in 1982 by Walter Tichy.
Tried to provide a better solution that some of the existing solutions.
One thing RCS did differently was how it stored files

Previous tools stored a base version and diffs to produce newer versions.
RCS stores most recent version and diffs to produce previous versions.

The RCS "database" for a file is stored in "filename,v" (either in the current directory or (recommended) in a subdirectory called RCS)
Collection of tools.

ci

"check in" a file
ci filename

Check in filename, giving it the next higher version number from the "current" version.

ci -u filename

Check in filename, and immediately check it out.

ci -l filename

Check in filename, and immediately check it out, locking it.

co

"check out" a file
co filename

Check out the file (you get a read-only copy, and have no right to check in changed versions)

co -l filename

Check out and lock the file (you have the exclusive right to submit changes to the file)

rcsdiff

What's the difference between two different versions?
Output looks like the output of diff.

rcsmerge

Merge two different versions

rlog

List the revision history of a file

rcs

Manage the RCS file itself

We'll demo RCS in class

Tool 2 - CVS

Stands for "Concurrent Versions System"
Started in 1986 as a set of shell scripts which used RCS as a backend.
Converted to C and updated many times since then.
What follows is a fairly broad, high-level overview of what CVS is and does
Some features of CVS:

Handles multiple users, multiple branches, and remote access
Doesn't require check out/check in operations
Forces you to merge in any other changes when you do a "commit" (roughly equivalent to a check in)

Commands

Unlike RCS, cvs is a single command, with various instructions that it understands
cvs checkout

Enables you to check out a "module"

A module is a collection of files that are referred to by a name

There is no locking

CVS forces you to reconcile changes when you checkin

cvs commit

Enables you to save your changes back to the "official" repository
CVS starts an editor for your log message

cvs update

Refreshes your copies of the source with what's in the repository

cvs import

Places an existing directory (with sources, presumably) into a new cvs repository

cvs tag

Tag a certain set of revisions with a particular identifier
To get from version 1.0 of your product to version 1.1, some files might go through 3 revisions, while others might have none.
The version number of a particular file doesn't necessarily have anything to do with the version of the software product that file is part of

Branching

Branching is conceptually similar to in RCS
The tag command is used with a "-b" option to create the branch
The branch can then be checked out, or the current working source can be assigned to be the source for the branch

cvs checkout -r to check out the branch
cvs update -r to make the current working source be the branch

Merging from a branch

Often, a branch is made to fix bugs in a previous release
That fix should be in the next release as well
cvs update -j followed by the name of the branch will merge in differences from the branch

Multiple users

One of the strengths of CVS is how it handles multiple users

In RCS, only one user can work on a file at a time
If two different people both need to make changes to the same file, one will have to wait

Barney and Betty, the CVS version

Barney and Betty both are working on a file.
They start with a cvs checkout to get the current version
Barney finishes first, and does a cvs commit of his changes
Now Betty finishes, and does a cvs commit

CVS will tell her that there has been a change since she started
Betty runs a cvs update to update her source
Betty's version of the file now contains markers identifying parts of the file that are from her change and from the committed change
It is Betty's responsibility to reconcile the changes and then do her commit

Chapter 10 of the CVS manual has a good example of this in action