The purpose of this article is to explain the basic tools provided by source control tools for a happy and harmonious household. Advanced source control tools like the Evolution Source Control System provide a variety of methods to minimize disruption during collaborative development.

Atomic Transactions

Atomic transactions basically allow you to perform a series of operations as a single unit. This is important in several regards, best explained by example.

First, consider the situation where you have added a feature that required that you change, let’s say, 10 files. If any one of these edited files is out of date, the project cannot be compiled. After you’ve checked in 5 files, another user tries to get the project to bring their working folder up to date. That user will only get the 5 files you have managed to check in so far, breaking their project.

Now if you were to check in your 10 files atomically, they are effectively committed at the same time, eliminating this problem. Until you have completed all operations that are a part of an atomic transaction, none of them have actually occurred yet.

The above situation is rare; the more common condition is also the more significant reason that atomic transactions are important.

Let’s say that you have some files checked out in several projects. Now you want to check everything in that you have changed, but half-way through the process of checking in your files, you lose your wireless connection. Or perhaps an error occurred on one of the files halfway through.

Without atomic transactions, you have again left the repository in a state that cannot be compiled.

Atomic transactions either all fail or all succeed, preventing the possibility that an unforeseen situation will cause your teammates to have a set of mismatched files.

Works in Progress

Source control should also be used as a form of sophisticated backup. What if you have been working on a set of changes for a few days, but are not finished with your work? It is bad practice to keep files checked out for long periods of time. In fact, you should check in your work every day before going home. You may need a few more days to complete your work, but you want to ensure that your work can not be lost if your hard drive crashes or in the case of some other disaster.

The discrepancy is that we are encouraged to check code in often and are chastised when we keep files checked out for too long, but by checking in incomplete code we are causing our teammates to have broken projects that cannot be compiled.

An idea unique to Evolution is the “Work in Progress”. When you check in files as Works in Progress, you are effectively just shelving your work. Your changes are only visible to you. All other users do not even see the changes you make while you are in Work in Progress mode.

You can keep checking in as a Work in Progress to continue your “session”. This also has the side effect of shielding you from needing to merge with other changes your teammates might be making.

When you check your work in normally, Evolution will force you to merge if necessary. Multiple users can even have simultaneous Work in Progress sessions. As with a normal concurrent checkout, he who checks in first wins and gets off easy. Everyone else needs to merge. This enables you to back your work up, safe in the knowledge that you are not negatively impacting your co-workers’ productivity.

Private Workspaces

Private workspaces are a copy of the project you are working on that is available on the server only to you. This is not to be confused with your local working folder.

A project in source control is a public space. This is where everyone plays. This is where you ultimately get the files for your working folder, and ultimately where any changes that you make will end up.

Private workspaces are an intermediate stage between the public project space and your working folder. Just like your working folder is available only to you and anything you do in it does not in any way affect your teammates until you commit the changes to source control, anything you do in your private workspace on the server does not in any way affect your teammates until you promote your changes into the public space.

Users work in their own workspace, and when they are ready, they synchronize their private space with the original parent.

This is a complicated subject that will be addressed in detail in a future article.

The Bottom Line

Since the most important reason to use source control is to facilitate collaboration, it would be a shame to throw the benefits out the window by incorrectly using it.

The thing to always keep in mind is “How will my actions affect my teammates?”

Evolution, along with any other source control tool worth its weight, makes it easier to you to work without negatively impacting your teammates so that you can expend your cycles thinking about code instead of management.

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.