We use Subversion in Macronimous, and I found it would be interesting to share its benefits and our experience with Subversion. It’s a bit lengthy entry, kind of Article, But I believe at the end you will find it useful.
Web applications are growing tremendously, with more developers involved in finishing the projects. This is when the need for a control system for better code management, that handles revisions effectively, came into existence.
And that is how the version control system called Subversion came into being. The details of the project being worked upon are stored in a repository, which is usually on a remote server. Every time a change is done to the project, the changes are highlighted in the repository as well. The changes can then be imported into your local machine. Any change done to the local working copy reflects upon the repository as well.
Not only that, the changes that are done by other users to the repository, can be made to reflect in your local copy as well! This facilitates in keeping every developer involved in the project to know the changes done in the coding, by other developers, thereby allowing multiple developers to work on the same project effectively, in a hassle free manner.
What all are required to manage web applications in SVN?
The following are essential to handle web applications using Subversion:
- A public web server along with a live webspace
- A testing web server with one web space for each developer, minimum
- MySQL server accompanied by two databases
- An SVN server
What is possible using SVN for web development?
When we are working on a developmental project at Macronimous, with SVN, we found the advantage of maintaining a trunk and stable release versions. This is because, as changes are made on the local machine, these changes are equally reflected in the working copy on the server, with complete SVN update.
To automatically update a folder’s content, when the latest work was done is saved in the repository, and get the latest work through your server, the following needs to be done:
The post-commit.tmpl repository of the hooks folder in the svn repository folder structure is of importance here. For *nix systems, it is required to rename the post-commit.temp into post-commit, so that permissions can be given to execute the specific task. For windows systems, it is required to rename to post-commit.bat. In Windows servers, permissions do not pose to be a problem.
When your files are named this way, Subversion understands to use your hooks. Because of this, there is no need of configuring anything to enable these features. This results in creating the script that is required to execute whenever the event starts off. No environment settings are required (like %PATH%) to run these scripts. Therefore, this requires a reset of the variables involved in the script or the usage of absolute paths.
If any changes are done to the production server of a site that is already being used by visitors, we have to be really careful enough, so that errors do not creep in for the website users. We must ensure that the server has got updated the way our working copies have, and this is done using a staging area, placed on the same server, but with the access provided only to the admin.
When the updates have to be uploaded to the server, an export is performed to the staging area, followed by a click through the site and checking through the checklist in order to check if everything is perfect. Once we have got it confirmed that everything is perfectly fine, the updates are copied to the production area. This makes the updates live, without any problem to the already online users.
Some advantages of using Subversion, with respect to web development include:
- No more need to take backups locally. The repository is available on a remote server. So every time a change is made to the repository, the changes reflect in the remote backup as well.
- Multiple users can work together on the same code base, simultaneously.
- Allows keeping a continuous record of all changes performed to a project over time. Subversion also has the facility of checking out what all changes have been performed previously in the project, as well.
Few handy features like atomic transactions and Apache piggybacking are also available.
- One of the earlier web development techniques of using an FTP client while updating files into your production server has been replaced by SVN, wherein the production server can execute the repository just like how it does in the local copy.
- When a large number of changes has to be uploaded in the project, including new codes, images, videos, fixing few bugs and the likes, Subversion uses only one command is run – the svn update; it effects down all the latest changes together.
- SVN clearly pinpoints on the files that have undergone changes and those that are new. Moreover, if the same server hosts the repository as well then the update comes into effect in a jiffy! If the repository is available on a different server, the speed of transfer is still fast, taking a few seconds.
Subversion is definitely a very powerful and useful web VCS, with the core importance given to the fact that changes can be done to the local working copy would cause mirror image changes to be brought into effect in the repository as well. Also, it encourages many users to work in a collaborative manner on the same project, by effecting the changes done in the repository, on the local copies as well!