Abstract

Local version control stores the history of the code base on the same disk storage used for the code under development.

In this lesson we will look at how this approach supports the problems areas of

• history maintenance,
• exploration of alternatives, and
• collaboration among developers
  • Particular attention will be paid to the locking mechanism used to support safe simultaneous access.

---

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
• usually a hidden subdirectory inside the working directory.
• Sharing of the repository and the working directory is possible only via the operating system’s underlying mechanism for sharing access to directories
  • permissions, linking

---

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

1 History

• mkdir RCS

  Creates an RCS repository for the files in the current directory (only)

  • The repository is currently empty

• 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.

  • Adding a -r v option allows check out of a specific revision number

---

Revision Numbers

• Clearly there was an intent that revision numbers also serve as version 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

• Problem is that each file’s revision number changes independently

  • So your intended release “version 2.1” might use revision 2.1 if adt.h, revision 2.5 of adt.cpp, revision 2.3 of main.cpp, etc.

• Versions can be checked out by date instead:

  “check out whatever version was current as of 12/13/2012”

  • Repeated over all files, would give a coherent view of the project status as of that date

---

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

  • Later version managers would make this “mandatory”

---

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.

  • Diffs are used to go back in time

    • Originally considered an important point in supporting efficient access to the most commonly needed file.

    • Now, probably not so important

2 Exploration

---

Exploring Alternatives

Suppose that we have worked through a few revisions and then get an idea that might not pay off.

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:

• Note that checking out the most recent version along a branch is not as efficient as checking out the most recent version on the trunk.

---

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.

  • The rcsmerge command is used to conduct the merge,
    • Need to resolve any conflicts introduced by continued development along the trunk.
  • then the resulting combined file checked in with a trunk number
     
    

---

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.

• An effective strategy for combating this is to periodically merge the trunk into the branch
  • the reverse of the “normal” merge direction
     
    

3 Collaboration

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).

4 Strengths and Weaknesses

• rcs addresses history, exploration, & collaboration concerns

• but has weaknesses in each area

---

History

• rcs tracks files in a directory.

  • Each file is tracked separately.

• No support for deletion of file

  • Unless you know not to request a file, you will always get the last version before it was deleted.

• No support for creation of new files

  • If you request revisions associated with very old dates, you will get version 1.1 even if the file did not actually exist as of that date.

• No support for renaming files

  • Appears to be a deletion and a subsequent creation of a new, unrelated file

• Each directory is tracked separately

  • Poor support for multi-directory projects

---

Exploration Issues

• Branching and merging is often confusing.

---

Collaboration Issues

• Locks are frequently abused

  • e.g., people forget to release a lock, forcing team members to wait
  • People grab locks they don’t really need.

• Cheating on locks is easy

  • People get in the habit of cheating to cope with lock abuse
  • And eventually start cheating with less and less provocation.