Progress, aims & challenges

The end of the Google Summer of Code is nearing, and stuff is coming together in my version control modules. It seems to me like I'll not be achieving everything that I would have liked, but most of the important stuff is going to be ready next Monday. And now for a short report of the last one-and-a-half weeks.

Project node integration

After finishing the basics of account management (only #1 of my last status update, for now), I felt like finally integrating that version control stuff with project nodes. In this domain, one has to differentiate between two different things: there's integration with stock project nodes like those provided by the Project module, and integration with project release nodes - those that were introduced with dww's New Release System(TM) and represent specific releases of a project node.

Originally, I had planned to provide "native" support for branches from within my own project node module, so that you can look at all branches of a project on a single page, including separate commit access rights for each branch (which would be cool to have), maybe on an additional tab of the project page, something like that. That was a cool idea until I had a more detailed look at the project_release module, because it would mean massive changes to how release nodes work, maybe even a rewrite of it. I only then realized that release nodes actually are the representations of branches and tags, so everything I planned should probably go there instead of having branch support in my project node integration module. But before coming to that awareness, I had a major think and work stoppage that deferred my time schedule quite a bit.

So then I decided to cut down to the current state of how things work, and implemented the "CVS access" tab (renamed to "Commit access") and all that jazz that's required for assigning nodes to repository folders and project maintainership to Drupal users. Oh, and what's really cool about it is that you can assign "project" status to any content type on your site. Which is in fact an improvement to the current state of things :D ...and it looks like this:

Commit Restrictions

At that time (about a week ago), I wanted to post an update... but I was seduced by getting just a bit more code to work and reporting back afterwards. The thing is that once you have all those project relations working, it's quite a breeze to implement the hook functions that restrict commit access to existing projects and their maintainers. It was indeed very straightforward, so I figured out a nice commit/branch/tag access API and implemented project node based restrictions.

Of course, those restrictions were not really working yet, as the commitinfo and taginfo hook scripts (or trigger scripts as they're called for CVS) were not ported to the Version Control API yet. Nevertheless, I felt like this was the time to get the other, non-project commit restrictions done as well, and because I didn't want all of those to clutter the main Version Control API module itself (it's already large enough) I split those off into a separate module called Commit Restrictions. Like Commit Log, that module will probably be popular enough to be widely used, so it's also in a subdirectory of the Version Control API module, which makes for painless distribution.

As opposed to the current access restrictions (which are defined in the xcvs-config.php file that is directly included by the hook scripts) it has a Drupal-based admin interface, form_altered into the add/edit form of each repository that supports commit or branch/tag restrictions. One restriction (allowing branches and tags only in predefined directories) is still missing, but it already looks ok:

Final work on the CVS backend

That was on Monday or Tuesday, and I could have proclaimed success then... but I was but I was seduced by getting just a bit more code to work and reporting back afterwards. The thing is that once you have all those restrictions implemented, you certainly want to try them out, as implemented stuff is only half as cool if there's nothing to show off. So I went off to port the commitinfo and taginfo scripts, and this work was not all too hard... apart from the fact that the CVS backend didn't have a notion of tags at that time. As branches and tags are the same thing for CVS (not for the backend, btw), it's hard to write a tag/branch access hook script when the backend doesn't support tags.

That was one of the (few, by now) points on my todo list anyways, so I decided to take this last one on before writing my update. Well, and that's what I did. In the end, both code and database tables of the CVS backend changed quite a bit, so I'll probably need to reinstall it and clear the example commit logs that were produced while developing the backend. (Robert Douglass needs some for his FrOSCon presentation, so I'll have to redo at least a few of them.) I didn't test much so access restrictions are likely not to work at the moment - they should, though - but finally everything is in place for all of this to work.

The CVS backend now has all functions that are mandated by the Version Control API, and is fully functional. There is a lot of advanced functionality which is considered optional by the Version Control API, mostly stuff that can facilitate repository browsing, and that is supported neither by the original cvs.module nor by the new CVS backend. I didn't plan on implementing this functionality, and even release node integration (which is quite demanding, I tell you) should need only little of what's not yet there already.

Refactoring!

Everything's in place? Well, not entirely. When I was close to finishing the hook scripts and the database structure was finally in a state where I liked it, another idea came to me (that was today) - centralizing the non-file part of the tag and branch tables in the Version Control API, and tracking only file/directory associations in the backends. At the moment, branches and tags are completely handled by the backends, but I can well imagine even a Subversion backend to use the database this way. As the database schema is, like, highest priority because it causes significant effort to change stuff when it already exists, I'm going to tackle this next.

The plan is to have tables for branch and tag operations that look quite, but not entirely, similar - the columns will probably be: branch/tag operation id, branch/tag name, repository, containing directory, timestamp, and action ('add', 'move' or 'delete'). Each of the rows corresponds to a successful branch or tag call and will probably be amended with backend-specific tables that associate branch/tag operations to file revisions.

Apart from this last major change, most of the planned functionality is in place now.

Upcoming work

I should get this branch/tag centralization done by tomorrow. Still, there are some points on my list:

• Account motivation message management and approval. Most likely the next thing that I'll take on, and probably the last thing that I'll fully get done.
• CVS account import and export. (I just noticed this is still missing as well. Oops.) Not all too much work, but little time to do it.
• Port log parsing from cvs.module to the CVS backend. I'd still like to get this done as well, if only to make the select box in the add/edit CVS repository form meaningful. Shouldn't be really hard anymore, or take too much time.
• More optimization in order to cut down on the number of SQL queries. Well... there's not all too much time left to effectively optimize those queries. I'll leave this one out, and we'll probably notice in case it doesn't perform as needed. In any case, it'll definitely work for sites that are not as demanding as drupal.org.
• project_release integration. That's the one I'm actively sorry about not getting it done, I'm not going to make it in time for the deadline on Monday. Let's see how that affects my mentor assessment.
• A few leftovers in various modules to complete the functionality which is in cvs.module. Like, directory restrictions for branches and tags, an implementation of hook_user in Version Control API in order to catch user deletions, some minor TODOs here and there.

You'll hear back from me when the deadline has arrived. Till then, back to a busy coding weekend!

In other news

I had a concert in Slovenia (Novo Mesto) with my band, and it went really smoothly. Nice organization crew, nice audience, great main act, and lots of time spent driving the car. How it's good to have an excellent drummer and an amazing base player as comrades :)