Metronome

Using SVN for Web Development

Maarten Manders
Maarten Manders
Published in
·Updated:

Share this article

SitePoint Premium
Stay Relevant and Grow Your Career in Tech
  • Premium Results
  • Publish articles on SitePoint
  • Daily curated jobs
  • Learning Paths
  • Discounts to dev tools

7 Day Free Trial. Cancel Anytime.

Key Takeaways

  • SVN (Subversion) is a beneficial tool for web development, offering features like atomic transactions and Apache piggybacking, and can be used to manage code revisions efficiently as web applications grow and more developers join a project.
  • A system architecture for using SVN in web development involves a public webserver with live webspace, a testing webserver for each developer, an SVN server, and two MySQL databases, one for development and one for live use.
  • While code, database schemata, templates, and graphics should be included in version control, user data, database data, cached data, and configuration files should be excluded to avoid overwriting and security issues.
  • Branches should be created for large projects, long-term projects, and projects involving multiple developers to prevent damaging the trunk, and tags should be used to track releases; this approach also improves security as developers do not need access to the live server.

As our web applications grew and more and more developers started working on them, it became obvious that we needed some kind revision control system to manage our code. As CVS is quite dated and Subversion (SVN) introduced some handy features (atomic transactions, Apache piggybacking, more convenient branching/tagging, tons of other improvements), we chose to go with SVN. The big question was: how to use it correctly? After coming up with some more or less weird ideas I think we finally found a decent solution to put a web application into source control. Keep in mind that this post is not about how to use SVN itself, it’s rather about the system architecture for using it in web development. If you need help with Subversion, you can find it in the manual and the FAQ.

Managing web applications in SVN is tricky for some reasons:

  • When using revision control, a programmer is always working on a ‘working copy’ of the project. In traditional software engineering, this copy is somewhere on the his machine, as it’s a stand-alone application. In web development, however, we’re talking about webspace. Should every developer have a PHP environment on his machine then? Shouldn’t all programmers work on the exact same server configuration? What about Windows and Mac users?
  • This means the working copies should be best on one webserver, along with an SVN client. Thus, we need some interface (the most simple one being SSH) to access it. Maybe a rich web client would be even better.
  • Most web applications use a database. Different versions of software need different versions of database designs. Even worse, their operabililty may depend on data in the database. An application version without a matching database structure is no good.
  • The application needs to be deployed to a live webspace. This might happen quite often and should be as painless as possible.

So this is what we’re going to need to make it work:

  • A public webserver with the live webspace
  • A testing webserver with at least one webspace (working copy) for each developer
  • A MySQL server with two databases
  • A SVN server
  • Some discipline

Webservers

Each developer is now able to work on the project in his own working directory (webspace). They all share one development database though, as the code shouldn’t be dependant on data in the database. Whenever a programmer has finished his task, he commits his changes to the repository.

When the next version of your application is ready, it can be rolled out to the live server, which is a working copy as well. That way, updates can be released very quickly and efficiently without having to export the whole repository. All we need is a little script or webmin to trigger the rollout. For security reasons, there is no other way to access files on the live webspace. All that needs to be done yet is to prevent Apache from descending into .svn folders. A little directive in our httpd.conf can help us here.

# Disallow browsing of Subversion working copy administrative dirs.
<directorymatch "^/.*/.svn/">
    Order deny,allow
    Deny from all
</directorymatch>

Databases

For each version, there is a matching database structure. How are we going to handle this? First of all it seems smart to keep things backwards compatible, as it’s important that you can roll back to a previous version without breaking your application. Which means: don’t delete anything anywhere, just extend existing structures.

On each software release, all changes to the database structure need to be made on the live database server. On first thought this should be done automagically. The problem is: how? We don’t just want to “replicate” all the development server’s differences to the live server because there are certainly test tables or other half-baked things around there. Which makes it necessary to carefully select and that’s painful.

That’s why you should keep a changelog, where you can append all changes to the database which are meant for live use. It takes some discipline but has the advantage that you always have a ready SQL file to build your database from. If properly commented, you can use it as a changelog, too.

