Version control wrap-up, part 2: comments

If you already had a go at part 1, you have been waiting half a week for this one. Lack of internet, party intermezzos and my first company outing caused a minor delay, but here you are! While part 1 was meant as a higher-level overview and introduction for interested bystanders, part 2 aims more to provide a sound basis for my mentors to evaluate the Summer of Code project. For that matter, this post also has the source code of the three project directories (Version Control API & children, CVS backend, project node integration) at the state of the "pencils down" deadline (Monday 20th, 19:00 UTC) attached - its real file extension is of course tar.bz2 which groups.drupal.org doesn't permit to upload as such.

Little arithmetics

Out of interest, I wrote a small shell script that measures a set of line counts in a directory and did a few runs on my module as well as the original cvs.module from which I started out. As a result, you'll get a table with line count statistics:

Neat, isn't it? Six modules doing the same as (in fact, less than) cvs.module, with two times as much code... but, er, you know, it's VCS independent now :D

The real sugar

Now, what have I achieved in this SoC project, what does all the code do? The module-centric breakdown is already covered in part 1, however I thought it appropriate to sum up the major achievements in a more task-centric and comparative list of bullet points.

• An extensible, VCS independent API for server-side version control needs. This, of course, was the topmost goal of this project, and I think it worked out quite well. Might still need the one or the other addition for release node integration, and for sure has potential for better optimization, but all in all it's pretty comprehensive and easy enough to implement and use.
• Extensive documentation. As the above statistics might suggest, most modules and the API functions in particular include a whole lot of apidox. I didn't yet run it through phpdoc yet so it might not look perfect, but all the important parameters and result values are documented and specified in detail, which is especially important when implementing a backend. There's also the FakeVCS module that provides template/boilerplate code for backend writers. I wonder if it's possible to get the API and the FakeVCS module on api.drupal.org.
• Pluggable backends. The API should be VCS agnostic enough to allow usages that really fit into the VCS's way of doing things, while still providing a unified interface to the user. It is now really feasible to write a backend - it's hardly more than providing hook scripts that transform command line input into the API's structured array format, and implementing a few functions that perform read/write operations on the backend specific database tables. The API is designed in a way that allows VCS specific information to be added to pretty much all objects that it handles, and provides some additional comfort for backends that would like that API module to manage its table additions.
• Commit restrictions are decentralized. Anyone can implement hook_versioncontrol_{commit,branch,tag}_access() and impose their own site or module specific access control.
• Pluggable account registration. Including the Version Control Account Status module, there are now three possible ways of having new VCS accounts registered (I recently thought of a fourth one that I'll also implement soon). If none of those accomodates the way that users are required to apply on your site, it's possible to write your own module that modifies the standard user account creation. Not quite as easy as adding commit restrictions, but at least doable at all - as opposed to cvs.module where the drupal.org way of user applications is hardcoded.
• Project node integration for all node types. cvs.module also hardcodes the "Project" and "Project release" content types for holding version control related information. While the integration with the project_release module is tied enough to node type specifics that this makes sense, it's hardly necessary to predefine the "Project" type in this regard. With the new project node integration module, you can have project.module's projects as well as case tracker projects as well as any other content type get an associated repository location, per-project commit log pages, and commit restrictions.
• Hooks for everybody! If you want to write a module that mails out project specific commit messages to subscribers, or a module that closes issues when they are mentioned in the commit message, or a module that automatically creates tarballs when a tag is assigned, look no further - you can do it with the hooks that the Version Control API provides.

Not an all too bad outcome, I think. But there are also things that I didn't complete in time even if they were planned.

A shocking lack thereof

I totally love bullet points - here we go again.

• Release node integration. Point of criticism #1. This is critical for replacing cvs.module on drupal.org, and I didn't even get started on it. It's still a major undertaking (definitely not under three days, I'd rather estimate a week) and I regret not coding fast enough to also have this.
• CVS account import and export. For sure nice to have if you're administering a VCS installation. Done.
• Filtering the account table by status. Not really critical, but nevertheless a regression when compared to cvs.module. Done.
• Commit notification mails. I ripped those out of the CVS backend, because they should rather be done in a VCS independent way, probably as part of the Commit Log module (which already renders commit messages to HTML, so mail friendly output would be a logical extension). I didn't get to reimplement them, though, it's still left to do. Done.
• "Most active developers/projects" blocks. Minor and easy, which is why I deferred them until a later date. Where a later date is probably next week, although after the deadline in any case. Done.
• Log parsing, to be ported from cvs.module to the CVS backend. Done.
• Minor bugs and TODO items. Not a whole lot, but still noticable. Only a few minor ones left. Done. Hah.

Additionally, the attached tarball containing the code at the time of the deadline is not as functional as it might be - from my last-weekend-code-shuffling session I left one or two bugs in the CVS backend that prevented new commits to be recorded, and the account status module was still being written so that it doesn't quite work sufficiently in the tarball's version. Those issues are fixed by now (everything basically worked smoothly again after squashing bugs on Tuesday), so don't use the modules in the tarball for anything other than evaluating the code base. (Even if buggy, all the code is there - I would of course prefer my mentors to largely disregard those user-visible issues from the tarball version and focus on the code itself. But then, I don't want to tell anyone how to review my project.)

Nothing really ends

I'm dedicated to implement the stuff that's still missing from cvs.module's feature set, apart from release node integration where I'm not sure if I can find the time to tackle it. (Help appreciated!) Also, a few recent additions to cvs.module (Postgres support, essentially) should be redone for Version Control API & friends as well.

In any case, in order to keep cvs.module drifting away from the Version Control API with an ever-extending set of features, I think it's important to get the latter into a state where it can be deployed on drupal.org. Whoever wants to support me in doing so is strongly invited to. (After all, with Summer of Code being over, the community can now chime in to their hearts' content!)

Also, there seems to be significant interest in a Subversion backend - I wasn't yet asked about one of the other version control systems - and I'll try to reuse one of my pending university practicals for creating one. It's not fixed yet, so don't rely on this statement before I get the university assistant to actually sign it off.

As for the short term, I'm going to push out a first release really soon. Like, providing additional capability flags for backends to specify that they support account import/export, and then release an alpha. Or a beta. Whatever.

Fell off the floor, man

And so, the summer goes to its end. For me, this post is the official end of my SoC involvement, and any efforts from now on are only accomodating my own personal interests. After today's Dojo session, that is. I hope my spoken English is not as bad as last time...

The survey deadline is August 31th, so I would appreciate my mentors to evaluate my project before that date, and Andy to submit the survey by then. As for communication - I know I haven't been the most active IRC participant ever, but I hope that the status update posts communicated progress and questions good enough. At least, I spent not too little time to put them together :)

Finally, I'm very curious about my evaluation. Let me know how you think about how the project worked out. And now... off to making Version Control API rock!