Subversion Version Control. Using The Subversion Version Control System in Development Projects

1.2. Why Use It?

You know what version control is; why do you need it? Especially for a small team project, what benefit does a good version control system provide that outweighs the cost of setting up and learning how to use it? Let's look at some of the reasons why version control is critical in any development project, small or large.

1.2.1. Data Integrity

A good version control system helps to protect the integrity of your data. By keeping a revision history, there is no worry that if code is removed in an edit on one day, it will be lost when it is determined a week later to have in fact been necessary.

Having a central project repository can also help with data backup. If developers regularly commit their data to the versioning system, it can be backed up nightly in one chunk and offloaded to backup storage, with few worries that weeks worth of unfinished data will be sitting on a developer's desktop, waiting for the inevitable hard drive failure.

1.2.2. Productivity

By freeing developers from the drudgery of by-hand integration of work, a version control system can greatly increase productivity. As projects grow larger than one or two people, even the most well organized of processes will lose countless man hours toward integrating the work of multiple developers. With a version control system, developers are able to test changes against the latest work of their peers, identifying and fixing conflicts before they become unmanageable. They are also able to experiment more easily, free to branch and modify code without worrying about whether their changes will affect the stability of the main project or the work of others. If an experimental change breaks something, it can quickly and easily be rolled back or compared with the original code to see what changed.

A version control system also protects against productivity lost to re-implemented work, not only by avoiding losses of data that was incorrectly deemed to be unnecessary, but also by making each developer's work readily available to other developers on the project. If developers are able to easily see where the others working on the project are going with their work, they will be less likely to duplicate effort. Even in a well-organized project, it can be easy for two developers working on closely related sections to accidentally implement the same piece of functionality. If all developers regularly commit their work to a repository, this becomes much less likely to happen.

1.2.3. Accountability

In any development process, it is important to know exactly who added each bit of code to a project, as well as when they did it, and who has made modifications since then. This sort of fine-grained accountability is important not only for technical reasons (for example, who to go to if a section needs to be fixed), but also for purposes of legal defense. In recent times, there have been a number of high profile cases, involving both open source and closed source projects, that have hinged around allegations of source code being illegitimately placed into other projects. In light of the potential liability that the maintainers of a project could have in these sorts of cases, having a version control system that makes each contributer accountable for his own contributions seems to be a prudent precaution to take, especially if you are maintaining an open source project, where little may be known about the contributer, and money to fight a legal battle may be tight or nonexistent.

1.2.4. Software Engineering Process Support

Good software (even open source projects) are developed with a software engineering process. By software engineering, I mean the application of disciplined development policies aimed at ensuring that the end product of the process will meet the desired goals in a timely manner, and with the highest possible standards of quality.

A good software engineering process involves a number of different processes and policies, such as good overall project design, peer review of project components, tracking of bugs and other issues, and quality assurance testing. None of these are explicitly supported by most version control systems, but many version control system features (such as hook scripts and logs) can be an important tool in supporting a project's software engineering policies. For example, a version control system (VCS) may be set to automatically e-mail an issue tracking system in order to report a bug fix, or a system could log peer reviews, and through the use of hook scripts, disallow any code that hasn't been peer reviewed to be merged onto the project's main source trunk.

1.2.5. Development Branching

As projects progress over time, branches will naturally occur. Old releases will need to be supported with bug fixes. New projects may be spun off from existing code bases to serve emerging markets. Whatever the reason, branches will happen, and unless the relationship between branches is carefully maintained, they will tend to diverge irreconcilably. Issues that are fixed in one branch will go unfixed in another. Features implemented in a divergent branch will be unusable in the main trunk. In general, keeping even a semblance of consistency between different branches of development will be a maintenance nightmare.

If used in an organized and consistent manner, the branching features built into most version control systems can greatly reduce the headaches associated with maintaining divergent branches of development on a project. By using the commit logs generated by the system, as well as its capability to merge changes from one branch to another, changes that are applicable to multiple branches can be cleanly implemented on a single branch and then applied to the other branches. Similarly, a new feature added to a branch can be migrated to other branches where it may be useful.

1.2.6. Record Keeping

A version control system will help to enforce policies that can ensure a project keeps quality records for later use. In addition to the aforementioned records of who committed each change, repository commit logs are invaluable for storing plain-English descriptions not only of what changes were made in a given commit, but why they were made. In many cases, commit logs can even be verified against certain patterns, to enforce guidelines for logs entries that are in place for the project.

In addition to providing a record of what has gone into each commit, logs kept by a version control system can be used for a variety of applications. For example, they could be used to create a changelog at a release, or to automatically tie into an issue tracking system.

1.2.7. Distribution of Work

In our modern Internet age, life is becoming more and more distributed, and nowhere is this more true than in software development. Open source projects are (almost by definition) developed in a distributed nature, by developers all over the world, but even in the closed source corporate world, distributed development can be a major issue. Regardless of whether a developer is telecommuting from across town or an outsourcing firm in India, distributed development can be difficult to deal with.

Version control can make dealing with distributed development easier, by automating much of the workload of exchanging and merging the work of different developers. As developers work on their projects from remote corners of the globe, the repository makes the latest work of their coworkers readily accessible at any time. Combined with good communication habits, using something like e-mail or instant messaging, distributed development can become almost as painless as being the next cube over.

1.2.8. Rapid Development

Recent software development methodologies have been moving toward rapid, flexible development, with processes like Extreme Programming (XP) and Agile Development being adopted with increasing frequency. These rapid development methods accentuate policies of small incremental change and frequent refactoring, which cry out for version control. By using good version control practices, a project will maintain extremely useful code histories that delineate the many twists and turns rapidly developed code can take. Additionally, the central repository of a version control system is perfect for automating the frequent systems builds called for by an Agile process.