version control api

Er, right, this update post has taken longer than it should have. I've been active on the code though, and this time I even have a screenshot for you. Without further ado, I present Commit Log:

Well, I promised you an update on the API module, so that's what you'll get. Just a short notice beforehand: the CVS backend's database structure is now online and available for everyone's reviewing pleasure. Module functions will be added in a week or two, but before that, I'll get the xcvs-* scripts to fill in the entries for the new database structure. I've also made a (slightly different, but largely similar) SVN version of the .install file, you can find that one attached to this post. (As a Subversion backend module is only an optional deliverable, I'd rather not start a versioncontrol_svn project and its directory in CVS just yet.) So it seems to me that deliverable number three, a finished database schema for the CVS backend, can be marked as done.

Get to the point, dude!

Ok, ok. My remaining problem with the Version Control API was that it lacked a way to consistently deal with tags and branches, and to uniquely identify files and directories even if they are not versioned themselves (which is the case for directories in CVS and other version control systems). So I thought a bit more about how to deal with this, and the outcome is a new building block object for items, in addition to the previously existing ones for repositories and commits.

Actually, I wanted to write a piece on how the Version Control API is maturing, but I've got to leave here in a few minutes and won't have internet available until tomorrow, so this must wait for now. Instead, a short coverage of the Version Control / Project Node Integration module (versioncontrol_project.module).

[disclaimer] I'm writing this update while drupal.org (including g.d.o) is attacked by database-eating gremlins, so I can't currently check back on previous entries. Apologies in advance if I mention something that has already been said before. Yes, I could use the Google cache, but that's kinda tedious. [end of disclaimer]

So, I've been pretty absent for quite some time. After getting my university stuff finished, I found a bit less time for my Summer of Code project than I had expected, moving out from the dorms, packing bags, wrapping up undone stuff, whatever. Last week (June 29th to July 7th) I've been attending aKademy, the KDE conference, as previously announced. Great event, great people, great location (this year it took place in Glasgow, Scotland). You can read lots of coverage on KDE Dot News - start here (you can find me in the group photo) and go left in the navigation at the buttom, the marketing team has been active as never before. I wonder in which ways DrupalCon will be different from aKademy, as in my view the projects and their attitudes already differ fundamentally. Ok, so that's that.

Not having found the time before, I reallocated a few hours from aKademy's hacking sessions to my Summer of Code project. Since the last real update, the RCS API module has changed its name to Version Control API (versioncontrol.module), and the former project_rcs.module is now Version Control / Project Node Integration (versioncontrol_project.module). Both now contain a good amount of API functions for accessing commit data. Even if the implementation is still missing out (which, according to the project proposal, has been planned this way), they are the core of what other modules will use from the API module. (Read more...)

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-)

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.)

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?

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.