View RSS Feed

Development Team Blog

The Case for Source Control

Rating: 45 votes, 5.00 average.
Source Control has been discussed in our forums off and on for years and it appears that some developers are not convinced that using it will benefit them. If you are not currently using source control, you should seriously reconsider doing so. I hope this article clears up most questions you have.

Source control is often also referred to as "version control" or "revision control". I prefer the term source control because it does so much more than simply tracking revisions, as I will discuss below.

For starters, using source control is a must. It's not an option, it's an absolute need for any developer. For example, a stackoverflow question titled Good excuses NOT to use version control, garnered more votes for the answer There are no good reasons not to use version control. Not one. than any others. The other answers state the same point, just not as politely.

Developing without source control is akin to developing with notepad instead of a modern fully featured development Studio. Theoretically, there should be nothing you can't do manually that you can do in a Studio, but in practice, doing so would be much less efficient, tedious and unreliable.

If none of the above convince you, then let me just tell you that you are missing out on some awesome cool tools that make you a better developer. Read on to see why.

It's Not That Hard!

If you are not currently using source control and have never used source control, one of your reasons, or possible THE reason, is that it seems like it will add a tedious complication to your development process. Part of this is but we've always done ok without it syndrome. Sure, life without wine is ok, too, but I wouldn't want to do without it.

I started using source control about a decade ago and when I think back to what I did before, I don't think "Gee, that was way less complicated, I wish I could go back". Instead, I think "What was I thinking? What a mess it was making copies of files to track changes and copying files back and forth to and from the network. How tedious, messy and error-prone!"

Of course source control will take some getting used to, just like any other tool or software, but once you are use to it, it will take so many worries off your mind.

Safety from Overwriting Other Developers' Code

If two developers check out the same file and each makes changes, the system keeps track of each of the before and after versions of the file. For example, if John checks out File A, makes changes and checks it back in, then Marcia checks out File A, makes changes and checks it back in, there will be 3 versions of File A in the source control system, 1 before any changes, 1 with John's changes and 1 with Marcia's changes.

