Image may be NSFW.
Clik here to view.
A version control system (“VCS”), or “change-tracking system,” keeps track of the files that belong to a development project in a systematic manner. Such files can include software source code, graphics files, third-party code libraries, technical documentation (e.g. Word documents and Visio diagrams), and project management files (e.g. Excel spreadsheets). It records exactly what changes were made, by whom, at what point in time, and in conjunction with what other changes. This gives the developers full control over being able to review the history of those changes, as well as the ability to roll back or undo any of them.
Version control systems have been around for decades. Over time they’ve gotten better, faster, cheaper (free). They are smarter than ever, and they are easier to set up and maintain than ever. I simply could not imagine doing software development these days without a version control system in place, even for the tiniest of projects.
Some Version Control Terminology
| Term | Definition |
|---|---|
| VCS | Generic term for any version control system (e.g. Subversion, CVS, StarTeam, Visual Sourcesafe). |
| project | A collection of interdependent files that are managed together. Typically, this includes all of the files that contribute to building a single executable (EXE or DLL), or a single web site. |
| repository, VCL | The repository, or “version control library,” is the location where the checked in copies of the controlled files are kept. |
| working folder | The location(s) where the checked out copies of the controlled files are placed so that the developer can work with them. |
| sandbox | Some VCS use “sandbox” to be synonymous with working folder. Others use it to refer to a throw-away project within a repository that newbies can use to get used to working with the VCS. |
| commit, check in | Saving a change, or a set of changes, to the repository. |
| update | The act of synchronizing your working folder with the repository, so that your working folder gets caught up with changes that the other developers have been committing. |
| diff, diffing | Using a compare tool to display the differences between two versions of a file. All VCS have built and compare tools, and most allow the users to configure calling their own compare tool of choice. Most often, the head or tip-revision of a file is compared to the one in the working folder, but there are also times when it is useful to compare an older version of a file to the working folder, or even to compare two different older versions of the file with each other. |
| 3-way merge | when multiple developers are working on the same project, it is sometimes necessary to reconcile conflicting changes. All VCS offer a way to do this, usually in the form of a 3-way merge tool. |
| head, tip-revision | This refers to the latest version of any particular file as it resides in the repository (within the trunk, or within a branch). |
| tag, label, build, milestone, snapshot | Synonymous terms for the VCS concept for remembering the state of each part of a project at a given point in time (e.g. as they were when a beta test version was built). |
| revision | one increment of change as recorded by the VCS. Every time changes are committed, the revision number is bumped. Some VCS use separate revision numbers for each file. Other VCS, such as Subversion, use one master sequence of revision numbers for all of the files in the project. Some VCS distinguish between casual tags (labels) and significant tags (builds, or milestones), but usually that is just a matter of the text used to describe the tag. |
| trunk, branch | Concepts by which the VCS tracks multiple, parallel development efforts against roughly the same set of project code. For example, one developer might be working on a bug fix patch that will be called version 4.01 (a branch), while five other developers proceed with working on the 5.0 release (trunk). At the same time, a seventh developer is working on and experiment to incorporate a new graphics package (a different branch). Usually, eventually, the changes from the branches and tags get merged into the trunk. |
Benefits of Version Control
Speeds up Development — The single biggest element that governs the pace of software development is confidence, or looking at it the other way, fear. Now, I am not referring to a project managers’ confidence in the development teams’ abilities here, but rather, to the developers’ confidence of the integrity of the code base. It’s a constant worry: When a developer makes a change to one part of the source code, will that cause something to break elsewhere? Today’s best practices offer ways to mitigate these fears, both proactively and reactively. Using a VCS is one reactive way. With a VCS in place, at least, if a change is found to have an adverse reaction, that cause can be quickly identified and either reverted or adjusted.
Supports a Consistent Software Engineering Process — Utilizing a VCS can be a major focal point in improving a software engineering process. The developers are introduced to a formal method for incrementally logging their work which emphasizes and reinforces the need for thoroughness.
Multi-Developer “Traffic Control” — This is probably the biggest benefit to using a VCS. Whenever two or more developers work on the same project, a system is required to avoid conflicts. Old VCS managed this issue by only allowing one developer to have write-access to any particular file at a time (“locking”). Newer systems include tools for automatically merging changes.
Consistent Progressive Backup Copies — VCS software maintains every version of every file that is ever checked in, going back as far as desired. If there is ever a question as to what transpired during the development cycle, the older copies of a file can be retrieved. Comparison tools then make it easy to highlight the changes so that they can be studied, revoked/reverted, or further modified. Note: Whenever it change is reverted, it’s always recorded as a new change that reverses the old change. So, even in the case of reverting a change, the history is maintained.
Past Build Snapshots — Let’s say that you are working on version 2.0 of your software. In the past you have released versions 1.0, 1.1, and 1.2 (in addition to various beta tests), and all three versions are still in use by various customers. Suddenly, a customer who is still using version 1.0 reports a problem that you cannot reproduce using your latest and greatest source code. What do you do? If a VCS is in place, you would be able to retrieve a set of source code exactly as it was when version 1.0 was built and work with it to track down the problem. You could then make sure that the problem is eliminated in the newest source. The problem may have been overcome by recent developments, which explains why it can’t be reproduced, or perhaps, recent developments have compounded or masked the problem. Either way, being able to run and debug the old build will confirm this.
The way it works is this: Any time a new version of the software is built, the current state of each file in the software project is “tagged” as belonging to that build. Then, if you ever need to recall the source code for a particular build, you can (either for one particular file, or for all of the files).
| Revision Number | Tag/Label |
|---|---|
| 10 | |
| 11 | 1.0 Beta A |
| 12 | 1.0 Beta B |
| 13 | |
| 14 | |
| 15 | 1.0 Beta C |
| 16 | |
| 17 | 1.0 Final |
| 18 | |
| 19 | |
| 20 | |
| 21 | |
| 22 | 1.1 Beta A |
| 23 | |
| 24 | 1.1 Final |
Branch Development — Expanding on the example above, let’s say that the user who reported the problem with version 1.0 demands that you provide a patch to fix the problem. The user is not willing to wait until 2.0 is released. This calls for “branching.” To create the patch, you would check out all of the source files as they were for revision number 17 (tagged “1.0 Final”), create a branch off of revision 17, make the corrections, and then commit the modified files to this branch. if other bugs or problems are reported against version 1.0, then they can also be fixed using this branch. The branch would then begin to collect its own set of tags (“1.0a Beta”, “1.0a Final”, “1.0b Beta”, “1.0b Final”, etc.). Most VCS provide tools making is easy to merge branch revisions into the trunk (or into other branches), keeping everything in sync.
Subversion – An Open Source VCS
One of the most popular VCS in use today is called Subversion. It is robust, powerful, cross-platform, and best of all, free.
There are two parts to a Subversion installation: the server, and the client. The server maintains the repository. The client maintains the working folders. There are different servers and clients available for different operating systems. For example, you could run a Subversion server on a Linux box and while some developers connect to it via a client that is running on a Windows box and others connect to it via a client that is running on a Mac. Here is a link to the official Subversion site, along with a link to the most commonly used client. And you’ll find further links to other implementations on the official Subversion site.
The Subversion Server
Latest Version: 1.4.4 (June 8, 2007)
Platform: Any version of Windows, Linux, Mac, others.
Price: Free (FOSS)
Download Link: subversion.tigris.org
Subversion Clients and Plugins
Some subversion clients operate as standalone executables. Others operate as plug-ins to operating system elements. (For example, TortoiseSVN is the most popular client for Windows. It operates as a Windows Explorer extension.) yet others operate as plug-ins to specific development environment tools (such as the Subclipse extension for Eclipse). A complete list of Subversion clients and plug-ins can be found midway down this page: subversion.tigris.org/links.html
Related articles: