Ever since i found subversion i have kept all the websites i've maintained or developed under a VCS. Some time back i discovered bazaar, which is a distributed VCS. With bazaar i learned the true power of VCS for maintaining a website.

The first thing people who don't use a distributed VCS notice is the excessive use of branches. It still gets to me sometimes, but it's a good thing in the end.

Ok, here is an example based on real life. A while back i set up a drupal based website. I started the development with an RC version and later migrated to a final version. I still have the repositories hanging around if i ever have to upgrade the site.

First we create the base repositories. I will use a shared repository to save some space, but there is no requirement to use one.

/work/ > mkdir -p website/upstream
/work/ > mkdir -p website/tarballs
/work/ > bzr init-repo --trees website 

Next we import the first drupal version (i've already copied the tarballs to the tarballs directory)

/work/ > cd website/upstream/    
/work/website/upstream/ > tar -xzf ../tarballs/drupal-4.7.0-beta4.tar.gz 
/work/website/upstream/ > cd drupal-4.7.0-beta4 
/work/website/upstream/drupal-4.7.0-beta4/ > bzr init
/work/website/upstream/drupal-4.7.0-beta4/ > bzr add 
added .htaccess
added CHANGELOG.txt
added themes/engines/phptemplate/node.tpl.php
added themes/engines/phptemplate/phptemplate.engine
/work/website/upstream/drupal-4.7.0-beta4/ > bzr --quiet commit -m "import drupal 4.7.0-beta4"
Committed revision 1.                                                          

Now it's time to start working with the website itself. First we get a copy of the website engine to start working on it. Lets create a dummy theme with a message in it.

/work/website/ > bzr get upstream/drupal-4.7.0-beta4 main
Branched 1 revision(s).
/work/website/ > cd main/themes/chameleon 
/work/website/main/themes/chameleon/ > cp -a marvin dummy
/work/website/main/themes/chameleon/ > cd dummy
/work/website/main/themes/chameleon/dummy/ > cat >> style.css << EOF 
> a:before {
>   content: "This is a message";
> }
/work/website/main/themes/chameleon/dummy/ > bzr --quiet add .
/work/website/main/themes/chameleon/dummy/ > bzr --quiet commit -m "commit my custom theme"

Next, we publish the website and create content. After some time we are ready for a full release and notice that drupal 4.7.5 has been released. Note that the import command is provided by bzrtools.

/work/website/upstream/ > cd drupal-4.7.5 
/work/website/upstream/drupal-4.7.5/ > bzr import ../../tarballs/drupal-4.7.5.tar.gz
/work/website/upstream/drupal-4.7.5/ > bzr --quiet commit -m "new upstream"
/work/website/upstream/drupal-4.7.5/ > cd ../../main   
/work/website/main/ > bzr merge ../upstream/drupal-4.7.5 
All changes applied successfully.

Now lets verify that the modification is still there:

/work/website/main/themes/chameleon/dummy/ > tail -3 style.css 
a:before {
  content: "This is a message";

That's all there is, bazaar will tell you if you modified some parts that were modified upstream and offer you some help in merging the changes. If the software was designed properly there usually aren't any conflicts.

At this point one could argue that you can do this manually too. It might even be easier for small projects to do it all manually, but on bigger projects it's increasingly difficult to track all local changes and changes made upstream without help. Getting it done by the tools provided to you makes it all worth it. And if you wish to add modules to the mix, just create new upstream branches for them too. Just create a branch based on a upstream release and add the module there, then merge that branch to your main branch. When you want to upgrade, replace the module in the upstream module branch and merge to your main branch again.

The last thing to note is that this all requires planning. Without planning or luck you will have to do a bit of work to get this all set up. It can be done, but it's not as easy as it is if you start off with proper structure.

Comments on this page are closed.