We use SourceGear Vault in CVS style (edit, merge, commit). Summarized very broadly, each developer working on the same workspace has a local copy of the workspace. Before we start working, we perform a 'get latest' action, which refreshes our local copy with all of the latest changes to the workspace that anyone else has checked in. Then we make our changes and check those in when we are ready to commit (meaning that the code compiles and won't break the workspace for anyone else).

Note that a check in is a separate procedure from saving a file; it checks in already saved files. Checking in and out are procedures that the developer controls. You or your team can create your own rules for this. For example, we never check in anything that is not self-contained and running. Depending what you are doing and where you are in the development, cycle check-ins may occur monthly, weekly, daily or multiple times a day. Your source control strategy can be customized to suit your needs and preferences. Modern source control systems are flexible enough they can be configured to work the way you want them to work, which can mean minimum changes on the developer's part. A future post will discuss these procedures in greater detail.

Change Tracking

This is the main reason I use source control even for my own personal projects that nobody else will ever work on but me. This is by far the simplest way of tracking changes in your code and quickly adding a note to a set of changes. For example, it allows me to very quickly check in changes or fixes to a single targeted issue. If I change 3 files to fix one bug, I can check these in as a set and add a note "fixes bug #1234" that will apply to all of these files. Months or years later, I can see exactly what I changed for this single issue.

The image below shows an example of this. I selected a folder in a project and asked for a history list. The image shows the history showing 3 files in this folder that were changed for a single bug fix.

Then I drilled down into the history of one of the files in this bug fix and the details, seen below, show my check-in comments (including my typos) that are applied to all files for this bug fix and it even shows me that another file checked in with this set is in another folder in the project.

Saving Time, Hassle and Preventing Errors

A source control system won't forget to check in one of the 3 files I changed, where without that, I may forget that I changed 3 files and only copy 2 to the main "working" workspace, thus potentially breaking something. It also allows me not to worry about dealing with this. I know the system tracks my changes and I don't have to.

For example, in the image above, the system remembered, more than 2 years later, that the files I checked in for this bug fix included a file in a different folder. Can you imagine tracking this manually?

We're all human, and this is the perfect task for a computer so that I can focus on coding, not tracking which file needs to be copied or merged.

Reverting to An Older Version of a Project

How often did you just try something, worked for a couple of hours, then got stuck and just wanted to go back to the version that worked? With source control, you can do this really quickly and easily. Just as importantly, you can do this many times. For example, it's easy to check out a version of your workspace from, let's say, 3 different revisions, so you can compare them side by side.

This really changes your mindset as a developer. Since I know it's easy and no hassle to revert to earlier versions, I might try something I might not try if it was more of a hassle to deal with tracking and reverting the changes. I can even label a set of files as "working version before I tried that crazy thing".

If someone reported tomorrow that bug # 4711 is not fixed, I could go back now and see exactly what code I changed and compare the changes, line by line, to the versions of the files just before I made this change, or even to the current version of those files.

The image below shows a line-by-line comparison of one of the changed files to the previous version. Vault has a built-in diff too, but I set up mine to use Scooter Software's Beyond Compare.

There's simply no way to get this level of capabilities without source control.

More Likely To Do The Right Things

By removing a lot of negative factors, such as time, hassle and overhead, that prevent us from doing things we all should be doing, source control software causes us to do things right:

  • Commit changes more often, because it's so easy to do
  • Add comments to files checked in, because it's so easy to do
  • Try new things without messing up existing projects

It also allows us to do things we might not have the capabilities, resources or desire to do otherwise:

  • Compare any version of files and projects against any other version
  • Commit and group code changes targeting very specific issues
  • Ensures we don't forget about some changes we made


Last, but not least, there are a lot of companies who simply will not hire or keep a developer who doesn't use and/or doesn't know how to use source control. This is not just a nice thing to have on your resume, it is absolutely mandatory. It is simply assumed that you know this and not knowing how to use source control can absolutely cost you a potential job. See the stackoverflow post above for the prevailing attitude regarding this issue.

There are many low-cost and free source control tools available today that cost is no excuse.

  • SourceGear Vault is free for personal use. Vault is the tool we use at Data Access Worldwide for Visual DataFlex development and I would highly recommend it. The one potential negative is that it runs on Microsoft SQL Server, so it has a larger overhead than some others.
  • Subversion is widely used, mostly because it was one of the first fully-featured free systems available that allowed large business customers to migrate away from commercial systems.
  • Git, written by Linus Torvalds of Linux fame, is gaining in popularity and is the most widely used of the new class of source control tools called distributed version control (DVCS). It has a very small footprint and is extremely fast. However, I would not advocate this for someone just trying to learn source control. It requires some studying to use properly. While there are GUI front-ends available for git, I've heard negative things about these (yes, anecdotal evidence, but from enough folks to be cautious), and the vast majority of users use git from the command line.
  • Many more.

I am working on another post that shows how to use source control with Visual DataFlex.

I urge you to do some research into source control and start using it. You will have to invest some time into this, but the payoff is immense. You should consider your needs, such as remote access, and use a system that meets them. You will then likely have many choices, but ultimately what you use for source control isn't nearly as important as using something, anything!

An excellent starting point is Eric Sink's Source Control HOWTO. Eric is the founder of SourceGear, the company that makes Vault, among other products, and he knows his stuff.
Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	VaultHistoryBT4711.PNG 
Views:	3454 
Size:	16.7 KB 
ID:	3806   Click image for larger version. 

Name:	VaultHistoryBT4711DrillDown.PNG 
Views:	3494 
Size:	57.8 KB 
ID:	3807   Click image for larger version. 

Name:	VaultBT4711ChangesInBC.PNG 
Views:	9830 
Size:	92.3 KB 
ID:	3808  


  1. Mark Rutherford's Avatar
    Version control = lifesaver, time saver..... good idea.... And I am a subversion guy.
    Project Scotty..... love the name
  2. Michael Mullan's Avatar
    OK I Installed Vault.

    Now, about that blog on How to use with VDF Studio...
  3. seanyboy's Avatar
    It's worth looking in a bit more detail at DVCS, but if you're on Windows, then Mercurial is probably a better option than Git.

    Here's a tutorial on using mercurial.
    And the inspiration for that tutorial.

    We're using subversion at the moment, and it's not pretty. I'm pretty convinced we're doing it wrong though. I'd like to see how other DF programmers use it.
  4. Focus's Avatar
    Developing without source control is akin to developing with notepad instead of a modern fully featured development Studio
    Have you done any web development recently Dennis ?
  5. wila's Avatar
    Well put Dennis, I completely agree.
    Here's another vote for Subversion, personally I find it much more flexible and easier to use as Vault. But that's just my opinion of course.
    Also see this article on vdf-guidance on how-to use it with VDF: Using Subversion
    It's a little dated now as the windows client has improved since then, but it gives you the right idea.

  6. Ola Eldoy's Avatar
    I wholeheartedly agree with Dennis on this. Developing without source control? There's no excuse!

    Like seanyboy, I too would like to recommend looking into Mercurial. To get started quickly, install TortoiseHg, which is a complete GUI for Windows, and it includes the pdf version of a very good book on using Mercurial. To begin with, simply use Mercurial locally. If you're a one person shop, you don't even have to set up Mercurial on a server. It's so simple, and the benefits are so great, that there is absolutely no excuse to not use it!
  7. Clive Richmond's Avatar
    Excellent blog Dennis. I'm looking forward to the next instalment.
  8. Marco's Avatar
    We use Visual Sourcesafe. It does all what we need to, although when budget allows we might move to Vault as it seems more feature rich.

    But no matter what you use, use it, you will never look back and wonder how you worked without!
  9. Dennis Piccioni's Avatar
    Good article Wil, sorry I wasn't aware of it. I'll use it as a resource for the next installment.
  10. Ian Smith's Avatar
    All the people who have installed the Tortoise SVN client already have a full version control system. With Tortoise you can use a folder on your local hard disk as the repository you do not need a server.
  11. Dennis Piccioni's Avatar
    The follow-up posts are now up -- see the announcement here.
  12. Raphael Theiler's Avatar
    I use Mercurial for all my private projects (hosting the repositories on my own server). For university projects we use either Mercurial or SVN and at my workplace we use the Vault. I've compared all the different systems and I like Mercurial (with TortoiseHG) the most. I would'nt recommend SVN (since mercurial does a little bit more, is almost as easy to use (at least with TortoiseHG) and you have this really cool "graph thing" which shows who is branching and who commits to which branch and who merges what, etc)
    The Vault server seems a bit easier to setup on a windows server, but i miss the Windows Explorer shell integration, as well as the fancy GraphLog of mercurial.
    A possibility to integrate Mercurial or the Vault into the Studio would be awesome. One of the best integrations of source control in a IDE I've seen so far is AnkhSVN (for Visual Studio). Here's a screenshot:
  13. Dennis Piccioni's Avatar
    Marco Kuipers has written an excellent Wiki post for using git here.
  14. Ezequiel Marin's Avatar
    Here we use, for decades, Control Version made by VDF created by us
    Together with Mysql Server, all the our sources are stored, recovered and compared from SQL Database.
    This another way to make it