What if, for some odd reason, your code is dependant on data in the database? Say, the there’s some sort of sitemap stored in the database. This is painful because you have to update that table manually. Before each commit, when there’s been changes, you’ll have to dump it to an SQL file to put it under revision control. This way your data becomes mergeable, too. When there’s a lot of places to do so, you should consider scripts for freezing (writing database data into files) and unfreezing (vice versa) your web application.

What to put in…

Of course, your code belongs into version control. So do database schemata, templates and graphics. What you shouldn’t put in, is:

  • User data – user uploaded files and stuff don’t belong there.
  • Database data – don’t confuse revision control with a backup!
  • Cached data – it’s temporary data.
  • Configuration files – they’re to be created manually.

Don’t even think about putting configuration files into revision control. First of all, they tend to get overwritten and, for example, change your live server’s database. Second, passwords don’t belong into revision control! Instead, you should add default config files with changed filenames, like database.conf.default.

Branching and tagging

It’s important to remember that only working code belongs in the trunk. After all, it needs to be ready for deployment all the time. Because of this you need to create a new branch, whenever:

  • You’re working on a big project that requires its own versioning.
  • It’s a project that takes a rather long time to complete. Your code is safer in the repository than on a developer’s laptop.
  • When more than one person is working on a project. In their own branch, developers can share their code without damaging the trunk.

These branches are merged back into the trunk after completion. About tagging, the only thing I can say is that it’s smart to create a tag whenever you’re updating your live webserver to keep track of your releases.

Security

A nice side-effect of this whole approach is that no developer needs access to the live server anymore. When done right, live server updates are triggered over a webmin interface and that’s about all administrative access you need on that machine. Which is good. And don’t forget to use SSL for your SVN transactions to be safe!

Frequently Asked Questions about Using SVN for Web Development

What is SVN and why is it important for web development?

SVN, also known as Subversion, is a version control system that allows multiple people to collaborate on a project without overwriting each other’s changes. It is crucial for web development because it helps in tracking changes to source code, enabling developers to revert back to a previous version if necessary. It also aids in resolving conflicts when several people are working on the same project.

How do I install SVN for web development?

Installing SVN depends on your operating system. For Windows, you can download the installer from the Apache Subversion website. For Linux, you can use the apt-get or yum command to install SVN. Once installed, you can verify the installation by typing ‘svn’ in your command prompt or terminal.

How do I create a new SVN repository?

To create a new SVN repository, use the ‘svnadmin create’ command followed by the path where you want the repository to be created. This will create a new directory at the specified path with the necessary SVN structure.

How do I check out a project from an SVN repository?

To check out a project from an SVN repository, use the ‘svn checkout’ command followed by the URL of the repository. This will create a local copy of the project on your machine.

How do I commit changes to an SVN repository?

To commit changes to an SVN repository, first make sure you are in the root directory of your project. Then use the ‘svn commit’ command followed by a message describing the changes you made. This will upload your changes to the repository.

How do I update my local copy of a project from an SVN repository?

To update your local copy of a project from an SVN repository, use the ‘svn update’ command. This will download any changes from the repository that you do not have in your local copy.

How do I resolve conflicts in SVN?

Conflicts in SVN occur when two or more people make changes to the same part of a file. When this happens, SVN will mark the file as conflicted. To resolve the conflict, you can manually edit the file to decide which changes to keep, then use the ‘svn resolved’ command to tell SVN that the conflict has been resolved.

How do I revert changes in SVN?

To revert changes in SVN, use the ‘svn revert’ command followed by the name of the file or directory you want to revert. This will undo any local changes you made to the file or directory.

How do I view the history of changes in SVN?

To view the history of changes in SVN, use the ‘svn log’ command. This will display a list of all the commits made to the repository, along with the commit messages and the names of the people who made the commits.

How do I delete a file or directory from an SVN repository?

To delete a file or directory from an SVN repository, use the ‘svn delete’ command followed by the name of the file or directory you want to delete. Then commit the change to the repository.

Share this article

Subscribe to our newsletter

Get the freshest news and resources for developers, designers and digital creators in your inbox each week

© 2000 – 2025 SitePoint Pty. Ltd.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.