The Case for Source Control
by
, 19-Apr-2010 at 02:18 PM (67296 Views)
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
Employment
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.