Author's Opinion

The views in this column are those of the author and do not necessarily reflect the views of iTWire.

Have your say and comment below.

Monday, 03 December 2007 15:39

Compiling and contributing to the Linux/open source subversion

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.

This is useful for documentation and quality assurance but also extremely helpful in the worse-case scenario where new code breaks functionality and has to be scrapped – it becomes a no-brainer to completely undo changes and revert back to a known, good state.

If you would like to contribute to an open source project, you will need to become conversant with the source control system in place – you won’t be able to submit any modified code without using it. This is an excellent discipline and practice for successful software projects, and without it much open source software would have a hard time keeping itself organised especially with developers working all around the world.

But, even if you are not interested in actual programming, there is still a lot of value in understanding source code control because it’s THE guaranteed way to always get the bleeding edge version of any app you are keenly following.

Software releases generally occur at specific milestones, where a reasonable amount of extra functionality has been added or bug fixes have taken place. Only in exceptional circumstances, like an emergency security patch, does a new release come out hot on the heels of another.
For many users, this is fine enough; you get to maintain a stable system with just periodic updates. However, you might be mad keen on a crucial app. You might be desperately waiting for an anticipated new feature. You might have a mix of software which doesn’t work together and you anxiously want the patch.

For power users, or at least the mad obsessive, mastering the VCS is also for you. You can pull down the absolute latest version of all the source code files for a project on demand, compiling it on your system, and putting it in place.

There are two major source control systems in the FOSS sphere. The first, CVS, is well-known and established but the second, Subversion, is gaining in popularity and is used by such well-established projects as WordPress. Popular source code repository, SourceForge, provides supports for both.

I’ll focus on Subversion here because, as good as CVS is, Subversion is better. Subversion is based on CVS and improves upon it; they’re not two radically different systems but instead one which works largely the same as the other but does more.

One example is folders; CVS will version files but not directories. By contrast, Subversion will version directories, copies and renames.

Subversion – or SVN as it is regularly known – has two parts – a server and a client. The server is web-based and is hosted on a central machine with a dedicated database known as its repository. The client component is used by all the people wanting to work with repositories, whatever their purpose may be.

I won’t talk about the server because while essential it’s not something people will be setting up too often. If you make a new project on SourceForge, the SVN server is already provided for you. However, if you do make your own FOSS project on your own system then this Lifehacker article may help.

You can download the latest SVN client, which at the time of writing is v1.4.5, from It is available in source code format, requiring compiling, or pre-compiled binaries for a variety of Linux distros as well as Microsoft Windows.

SVN is a command-line system (although GUI front-ends can be found) and has pretty much just one command, namely svn. The very first svn parameter you should master is checkout. This will download the entire source tree from the specified repository.
In the case of WordPress, their Subversion repository is hosted at so the appropriate command is

svn checkout

This invokes the svn command, instructing it to check out the whole repository at the URL given.
This only needs to be run once; once you have the repository the command to use hereon in is
svn update

This command is deceptively simple. It goes through your local copy of the repository as well as the master copy back on the server. It uploads any modifications you have made back to the server, and it downloads any modifications others have made to your copy. Where possible, if two or more people – including yourself – have modified the same file then changes will be merged so long as they don’t interfere with each other.

If you only want to build the latest version of an app, then these are the two commands you need; run svn update regularly and you’ll always be up-to-date.

If you’re contributing to a project, be sure to run svn update before you begin coding just to make sure your repository is current. This will help minimise any version conflicts which can occur if two people do edit the same section (and which require a bit of manual work to rectify.)

When you’ve finished working, don’t perform an update straight away; run svn status to confirm what you have actually done. This causes SVN to run through the project and advise you every file you have modified – and which it would upload if you updated – as well as any files that may be in a conflicting state.

You might find that you have inadvertently modified a file that you didn’t mean to, or no longer wish to. You may see that someone else has implemented a change you were working on and no longer need to.

The svn status command will show the names of files; to see more information – the actual lines of code themselves – run svn diff. This produces output showing how your files vary from the original versions you began with.

If you determine you wish to undo a change, you use the svn revert command followed by the name of file you want to send back to its original state – e.g. svn revert main.c.

Now you can update!

That’s the fundamentals of Subversion. If you’ve made it this far, you’re a Subversion champion. You have all the tools and commands and concepts under your belt to retrieve all the SVN repositories you crave.

There’s a lot more to version control however; there are many advanced things you can do like even branching one project into two different directions – and then bringing them back together again. As indicated earlier, you can review the version history for files. There’s a lot of power at your fingertips through the tiny three-letter svn command.

There’s a great book available online, for free, which goes through SVN in great detail and is well recommended.

Subscribe to ITWIRE UPDATE Newsletter here


The much awaited iTWire Shop is now open to our readers.

Visit the iTWire Shop, a leading destination for stylish accessories, gear & gadgets, lifestyle products and everyday portable office essentials, drones, zoom lenses for smartphones, software and online training.

PLUS Big Brands include: Apple, Lenovo, LG, Samsung, Sennheiser and many more.

Products available for any country.

We hope you enjoy and find value in the much anticipated iTWire Shop.



iTWire TV offers a unique value to the Tech Sector by providing a range of video interviews, news, views and reviews, and also provides the opportunity for vendors to promote your company and your marketing messages.

We work with you to develop the message and conduct the interview or product review in a safe and collaborative way. Unlike other Tech YouTube channels, we create a story around your message and post that on the homepage of ITWire, linking to your message.

In addition, your interview post message can be displayed in up to 7 different post displays on our the site to drive traffic and readers to your video content and downloads. This can be a significant Lead Generation opportunity for your business.

We also provide 3 videos in one recording/sitting if you require so that you have a series of videos to promote to your customers. Your sales team can add your emails to sales collateral and to the footer of their sales and marketing emails.

See the latest in Tech News, Views, Interviews, Reviews, Product Promos and Events. Plus funny videos from our readers and customers.


David M Williams

David has been computing since 1984 where he instantly gravitated to the family Commodore 64. He completed a Bachelor of Computer Science degree from 1990 to 1992, commencing full-time employment as a systems analyst at the end of that year. David subsequently worked as a UNIX Systems Manager, Asia-Pacific technical specialist for an international software company, Business Analyst, IT Manager, and other roles. David has been the Chief Information Officer for national public companies since 2007, delivering IT knowledge and business acumen, seeking to transform the industries within which he works. David is also involved in the user group community, the Australian Computer Society technical advisory boards, and education.

Share News tips for the iTWire Journalists? Your tip will be anonymous




Guest Opinion

Guest Interviews

Guest Reviews

Guest Research

Guest Research & Case Studies

Channel News