Version Control API in Drupal 6 and beyond

It's been a long time since I last posted an update on the state of the Version Control API, assuming we disregard short teasers on Planet Drupal. Since this last article, Version Control API nearly died during my attempts to wholly restructure the data model for practically everything involving commits, branches & tags (now unified as "labels") and repository items (= files and directories). Luckily, the story has come to a good end. Well, "end"? Depends.

The module family is working nicely again, the foundations have been laid for future goodness, and Sam Boyer took maintainership of Version Control API and promises a bright future for it. Which in turn motivated me to keep working on it. Win/win, so to say.

Don't look back: Plans for the short to medium term

As of now, the release cycle for Drupal 5 based releases is done - I just pushed out all the 5.x-2.0 releases - and the Drupal 6 port is progressing quite nicely. My current plan is to make stuff work like it did with 5.x-2.0, and release that as 6.x-1.0 so that the longing masses (right?) can finally jump on a 6.x version.

After that, it's time to go for the remaining features that are missing for Version Control API & CVS backend being deployed on drupal.org. Of course, I've been saying that since, like, more than a year, but at least some of the functionality has slowly been implemented, and with consistently more work going into those modules than into the resident local hero, cvs.module, there has to be a time when feature parity is achieved. (I just hope that happens before I start to work full-time at some exhausting place.)

For coders who want to accelerate the d.o deployment plans, there's still the old trusted TODO list which I'm keeping current whenever some required feature is implemented. In principle you can help out with any of those, they're mostly independent and nicely scoped so it's easy to focus on just one aspect of the whole picture.

In Soviet Russia, Version Control API works for YOU!!

Or something. Anyways, after the tons of API changes for the 5.x-2.0 release, it's actually realistic to adapt Version Control API's functionality to your specific use case, provided that writing a little extra code doesn't make you cringe.

For instance, 5.x-2.0 contains rudimentary integration with the workflow_ng module (renamed Rules for 6.x) that demonstrates the ease of sending commit notification mails - combined with a (to-be-written) "Subscribe to commits" block, filtered notifications per user shouldn't be hard to do. Also, embedding the commit log is now possible in a nice & clean & easy way, so for example Repoview could reuse Commit Log's message view for displaying the revision history of a file.

There are tons of possible integration opportunities - closing issues when the node id is mentioned in the commit message, gathering commits and node contents into a weekly commit digest, or making release tarballs work at last (hint, hint, d.o deployment) - many of the use cases could be implemented with a minimal amount of work.

Personally, I'll be spending my (limited) time pursuing the drupal.org deployment, so quite a few of the "cool" features won't be tackled by myself. That includes the Git and Mercurial backends, which unfortunately haven't been updated to the 5.x-2.x API yet - Jimmy Berry (Git backend maintainer) is busy rocking the testing infrastructure, and Edward Yang is apparently gone from drupal.org. Porting those backends mostly means to throw away a lot of code and write update routines for the table contents, but maybe we should just skip an upgrade path for these backends and just get them running on the 6.x version so people can make use of them at all. Anyways, that's definitely an area where you can make a difference.

Still want more? Sure...

So when all that pressing stuff is done and d.o is running along peacefully on Version Control API, we could even go on to implement some more architectural improvements. On the one hand, a sane system for user authentication/authorization (which basically means to synchronize VCS accounts between Drupal and the version control system) is probably my favorite item, and only postponed because the other stuff is more important right now. On the other hand, a move from functions and structured arrays to real classes and objects has a lot of potential for improvements, including better separation of concerns and lazy loading that could obsolete much of the current efforts of tracking state.

For now, the major portion of the above wishlist is unlikely to manifest anytime soon, unless Sam and me are helped by other members of the community. But then again, even in the current state where the feature set has not (by far) reached its full potential, a working Version Control API with CVS and SVN backend (maintained by the API module maintainers themselves) should be rocking hard enough to have the project progress further towards world domination. As long as we're alive and kicking, good stuff is bound to happen. :)