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

How to grant access to repositories at all is an important issue, and it potentially comes with a slight regression compared to the current work flow for managing CVS accounts. One advantage of CVS is that it's easy to administer - in terms of user accounts, that would be a simple "passwd" file that contains all usernames that are allowed to commit. Dead easy to generate, and at least possible to keep in sync even in an automated way. However, more recent version control systems are less nice to handle - also caused by a better eye on security concerns. An overview.

I just spent some time in #git to further investigate how our CVS access control scripts would translate to distributed version control systems, in order to help determine the right direction for our new GHOP-powered Git and Mercurial backends (currently being worked on, more on that to come later). Short answer: keep out of that altogether - it's not DVCS style to restrict project maintainers like that. Read on for a more detailed analysis.

Seems I haven't given up on Version Control API & friends by now, which one could say is a good thing. Due to my rather silent nature, there haven't been as many g.d.o posts as during the Summer of Code (namely, none until now). Nevertheless a good share of remaining issues have been resolved, and missing features have been added. Here's a short rundown of what has been achieved since part 2 of my wrap-up, which was written a month ago.

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!

It's over! Google Summer of Code 2007 had its official "pencils down" on Monday, 19:00 UTC - which was 21:00 at my place, perfect for a last sprint... but I digress. According to Google, mentors are supposed to evaluate projects based on the state that they were in at that time. Which means it's time for me to wrap it up and explain what I achieved in those two or three months. In addition to these writings, I set up a test site at http://www.petsovits.at/versioncontrol/ where you can try out most of these things in action.

The wrap-up is becoming too long to conveniently fit into one single blog entry, so I'll split it up into two halves. This one basically covers the hard facts: which modules I wrote during the Summer of Code, what they do, and how they work. (Part 2 is now also available.)

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.

This week, my Version Control SoC Project saw further completions of the API functions' implementations (the API itself is completely implemented now, if I'm not mistaken) and the creation of extendable admin screens, mainly for repositories for now. There's now a list of repositories separately for each version control system, and each backend can easily customize creation, editing and display of repository information by means of hook_form_alter() and a small number of more specific hooks. Repository management is now at the same level of functionality as the one in cvs.module, only that it's generic at the basics and other backends can without much effort provide their own custom stuff, just like CVS provides CVS modules and different methods of commit information retrieval. Sure, you want screenshots:

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.