[disclaimer] I'm writing this update while drupal.org (including g.d.o) is attacked by database-eating gremlins, so I can't currently check back on previous entries. Apologies in advance if I mention something that has already been said before. Yes, I could use the Google cache, but that's kinda tedious. [end of disclaimer]
So, I've been pretty absent for quite some time. After getting my university stuff finished, I found a bit less time for my Summer of Code project than I had expected, moving out from the dorms, packing bags, wrapping up undone stuff, whatever. Last week (June 29th to July 7th) I've been attending aKademy, the KDE conference, as previously announced. Great event, great people, great location (this year it took place in Glasgow, Scotland). You can read lots of coverage on KDE Dot News - start here (you can find me in the group photo) and go left in the navigation at the buttom, the marketing team has been active as never before. I wonder in which ways DrupalCon will be different from aKademy, as in my view the projects and their attitudes already differ fundamentally. Ok, so that's that.
Not having found the time before, I reallocated a few hours from aKademy's hacking sessions to my Summer of Code project. Since the last real update, the RCS API module has changed its name to Version Control API (versioncontrol.module), and the former project_rcs.module is now Version Control / Project Node Integration (versioncontrol_project.module). Both now contain a good amount of API functions for accessing commit data. Even if the implementation is still missing out (which, according to the project proposal, has been planned this way), they are the core of what other modules will use from the API module. (Read more...)
Today was the first day in a long time that I could fully devote to this project, so apart from the newly committed versioncontrol_project.module I added some more API functions to the API module. It's not perfect yet (see below) but I think the overall API design is sensible enough to allow for extensibility and optimization, as far as the split into frontend, API and backend allows to do this. Also, I spent a lot of time on good and consistent API documentation, which will both benefit the API users and me when implementing the functions. There's also an example module named FakeVCS backend, which comes with only a dumb implementation (predefined return values) but shows very well how a backend and the return values of many API functions needs to look like. For the end of the SoC, I'm also planning on another example module that people can use as skeleton template for starting their own one.
Upcoming work
- Fill in my Google half-term survey. I'm not sure what my mentors (Andy and Derek) think of my achievements until now, but at least from my side the experience has been very pleasing. I can nearly be sure that at least one of them is around to answer questions when I need help. With the API coming close to a sensible state, their input will be even more important. @Andy: Please mind to fill in your Google survey before Monday, July 16th.
- Figure out some remaining branch/tag stuff, in particular the issue of what information is needed to uniquely identify a file. When just regarding files that are known to have been modified in a certain commit, it's enough to specify that commit and the file path, and we can unambiguously get the file (which is the state of the API at the moment). When we want to retrieve the current state of a file at any arbitrary revision though, it seems that the branch or tag must be specified as well. Plus, how to get this additional knowledge into the API.
- Find out if the get_commits() function needs a $limit parameter ("only retrieve the last 10 items that match the given conditions") and if so, how this can be done while leaving most of the querying work to the database. (Sounds like a database query hook for the backends.) But this is rather optimization than architecture and should be done when the actual implementation is ready.
Anyways, I'm back. Last semester is over. aKademy is over. Which means that the rest of my summer clearly belongs to Drupal. Let's get this thing moving!
Also, point 3 in my proposal is now on, which reads
Refactor the database table layout of the current cvs.module so that there is a table scheme for the project_rcs_api module containing RCS independent information, and redesign the table layout of cvs.module so that it complements the RCS independent tables. In order to make sure the project_rcs_api table layout is really RCS independent, create a similar complementary layout that an SVN backend would use. (For the latter, take into account how existing Subversion module tables look like.) Improve the RCS API based on knowing the exact table structure.
Targeted for: 2007/07/16
Basically, I did the table layout split at the very beginning, so this point is mostly done already. The primary issue left here is what to do with the motivation text and approval procedures, as those can be significantly different for different VCS hosting sites - just compare the approval procedures on SourceForge to drupal.org. SVN, being a more capable VCS itself, will only need a subset of the database tables that the CVS backend uses. This part and improving the API go hand in hand anyways, so more work on the basics is coming up.