Sometimes we call it "version control." Sometimes we call it "SCM," which stands for either "software configuration management" or "source code management." Sometimes we call it "source control." I use all these terms interchangeably and make no distinction between them (for now anyway -- configuration management actually carries more advanced connotations I'll discuss later).
By any of these names, source control is an important practice for any software development team. The most basic element in software development is our source code. A source control tool offers a system for managing this source code.
There are many source control tools, and they are all different. However, regardless of which tool you use, it is likely that your source control tool provides some or all of the following basic features:
- It provides a place to store your source code.
- It provides a historical record of what you have done over time.
- It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
- It can provide a way for developers to work together without getting in each others' way.
HOW TO
My goal for this series of articles is to help people learn how to do source control. I work for SourceGear, a developer tools ISV. We sell an SCM tool called Vault. Through the experience of selling and supporting this product, I have learned something rather surprising:
Nobody is teaching people how to do source control.
Our universities often don't teach people how to do source control. We graduate with Computer Science degrees. We know more than we'll ever need to know about discrete math, artificial intelligence and the design of virtual memory systems. But many of us enter the workforce with no knowledge of how to use any of the basic tools of software development, including bug-tracking, unit testing, code coverage, source control, or even IDEs.
Our employers don't teach people how to do source control. In fact, many employers provide their developers with no training at all.
SCM tool vendors don't teach people how to do source control. We provide documentation on our products, but the help and the manuals usually amount to simple explanations of the program's menus and dialogs. We sort of assume that our customers come to us with a basic background.
Here at SourceGear, our product is positioned specifically as a replacement for SourceSafe. We assume that everyone who buys Vault already knows how to use SourceSafe. However, experience is teaching us that this assumption is often untrue. One of the most common questions received by our support team is from users asking for a solid explanation of the basics of source control.
Best Practice: Use Source Control
Some surveys indicate that 70% of software teams do not use any kind of source control tool. I cannot imagine how they cope.
Throughout this series of articles, I will be sprinkling Best Practices that will appear in sidebar boxes like this one. These boxes will contain pithy and practical tips for developers and managers using SCM tools.
We need some materials that explain how source control is done. My goal for this series of articles is to create a comprehensive guide to help meet this need.
Somewhat Tool-Specific
Ideally, a series of articles on the techniques of source control would be tool-neutral, applicable to any of the available SCM tools. It simply makes sense to teach the basic skills without teaching the specifics of any single tool. We learn the basic skills of writing before we learn to use a word processor.
However, in the case of SCM tools, this tool-agnostic approach is somewhat difficult to achieve. Unlike writing, source control is simply not done without the assistance of specialized tools. With no tools at all, the methods of source control are not practical.
Complicating matters further is the fact that not all source control tools are alike. There are at least dozens of SCM tools available, but there is no standard set of features or even a standard terminology. The word "checkout" has different meanings for CVS and SourceSafe. The word "branch" has very different semantics for Subversion and PVCS.
So I will keep the tool-neutral ideal in mind as I write, but my articles will often be somewhat tool-specific. Vault is the tool I know best, since I have played a big part in its design and coding. Furthermore, I freely acknowledge that I have a business incentive to talk about my own product. Although I will often mention other SCM tools, the articles in this series will use the terminology of Vault.
The World's Most Incomplete List of SCM Tools
The SCM tools that I mention most often in this series are listed below, with hyperlinks for more information.
- Vault. Our product. 'Nuff said.
- SourceSafe. Microsoft. Old. Loved. Hated.
- Subversion. Open source. New. Neato.
- CVS. Open source. Old. Reliable. Dusty.
- Perforce. Commercial. A competitor of SourceGear, but one that I admire.
This is a very incomplete list. There are many SCM tools, and I am not interested in trying to produce and maintain and accurate listing of them all.
Audience
I am writing about source control for programmers and web developers.
When we apply some of the concepts of source control to the world of traditional documents, the result is called "document management." I'm not writing about any of those usage scenarios. When we apply some of the concepts of source control to the world of graphic design, the result is called "asset management." I'm not writing about any of those usage scenarios.
My audience here is the group of people who deal primarily with source code files or HTML files.
Warnings About my Writing Style
First of all, let me say a thing or two about political correctness. Through these articles, I will occasionally find the need for gender-specific pronouns. In such situations, I generally try to use the male and female variants of the words with approximately equal frequency.
Discerning readers may notice my tendency to use female pronouns in examples which are positive and male pronouns in situations where the hypothetical person is a bonehead. In part, I use this approach because it seems safer for me to aim my errors of political correctness in that direction. I would also admit that this habit somewhat reflects my general belief that I was born a member of the gender which tends to evidence less character and virtue.
Second of all, please accept my apologies if my dry sense of humor ever becomes a distraction from the material. I am writing about source control and trying to make it interesting. That's like writing about sex and trying to make it boring, so please cut me some slack if I try to make you chuckle along the way.
Looking Ahead
Source control is a large topic, so there is much to be said. I plan for the chapters of this series to be sorted very roughly from the very basic to the very advanced. In the next chapter, I'll start by defining the most fundamental terminology of source control.
Eric Sink is a software developer at SourceGear who make source control (aka "version control," "SCM") tools for Windows developers. He founded the AbiWord project and was responsible for much of the original design and implementation. Prior to SourceGear, he was the Project Lead for the browser team at Spyglass (now OpenTV) who built the original versions of the browser you now know as "Internet Explorer." Eric received his B.S. in Computer Science from the University of Illinois at Urbana-Champaign. The title on Eric's business card says "Software Craftsman." You can Eric at [email protected]. This series of articles from Eric Sink are part of his online book called Source Control HOWTO, a best practices guide on source control, version control, and configuration management. You can find it online at http://software.ericsink.com/scm/source_control.html.
