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 a digital asset (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 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. We never directly change the contents of the repository. Think of the repository as a static record of the past. On every client, we have a copy of the repository that we make changes to by checking out files, 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 point is that, during the course of development, data flows back and forth between the clients and server. The rest of this article will discuss the specifics of this dataflow.

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 data is then edited and committed back to the repository.

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

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, files are pulled from the server and placed in the corresponding location on the client’s drive.

If the file already exists on the local drive in the working location, as an efficiency consideration, source control systems usually will calculate the state of the local file and determine a course of action accordingly.

There are many states a file can be in:

Current - The file is in sync with the latest server version.
Modified - The file is different, but the user owns a lock on it, so it is assumed it is intentional
Renegade - The file is different and the user does not own a lock on it, so it is assumed the change is unintentional.
Old - The file is a previous version from the server; this usually indicates that someone else has made a change to the file.
More Recent - The file is newer than the current version on the server. This is a more advanced state that only some systems take into account, including Evolution.
Work in Progress - This is an Evolution specific state that will be explained later.
Missing - The file is in source control, but not in the corresponding local working folder.
Uncontrolled - The opposite of “missing”, the file resides in the local working folder, but is not in source control.

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 to the system. Checking in a file is really just creating a new version of the file on the source control server. It is generally a very straightforward process.

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

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.

About the Author

Nick Ni is the Director of Technology of ionForge Company and the chief architect of the Evolution Source Control System. He has been a part of software teams of all sizes, developing products for consumers (such as PowerDesk, ZipMagic, and SystemSuite) to enterprise applications for financial institutions. He has led the development of Evolution from inception in 2001 to delivery in 2003 to the present time. He has been researching and implementing solutions for development lifecycle management for the last 5 years.

You can visit:
ionforge.com for more information about the Evolution Source Control System.
forums.ionforge.com to read more and ask questions.
blog.ionforge.com to get information directly from the Evolution Development Team.

(c)2005 ionForge Company. All rights reserved.