Methods of programming have evolved to allow programmers to make better use of their skills in conjunction with others, allowing creation of vast and complex programs, for example in the creation of operating systems. Collaborative coding, as a result, is now the standard way for most programs to be made. Programs, prior to newer languages like Java, were written procedurally. This meant they were a simple list of instructions in a sort of “Step 1: Do this- Step 2- Do That-” list. This of course greatly limited the ability of programmers to work on a single program together. The program had to be cut into chunks for individual programmers to work on, causing frequent problems, as each worker needed to know how his colleagues were going about their assigned task. Each individual’s workload was inter-dependant on everyone else’s. In more recent times programming has undergone a paradigm shift, becoming ’object-oriented’ in nature. This not only means that programmers thought of code as separate logical objects, it meant that code could be much more easily separated, allowing different elements to be worked on with much less hassle.

Enter the Version Control System. A VCS enables users to actively manage projects they work on, be they alone or in a group. The project is kept on a server in a special folder structure, with the user’s working copy stored locally. When a user makes a change worth keeping they ’commit’ their local version to the server, which merges the changes they have made with the old work to create a new version. Behind the scenes it is important to note that, from version to version, only the changes made to a document are saved, not entire documents. This saves a lot of space on the server, and is obviously a wise move. If a user mucks up what they were working on, be it source code or an important report, they need only revert to the previous version of the work. Updating the master project folder frequently ensures the loss is minimal. If a user wants to take the project in their own direction they can ’branch’ the project, creating their own copy of everything, with its own revisions. Later, if their changes are useful, they can merge the two branches, or simply continue creating two different projects. The flexibility provided for allows for a host of options, and if everything was messed up 9 revisions ago it is trivial to revert to the version before everything went wrong.

These are the basic functions of a VCS, functions which have grown from requirement and genuine ingenuity on the part of the creators of each system. These systems usually grow out of a desire to improve upon the features of an older VCS, and to evolve the abilities of such a program. Concurrent Versions System (CVS) was, for years, the most popular and widely used system for keeping track of group work. CVS performed all the vital functions of a versioning system, and as such was used by many groups. The reason for this being was that it just worked. It had a few fundamental flaws, many of which were only noticed by more advanced users. These flaws included the lack of a simple 1 command commit, something that became troublesome and annoying even though it was not viewed as a flaw in the original design. As versioning became more important and small changes were increasingly committed it became clear that entirely new software would be the most beneficial to individuals and teams.

Subversion is one of CVS’s many replacements, as well as being an incredibly popular piece of versioning software. Used as the de-facto standard for projects that have a clear goal in mind. Subversion has made integrating work easy. Committing work to the servers is an elementary operation that keeps track of changes. Another added benefit (for programmers) is that many of the most popular development environments have Subversion plug-ins simply to entice them!

The dominance of Subversion is due to its clever development over CVS. With CVS if there an error occurred, One user checked out the entire project thus jeopardizing it. Subversion maintains the integrity of the server’s master copy of the project. Subversion’s support for non-text files is also vastly improved, so too has its ability to handle shortcuts. Originally CVS’s checked-in shortcuts still pointed to the location on the serverfrom which the project began, Subversion alters this to be a local shortcut.