Have you ever written a report or paper which took forever to complete? I'm sure you have. And like most of us, a good chunk of that time was spent rewriting unsaved work. And to think, most of that time could have been saved if we simply 'Saved often' and keep versions of our work. Well this simply theory has been embraced by multiple programs that enables data versioning. As a developer, a great program to use is Subversion.

What is Subversion?
Subversion is a free/open-source version control system. That is, Subversion manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.

Subversion can access its repository across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the trade-off for losing that conduit—if some incorrect change is made to the data, just undo that change. (Source: http://svnbook.red-bean.com)

Working with varied project requirements and changing technology, developers are always making changes and modifications. And sometimes old modifications can serve as a foundation for new modifications after they have been removed from a project. Talk about a 'head spinner'. But this has all been simplified by utilizing Subversion and some simple practices which I will share with you.

Commit Often!
Avoid: Making changes to multiple features or functions and committing them all at once.

Depending on how complex your project is, you want to try and break your changes up by feature or function. Once you have made your revisions to a particular function/feature to satisfaction, you want to commit it to the repository. Once completed, move on to the next function/feature.

The reason for this approach is to have granular flexibility in rolling back your changes without affecting multiple functions/features. There is nothing more frustrating than creating extra work for yourself after rolling back what you think is one change when in fact it is multiple changes across the entire project. You will not only find flexibility with rollbacks, but in other tools available in Subversion.

Meaningful Comments!
Avoid: Committing changes and not knowing exactly what the changes were.

The point in using Subversion is to make your life that much easier! In addition to the aforementioned practice you want to couple your 'commits' with a meaningful description so that both you and other developers can easily understand each others revisions.

Additionally, if you use a ticketing system to document bugs and modifications you may want to refer to the respective ticket ID where greater detail can be found. (A totally separate post!)

Simple practices can make all the difference in your work processes and maintaining your sanity. Although short, this post will be followed by additional posts made available about how you can effectively use Subversion.