Compiling and contributing to the Linux/open source subversion

David M Williams
Monday, 03 December 2007 15:39

Opinion and Analysis

Many of the best-organised software projects around the world are the legions of free and open source offerings. This is in part due to one reason, namely the tight use of source code control and versioning systems to keep the code base clean and in a known state. If you’ve wanted access to the latest build of your favourite apps or if you want to contribute your own mods, the key is to master the source control suite. I’ll introduce Subversion and show you it’s actually pretty simple. There’s a good reason for using such a package, especially when many developers are working on a project. The bulk of all computer software is made of many individual and modular files which attempt to self-contain the source code for specific functionality. It may be that some files are dedicated to database handling, others to the user interface, others to enforcing rules and logic and so on.

Version control software – and let’s call it VCS from here on – enforces that code be “checked out” and back in again. Traditionally, only one person can check out a module at a time. This means that one extremely common risk is mitigated immediately, namely the problem where two programmers independently change the same source code file, and whoever saves first loses their mods completely when the second person saves. Using this type of VCS the second person cannot check out the file if somebody has already checked it out.

You can think of checking a file out as being similar to checking a book out of a library. Obviously, nobody else can borrow that book if it has been taken out. It must be returned. However, there is one fundamental difference. Checking a file out of a VCS does not remove it. Any number of people can still request a copy of the file, as it was when last checked in. This is good because it permits other programmers or interested parties to get a copy of the source code at any time.

These parties will not be able to put any modifications back into the VCS, though. Only the person with the checked out file can submit their modifications, and they do this when they check the file back in. At that time, the VCS updates its version count for the file, includes the new code, and makes the file available to be checked out again, whether by the same programmer as before or someone else, and whether it happens straight away or months or years later.

Other VCS systems have a different way of thinking; in a complex project it’s unjustifiable to lock a whole file even if someone is working on just one function in it. So, these VCS systems allow the code to be checked out by anyone and then merge all updates that come back in to maintain a seamless single code base despite when and where changes occur. In this case, think of the safety tag system in use at industrial sites; you don’t dare turn a piece of equipment on if somebody has a safety tag on it. However, there’s nothing stopping many people putting their own safety tag on the equipment because they need to work on it too. They all work on different parts, and remove their own tag when they finish. At the completion of the work, many people have performed actions (or made changes) and these have effectively been “merged” into a single whole.

Best of all, the version control system maintains a record of what has been altered when a file is checked back in. The developer is encouraged to write a helpful annotation describing, at a high-level, the purpose for their modifications but even without this the system can reconstruct any previous version and show exactly what differs between it and any other version, be it the latest or not.