When you start to learn how to code, it doesn’t matter which language, you can see how everywhere they put special attention on things like document and put commentaries on the code, create a planning for the project you want to do, follow some kind of notation, create backups regularly and so on.
But usually there’s something missing: maintenance of code version.
Many people still think that use a version control system is just required when you work in a group but they’re absolutely wrong as you can get really nice advantages even if you use just for yourself.
Some examples of the situations where we’ll see clear the advantages can be:
- I’ve been using two computers for developing some applications. Even if I tried to keep the consistencies between both versions I always ended up with many different versions spread in many folders. So first advantage of control version is obvious, you will get one central copy of whole code and it will be all the time in the same place.. All the others local copies will be synchronized with this remote copy.
- You touch something and the program start to fail:
_ok... no problem, I'll delete the lines that I've changed_ (Compile and execute again... crash!) _ouch!... maybe I forgot something, let's take a look again_ (...after a while...) _ok.. I've found it... let's execute again_ (Crash!) _life sucks :(_
This is very common situation that will be remove with control version. You just revert the current copy in your harddrive to the previous version stored in the remote server and you’re done. Or if you prefer you can compare both files (the one you’ve change and the original one) so you can check where you did something wrong.
When you develop an application and you think the current version is stable enough, usually you just create new folder and copy everything there, calling it folder Project v2 stable. Then you go changing something and maybe you find a bug that you should apply to all the stored versions… not very funny eh?. With a control version you can create
tagfor each stable release version and then play with them as you want. You can for example merge two releases into one and using some files from a third release. You can compare the differences from one version to another to check why the new version doesn’t work on some clients while the previous one does.
Sometimes you want to try something new in your project but you’re not sure if it will works or not, so you start to make a big change in the whole system, and after all it doesn’t work, or what is more hard… something works but something not. With cvs you can create an alternative development branches. In this branches you can create new code as much as you want and if you realized that it doesn’t go anywhere, just cut it. But if it’s working you can merge it with the main development branch (aka
Backup! Enough descriptive by itself, but not just normal backup such as copy the current folder to somewhere, but also copy all the changes in all the revisions of the code.
I think just with these few examples you would like to start using a version control system. My advise is to use subversion (aka svn) there’re huge explanation on the web about why to use it instead of CVS or whatever, so I’ll not go into this.
The first thing we need to start using svn is to install a svn server. There’re different ways to install it, one very simple is to download the subversion binaries and execute them and keep them running while using the repository. Its works good for local access and it’s very easy and fast to get it working.
But as there’re many tutorials on internet about this method, I’ll explain another one more recommended for usability and security, but maybe harder to setup without help.
First of all I assume you’re already installed an
Apache2 server running up. So we just install the required packages for subversion:
$ apt-get install subversion $ apt-get install libapache2-svn
Next step is to tell Apache to use
WebDAV for authentication using the mod_auth module:
$ a2enmod dav $ a2enmod dav_svn
Now we define one configuration file to include in the available sites of apache (In our case
<Location /svn > DAV svn SVNParentPath /srv/svn/repositories AuthType Basic AuthName "Welcome to XYZ repository" AuthUserFile /etc/apache2/dav_svn.passwd Require valid-user </Location>
With this file we’re saying to the server that we want to use a password file for the users (
/etc/apache2/dav_svn.passwd), we need a valid user to access to the repository, and the repositories will be stored in
Once that we’ve configured Apache2 to use svn we can start creating repositories in our server with the following command:
svnadmin create /srv/svn/repositories/NAME_REPOS
I strongly recommend creating the standard structure of main trunk, branches and tags folders right after the creation of the repository:
$ svn mkdir file:///srv/svn/repositories/NAME_REPOS/trunk \ file:///srv/svn/repositories/NAME_REPOS/branches \ file:///srv/svn/repositories/NAME_REPOS/tags \ -m "Inicial repository"
And finally we should ensure that the Apache user will has access to these folders:
$ chown -R www-data:www-data /srv/svn/repositories/NAME_REPOS $ chmod -R g+ws /srv/svn/repositories/NAME_REPOS
Now we just need a user to access this repository so we’ll add to the ```AuthUserFile`` that we’ve defined in the apache config file:
htpasswd -b /etc/apache2/dav_svn.passwd USER_NAME PASSWORD
And you’re done, restart your Apache server to be sure it has applied all the changes we’ve made and try using any subversion client (I strongly recommend tortoisesvn) if its works typing:
http://your_hostname/svn/NAME_REPOS and you’ll get a login screen asking for username and password, enter it and enjoy.
You can download the scripts that I use to create and remove repositories and user. In next article I’ll try to explain how to secure your connections using SSL.