Painless SCM

Development teams often view software configuration management (SCM) systems as a necessary evil. Most SCM systems introduce a certain amount of friction in the development process, and the two most common sources of this friction are the system's locking semantics and its branching model.

Generally, there are two types of locking semantics: pessimistic and optimistic. While I'm borrowing these terms from database theory, you'll see that the motivations for each model aren't the same as when dealing with databases. Pessimistic concurrency is used when development managers are pessimistic about their developers' ability to manage merging changes from two conflicting check-ins; optimistic concurrency is used when managers are optimistic about their developers' ability to successfully merge changes.

Advantages and Disadvantages

Systems based on pessimistic concurrency exclusively lock files while they're being edited. Smaller development teams generally prefer these systems for several reasons: The update model is simplified—any updates to files that you've checked out will succeed; individuals tend to have ownership over entire features and, in small teams, it's rare that more than one developer would ever need to edit the same file; and a simplified update model means that little training is required for new team members. It also means that developers must negotiate a schedule to determine when they can edit those files. This situation may introduce a kind of peer pressure that encourages premature check-in of shared code, which can be extremely problematic for teams on a regular build schedule and becomes intractable in larger settings.

With optimistic concurrency systems, developers must explicitly merge their changes when the SCM system detects conflicts. Locks are never held on files, so developers don't need to negotiate when they can edit any file; all files are editable at all times. When two developers attempt to check in changes to the same file, the last one to check in his file must manually merge his changes with the changes made by the first one to check in his file. However, there's a risk of lost updates due to incorrectly merged files. To mitigate this risk, developers often must be trained on the SCM system before they're allowed to actively work on a project. More training, of course, means increased cost.

Unfortunately, some SCM systems are so complex as to defy understanding by all but the most dedicated SCM systems administrators. But there is hope. According to AccuRev, its eponymous configuration management product was designed to reduce developer friction; like a good manager, a good SCM system should make your life better, not worse. Does AccuRev fulfill its promise? Let's see.

A Flexible Workspace

One of the mantras of every great development team is "Never break the build. Code that hasn't been thoroughly tested should never be checked into the main development stream. This forces developers to delay checking code into the source control system until they're sure that the code works. While implementing complex features, this means that they could go days between checking in new code. Unfortunately, this also means that they lose the "undo benefits of regularly checking code into the source control system.

AccuRev's private Workspace feature solves this problem. The best way to understand it is to look at a typical developer session that supports the optimistic concurrency model. Two users, John and Bob, interact with each other in a typical session. Each prefers to work with different tools: John uses the AccuRev GUI tool, acgui, and Bob uses the Accurev.exe command-line interface to create new directories.

John first creates a Depot—a single version-controlled directory tree—called Cassini to hold our project files. An AccuRev Depot lives inside of the AccuRev Repository, which resides on the SCM server and may contain any number of Depots. Next, he creates his own Workspace—a private directory tree on his computer that's mapped to the Cassini Depot.

