State of the Version Control API

Yeah, those were the times. Weekly status updates during the Google Summer of Code... well, I'm too lazy to do that when I'm not forced to :-P
Let's see... the version control api term says that the last status update was in September '07. Way too long ago. So what's up going on in the Version Control API realm at the moment? Lots of good stuff. (Read on! It's just the <!--break-->.)

Backends on the rise

That's right: thanks to a task idea and management by chx and aclight, reviews by myself and dww, a highly open participation contest by Google, but most of all thanks to the awesome GHOP students ezyang and boombatower, we now have working backends for Mercurial and Git. Both of those backends cover all of the necessary functions for log retrieval, so if you want to view the commit messages of all those different repositories on your server, you know you can do it now.

Additionally, I have just gotten around to implementing a basic Subversion backend (unfortunately, the GHOP task for that one didn't succeed), which makes a total of 4 (four!) different VCS backends that are basically working. Considering that there are five popular version control systems out there, that doesn't leave much for a complete list! Of course, all of those new backends might still be a bit rough around the edges, but we're getting there.

drupal.org deployment deferred

hunmonk was already working on a script that ports data from cvs.module to the Version Control API + CVS backend + project node integration, but in the end there's too much to do for an instant switch of drupal.org. So the plan is to do a plain port of cvs.module to Drupal 6 and initially deploy that one. Version Control API should then replace cvs.module sometime in the Drupal 7 release cycle, when the database schema is stable and the remaining features are on par with cvs.module.

Stable release and further plans for the API module

I finally pushed out Version Control API 5.x-1.0 last week, with a minor bugfix release following yesterday. That release incorporates a lot of progress and testing - also made possible by the new backends - and is at least capable to show your commit logs in a pretty nice way. Probably more, but there are again large changes looming on the horizon... reviewing the new backends and input from ezyang made me think a lot about how the database tables could look like, and I finally have a plan on how to solve all remaining problems in one single stroke... well, something like that.

When I first drafted the rough architecture of the Version Control API and the data that is stored by the API module, I chose to leave file revision data to the backends so that it would theoretically be possible to retrieve logs without storing stuff in the database. That's a good premise, however two points now speak very much against it:

• All backends utilize their own item tables, and it's unlikely that backends appear make use of this possibility.
• Plus, calling the VCS binary each time when we need logs or even filter commits by path is going to be a major performance hit.

That's two good arguments against leaving out item tables, and the argument in favor is that centralizing this will make things easier for the API module - where easier also means that it will approximately improve performance to the level of cvs.module, and that's going to be important for deploying that stuff on drupal.org. The nice side effect is that centralizing stuff also takes work away from the backends, and that will essentially reduce the backends to little more than a simple interface between VCS and Version Control API, with hardly any commit/branch/tag management code left. If you're interested in the details, you can head straight for the Version Control API issue queue and look for "major issues".

So the plan is decent, it now just needs to be implemented timely. Along with that go small and not so small improvements in the API - amongst others, I want to kill off commit actions in favor of standard "items" with additional information, and if all goes well then we'll be able to query for commits, tags and branches with a single function call and get the information back in a unified format. (Displaying tags and branches next to commits in the log? You'll have it!) On the downside, I'm already creating the Subversion backend for post-1.0 versions only, so you either need to use development snapshots or wait for 5.x-2.0 in order to use it. Also, the Drupal 6 port will have to be postponed until these changes are done.

CVS backend on par with cvs.module

Last month I also got to (finally) port the log parser from cvs.module to the CVS backend, which means that the backend is now really as nice as the "backend part" of cvs.module. Feature-wise, in terms of polish, etc. - ok, if you don't take into account that cvs.module got an additional safety against branch creation through the backdoor in the meantime, which needs to be ported too.

The not so nice fact is that being on par with cvs.module is not sufficient, as we need more functionality in order to redo the (still pending) release node integration in a nicer way. That mostly includes retrieving directory listings as well as tags and branches for a given file (or directory), so that the release scripts don't have to base their data on post-commit hooks being tracked but can query CVS directly and still in a VCS-independent way. So, more work up for the CVS backend as well. Of course, if you look at it in a more optimistic way then you recognize that the same functions will help implementing the (eventual) repository viewer functionality for CVS :D

To infinity, and beyond!

Well, given all the workload that is mentioned above, it's going to be a tough schedule again, especially if I don't have the time that I was able to dedicate last summer. For the port of the release node integration (and release scripts) I'm relying on dww and hunmonk, whereas I still got to do a more advanced commit notification module (and some more stuff) for my late but ongoing university practical. Sometime later, we'll also want more fine-grained log/repository view permissions - I heard that request from a few people already - and write a unified solution for SVN/Git/Mercurial/Bazaar VCS user account authentication, as discussed in here.

Tons of stuff to do, you see. The good news is that you (yeah, ...you) can step up and make a difference! Whether that means porting aclight's hook scripts for Subversion to the new Subversion backend, or implementing the functions interfacing with CVS that are required for drupal.org deployment (thus speeding up the unmerciful destruction of cvs.module), or creating a module that synchronizes VCS users known to Drupal with the actual .htpasswd or SSH key files - there should be interesting stuff for everyone who wants to see Drupal shine as management and viewer tool for all kinds of version control systems.

Ok, enough of ongoing novel writing work, that should suffice for some time again :P