So other than Plasma panel auto-hiding (it's a bit of a mouthful, maybe the guys in kde-promo can come up with a good buzzword ;), Amarok 2.0 beta 1, and fanciness with QEdje; the new (not really new, but new for me) hotness of the week is Subversion Externals.

For those who don't want to read the link the idea is pretty simple. In your subversion repository, a directory can be defined to be another subversion repository. When you update your working copy, it will find the external repository definition, and also update that. It can also be nested, so that if an external repository is defined in an external repository it's code will also be gotten.

This is very cool for open source software (at least for projects which use subversion). I can get automatically updated code from the subversion repositories of other projects, very cool! Not only that, but it doesn't just happen for me, it happens for other developers as well. In the open source world, this can make source control a lot easier (with a little bit of co-ordination at least).

However, this is even cooler for PHP based projects. This all comes from the install model of PHP. To install my program I just copy it into a directory, and I'm done. With subversion externals and a little post-commit hook script magic, I can have an automated system for deployment of entire sites. I can have many disparate components, and have them be assembled in an automated fashion.

This is very nice (and easy) to do with Drupal, because many pains are taken to keep local modifications separate from Drupal's core. So I can have Drupal in one repository, and all of my local modifications in another. And with a little thought I can do automated deployment for test and production sites. If Drupal were ever to switch to subversion (as opposed to CVS) I could define external locations for modules and for Drupal itself, so I wouldn't even have to copy Drupal into my own repository, I could easily deploy and update to new versions of Drupal. Better yet, because of the possibility of conflicts, all files in a Drupal installation need to be deleted to ensure clean upgrades; but if subversion was used, it would be able to remove, add and modify files as necessary making the upgrading process faster, cleaner and less risky.

In the future, having this kind of deployment model for KDE websites would be very beneficial. Potentially, every KDE website could pull from a master repository (of something like Drupal) and all be updated mostly automatically. The need to go through and delete all the files in every installation and then copy all the new files installation would be removed (again, thanks to post-commit hooks). Only database update scripts and other maintenance tasks would have to be run (which could also potentially be automated). It would also bring along the benefits which version control systems already have; I'll have a backup copy (more or less), if things mess up the changes can be reverted (again, simply by pulling updates from the master repository), and I won't have to send the whole of every file across the network.

The catch? There are a couple. External repositories are considered disjoint, so I can't edit or make changes to files in an external repository, this must be done directly. Along the sames lines, I can not directly checkout an external repository. If I have an external repository at http://svn.testsite.com/repo1/external and I try to check it out, it will say that it doesn't exist. Also, a slightly higher level of interactivity would be nice, so that certain files (such as default setting files) could be easily ignored.

Nonetheless, this concept is powerful and in the future may be beneficial for deploying code updates to KDE sites, and for making it easier to work on KDE sites by pulling in disparate parts to one location.