Once John's Workspace has been created, our second user, Bob, creates his own Workspace that maps to the Cassini Depot. To add some files to our Depot, Bob writes the standard "Hello, World app using C#, and creates a new file called app.cs in his private Workspace on his computer.

 public class App {
   public static void Main() {
     System.Console.WriteLine("Hello, World); }
 }
 

Bob must explicitly promote files in his Workspace before other developers can see them. Since Bob wants John to see his work, he executes another command to promote app.cs to the Depot on the server. Note that I've simplified this example; see my later discussion on AccuRev Streams (see "Working with Streams).

When John wants to begin working, he updates his Workspace with the file that Bob has made. When he opens it, he finds that Bob hadn't made appropriate use of C# namespaces, so he changes the contents of the app.cs file.

 using System;

 public class App {
   public static void Main() {
     Console.WriteLine("Hello, World); }
 }
 

While John is editing his copy of app.cs, Bob decides to make an additional change to the file. He adds an exclamation point at the end of "Hello, World, finishing first due to his speedy typing skills, and checks in his changes. AccuRev prompts him to enter a comment that describes his changes. Once he enters his comment, AccuRev copies his changed file into his Workspace. He again promotes his copy of all kept files to the Depot.

[click for larger image] A Simple Merge AccuRev's diff tool lets you resolve merge conflicts among users.

From the previous example, we see how AccuRev's private Workspace feature lets developers continue to check changes into their private Workspace, and those changes are visible only to them. Once they're sure that their new feature works, they can promote their changes to the main development stream. This gives them the best of both worlds: version control without the risk of breaking the build.

Unfortunately, the private Workspace model relies on a connection to the AccuRev server; the Workspace check-ins are stored on the server, not the client. For developers like myself who often spend time working on laptops away from a network connection, it means that I lose source control while disconnected. The folks at AccuRev have assured me that they're working on providing an offline private Workspace model.

Working with Streams

A SCM system's branching model is frequently its greatest source of friction. Consider a team readying its product's first release. Bob and John both agree that it's time to cut release 1.0. After shipping 1.0, John will start to work on version 2.0, and Bob will do some maintenance work to get Service Pack 1 out the door. To track their work, they create three new Streams, a bookkeeping device that lets them associate which versions of files are associated with a particular release. This is AccuRev's most powerful concept. When you promote your changes to the Depot, you're really promoting your changes to the Stream to which your Workspace is attached. Unless you've explicitly created your own Streams, you're promoting to the Depot's default Stream, which shares the Depot's name.

In their Depot, the Streams are called R1, R2 and SP1. R1 and R2 are children of the Cassini Stream; SP1 is a child of the R1 Stream. Merging changes between different releases is often extremely time-consuming, causing teams to delay integration. The power of Streams becomes apparent when you start arranging them in hierarchies. When you promote a file, you're promoting it to the Stream that your Workspace is currently attached to. However, you can also promote changes from a Child Stream to its Parent Stream. To see this idea in action, let's return to our example.

[click for larger image] Stream Browser To track your work, you may create Streams, a bookkeeping device that lets you associate which versions of files are associated with a particular release. This is AccuRev's most powerful concept.

John and Bob update their respective Workspaces and begin to work. John updates app.cs by adding an important new feature: the ability to say hello to the user. This is what app.cs looks like when John's finished:

 using System;

 public class App {
   public static void SayHello() {
     Console.Write("What is your name? ");
     string name = Console.ReadLine();
     Console.WriteLin("Hello, {0}, name); }
   
   public static void Main() {
     System.Console.WriteLine("Hello, World!);
     
     SayHello(); }
 }

John keeps the changes in his Workspace and promotes his changes to his Workspace's backing Stream, R2.

Bob, however, notices the redundant reference to System in his copy of app.cs (which resulted from his and John's earlier changes to the same line of code), so he decides to remove it. Bob keeps the changes in his Workspace and promotes his changes to his Workspace's backing Stream, SP1.

While both John and Bob have promoted their changes to the same file, notice that they didn't have to merge their changes because they didn't promote those changes to the same backing Stream.

Bob then decides to make his change available to both the R1 and R2 Streams by promoting his changes from the SP1 Stream to the R Stream, and then from the R1 Stream to the Cassini Stream.

When John next looks at the status of his R2 Stream, he notices that the overlap flag is set on the app.cs file. This indicates that the backing Stream, Cassini, contains a different version of app.cs.

John realizes that he must manually merge the changes back into his copy of app.cs. To do so, he uses the Change Palette to tell AccuRev that he wants to resolve changes between the Source Stream, whose Workspace is Cassini_ john, and the Destination Stream Cassini.

John does a merge: The bottom-right window shows the changes in the R2 Stream, and the bottom-left window shows the changes in the Cassini Stream. John selects the Take My Change (right arrow) option, to accept the new call to his SayHello() method. Next, he notices that the reference to the System namespace is absent in the Cassini Stream's copy of app.cs, so he manually removes the reference to the System namespace. If John hadn't been careful, however, this would have been another opportunity for a lost update due to a manual merge operation. When he's finished, the merge window reflects the complex merge.

John uses the Keep Changes And Close command to commit his changes. Using the Change Palette, John promotes his changes to the R2 Stream, which has now been updated with the bug fix from the SP1 Stream.

Note that John had to explicitly merge the changes into the app.cs file, because both he and Bob had edited this file. But if he hadn't changed app.cs, the R2 Stream would have automatically inherited Bob's change to app.cs. This inheritance-by-default model reduces branch merging friction.

Wrapping It Up

AccuRev is a significant step forward in SCM. The private Workspace model reduces friction in day-to-day development, enabling developers to reap the benefits of an SCM system without risking the premature addition of changes to the main source control tree. The hierarchical Stream model reduces friction when it's time to integrate changes between different branches. Developers can simply promote changes to the appropriate Stream, and those changes become immediately visible to all child Streams of that Stream.

While AccuRev is a capable product, it has room for improvement. I'd like to see better integration of the AccuRev client with the operating system shell, better offline/disconnected support for laptop developers, and a simplified merge model that doesn't need to use the Change Palette for common tasks.

For more detailed information about AccuRev's unique concepts, download the manual from www.accurev.com and read the Concepts section. You can also download an evaluation version of AccuRev and request a trial 15-day two-user license to test drive the product for yourself.