Introduction

Articles in the Series • Part I: Introduction • Part II: Dataflow, the Repository, and You • Part III: Concurrent Development • Part IV: Differences between Asset, Workflow, and Process Management • Part V: Workflow Management • Part VI: Process  Management

Figure 1: Client-Server Source Control

In Part I, we covered the basic concepts of source control. Using a source control tool, you gain the ability to track historical revisions of digital assets (source code), as well as the ability to work collaboratively. This time we will discuss how to actually use it.

The Evolution Source Control System uses a true client-server architecture, like many other enterprise-level tools. There are some products available that are peer-to-peer, but it is beyond the scope of this article to discuss their merits or faults.

In client-server source control systems, the server controls the library of development assets. Once a digital asset is checked in from the client, its contents are never directly changed within the repository. Think of the repository as a static record of the past. On the client side maintains a copy of the portion of the repository you are working with, which you make changes to by checking files out from the server, changing them, and checking them back in.

Think of the changes that are made client-side as potential future realities of the repository. Every developer is playing god and creating his or her own version of the universe. When they're ready, they commit their altered reality to the repository, thus making it "real" forever.

The important points to remember are that the server is maintaining a static record of versions of your digital assets created over time, and during the course of development data is flowing back and forth between the clients and the server. The rest of this article will discuss the specifics of this data flow.

From the Repository to Your Local Working Folder

When a client pulls data down from the server, it is usually called a "Get" operation in source control systems. The local copy of the data can then be edited and checked back into the repository.

It is recommended that the data inside your repository be structured so that it is buildable. This means your code tree should be arranged such that when the client side gets an entire code tree from the server, the project files can be opened and complied as-is without any need to move files or folders around.

Figure 2: Server to Local Mapping

To get data from the server, your client software needs to know where to put it. To address this need, source control tools have the concept of a "Working Directory". This is simply a mapping of logical server constructs to a physical location on your computer.

When a Get operation is performed, the client copies files from the server and places them in the corresponding location in your Working Directory.

If one of the files you are copying from the server already exists in your Working Directory, source control systems usually calculate the state of the local file first and determine a course of action accordingly. This is done to minimize server load and bandwidth usage.

When a file is "Current", no action is taken. If the file was "Missing", then it is retrieved from the server. Usually in any other state, source control tools will confirm if an overwrite is desired.

From Your Drive to the Repository

So you have checked a file out and made changes that you want to commit back into the system. It is generally a very straightforward process. The file is copied to the server, given a unique identifier in the repository, and is marked as the new current version.

In the case of using concurrent (as known as shared) checkouts, someone else may have created a new version of the file since you originally checked the file out. In this situation, you will need to merge the files.

Merging is simply reconciling differences. Most source control tools offer a utility of some type to help you with this.

Evolution offers a merge tool that displays both your altered file and the version from the server you are reconciling with side by side. You can then move changes, remove changes, or add changes before committing the file to the server.

Figure 3: Merging Differences

It is also a good practice to always attach a comment of some sort to your changes. There is not one source control tool that doesn't provide this feature, with very good reason. Even though the reason for the change seems perfectly clear and logical now, imagine a year from now (or even a week from now), and thousands of lines of code later. Will you remember exactly why you made that change?

An even better reason to make liberal use of comments is to alert anyone else in the future that needs to alter the file. Your simple, concise comment could save them precious time instead of trying to decipher why a change was made.

Stay Tuned

With this article, we have covered all of the necessary basic to start getting into the nitty gritty of source control next time. I've talked a little about concurrent development at a simple level. In Part III, we'll get into the specifics on how this works.