SoC 2007

I've spent the past week coding the DAST patch tester - I really want to get this released with patch testing becoming a huge priority right now and new features like Chad's delete API only having a week left to be evaluated before the D6 code-freeze. I want to get this out today - I'll post another update later.

I had my last exam yesterday, which is why you didn't hear from me since the last write-up from nearly a week ago. One more assignment is likely to keep me busy until Monday, but when that's done I can fully focus on my SoC project. That is, apart from the week-long interruption by the KDE conference where I head to on next week's Friday.

Oh boy, I wish I could borrow just a fraction of the time that I have in July and August, and use it before the mid-term deadline x-)

This week I started coding on a Phing build file to implement the patch testing process I outlined in http://groups.drupal.org/node/4477 Right now I'm still punching out the code to get this working and I will commit it and release for testing by tomorrow. (June 20th)

So, Mercurial, or "hg" in short. One of the two revision control systems originally written for being the Linux kernel's BitKeeper replacement - in the end, git was chosen for that job, but Mercurial lived on nevertheless. The requirement of being suitable for kernel development implied two features: performance (although git is still a tiny bit faster) and distributed development methodologies. Both are also present in git, and in fact, the two systems are very similar in scope, paradigms and usage patterns.

While git is written in pure C, Mercurial mostly consists of Python code, with only small, critical code paths implemented in C. This has benefits for Mercurial's portability, as can even be observed with other SoC students. git is pretty much focused on just Linux, whereas Mercurial can also be installed more easily on Windows and other Unixes. Not that straightforward graphical tools are yet as mature as the ones that exist for CVS or SVN.

CVS, or Concurrent Versions System, was the de-facto standard open source version control system for a long time. It came up in the late 80s and grew popular enough to manage the source repositories of virtually all open source projects until only a few years ago (when Subversion started to take over). It's still widely used, including on drupal.org, but hardly deployed on newly created repositories anymore. Development is strictly fixed to a centralized client-server methology, and while distributed version control systems (or Subversion with svk) strive to make a checkout independent from the server, with CVS you're completely dependent on a fast and reliable connection to upstream.

In summary, there's little surprises in this CVS coverage, especially for the resident drupal.org admins. But necessary nevertheless, if only for later reference. Obviously, no new requirements for the API module were found, as the CVS setup on drupal.org together with the Project module is the status quo at the moment.

My project definition says that I still got to document the specifics of SVN and CVS (git has been taken care of). Coming from the KDE camp, I'm already acquainted to Subversion to a certain degree, as the whole huge KDE repository switched from CVS in May 2005. (No one, including the SVN admin, did regret the switch).

Subversion (SVN) came up as a replacement for CVS - motto: "CVS done right" - and incorporates its centralized development methology and its straight-forward workflow, while improving on its weak parts. Compared to CVS, Subversion features good stuff like atomic commits, renaming, serverless diffs, symlink support and version-controlled directories, to name the most popular ones. It fulfills its role as a drop-in replacement brilliantly and has kinda deprecated CVS, at least for newly installed repositories. (That, of course, doesn't stop Linus Torvalds from claiming that centralized development methologies are outright wrong.)

So I volunteered to help test the MSSQL database driver for 5.x and 6.x-dev. Right now Souvent22 is trying to stabilize the install script. So the routine for everybody is:

while (mssql install path != stable) {
1. Checkout DRUPAL-5-1 HEAD
2. Apply mssql patch
3. Delete all the stuff in the test vdir and put in the fresh HEAD
4. drop everything in the SQL Server test database
5. Go to Drupal install page
}

Now after a few iterations this is going to become tedious. So this is what will eventually replace it:

There was a quote of someone saying that inexperienced programmers worry about code, while advanced programmers worry about data structures. Don't remember who said that, but personally I find this an excellent analysis.

Let's try to formulate the important questions that need to be answered in order to get the Revision Control API right:

1. What kinds of functionality do users need from the API?
2. What kinds of functionality do different revision control systems provide?
3. How does the data that is delivered to the caller look like?
4. Which functions are required to deliver the data to the caller?

Like I said on the the DAST wiki page http://groups.drupal.org/node/3913 DAST is an implementation of a automated build process for Drupal sites. "Build process" is not a term you hear normally associates with websites, but any dynamic web page needs software which renders the final markup and script which gets delivered in the user's browser. A site running on Drupal is a complex piece of software. Building a Drupal site is complex enough to require a tool to automate the process, especially if you're a developer or tester. One important advantages of having a tool to automate the build process, in addition to lessening the toil of overworked Drupalites, is that it is a repeatable process - you can't forget to do something when building a site which leaves you cursing 1.5 hours later when you finally figure out what you forgot to do. DAST will build a Drupal site exactly the same way every time.

The process of creating a Drupal site can be viewed as a pipeline where code assets and configuration move through different stages until the final build output is successfully produced. The software which provides the framework for constructing this pipeline is Phing (PHng Is Not Gnu make) http://www.phing.info

There's a great introduction on git for SVN people like me, which made it twice as easy for me to look into how this thing works. Git only recently released their 1.5 version which is the first one that's supposed to be usable to the masses. (It might not yet be available pre-packaged for your Linux distribution, or available at all if you're running Windows, which could be a small hurdle at the beginning.) After reading the introductory couse and trying it out by myself, I must say I'm hooked.

For those who didn't know, git is the distributed RCS that was created by Linus and the other kernel folks because they needed to get rid of BitKeeper, and as the Linux kernel is a very demanding project both in code size and in patch management, git is quite capable indeed from an efficiency point of view. Currently in use by the Linux kernel itself, X.org, Wine, and One Laptop Per Child, to name a few popular projects.

As promised in my SoC application, here's a short rundown of features that are important to this abstraction layer.