summer of code

So this week saw the successful completion of file uploads! When files are uploaded a private flag is successfully set in the database indicating whether the file should be private or public. There is more work to do to transfer some functions over to the new file object interface and also an administrative interface will probably be made. As per the usual you can check out the latest code with bazaar from http://drupal.codeincarnate.com.

Last week was spent giving much overview of the code, as well as starting to play around with the layout and design of the forms. I spent a lot of time catching up on some of the drupal dojos. Diving into the nodeAPI as well as forms API. and spending much time on api.drupal.org to figure out what the current functions in the current case tracker module are doing. I spent some time learning some of the jQuery syntax as well as AJAX ( I am new to programming w/ AJAX). I also spent time learning CVS for drupal.

So work on public and private files is really starting to pick up. A fair amount of work has gone into file.inc which includes adding a path for private files, switching file_create_url to use the database and adding some functions to swtich files to public or private. Things are becoming somewhat functional and progress is going well. If you want to check out the changes you can use bazaar to grab the code at http://drupal.codeincarnate.com.

I've spent the past week coding the DAST patch tester - I really want to get this released with patch testing becoming a huge priority right now and new features like Chad's delete API only having a week left to be evaluated before the D6 code-freeze. I want to get this out today - I'll post another update later.

I had my last exam yesterday, which is why you didn't hear from me since the last write-up from nearly a week ago. One more assignment is likely to keep me busy until Monday, but when that's done I can fully focus on my SoC project. That is, apart from the week-long interruption by the KDE conference where I head to on next week's Friday.

Oh boy, I wish I could borrow just a fraction of the time that I have in July and August, and use it before the mid-term deadline x-)

So, Mercurial, or "hg" in short. One of the two revision control systems originally written for being the Linux kernel's BitKeeper replacement - in the end, git was chosen for that job, but Mercurial lived on nevertheless. The requirement of being suitable for kernel development implied two features: performance (although git is still a tiny bit faster) and distributed development methodologies. Both are also present in git, and in fact, the two systems are very similar in scope, paradigms and usage patterns.

While git is written in pure C, Mercurial mostly consists of Python code, with only small, critical code paths implemented in C. This has benefits for Mercurial's portability, as can even be observed with other SoC students. git is pretty much focused on just Linux, whereas Mercurial can also be installed more easily on Windows and other Unixes. Not that straightforward graphical tools are yet as mature as the ones that exist for CVS or SVN.

CVS, or Concurrent Versions System, was the de-facto standard open source version control system for a long time. It came up in the late 80s and grew popular enough to manage the source repositories of virtually all open source projects until only a few years ago (when Subversion started to take over). It's still widely used, including on drupal.org, but hardly deployed on newly created repositories anymore. Development is strictly fixed to a centralized client-server methology, and while distributed version control systems (or Subversion with svk) strive to make a checkout independent from the server, with CVS you're completely dependent on a fast and reliable connection to upstream.

In summary, there's little surprises in this CVS coverage, especially for the resident drupal.org admins. But necessary nevertheless, if only for later reference. Obviously, no new requirements for the API module were found, as the CVS setup on drupal.org together with the Project module is the status quo at the moment.

Last weekend I spent more time on the design document, I also spent time playing with many various modules to see about integration with the extend case tracker module. I have been working on a mock design and how things will function and integrate. I also started looking at all the existing case tracker module code to see how things are interacting with other modules and what type of functionality exist there. I had a discussion with yoroy and with Dave Notik (sponsor of the case tracker module) about usability and design.

My project definition says that I still got to document the specifics of SVN and CVS (git has been taken care of). Coming from the KDE camp, I'm already acquainted to Subversion to a certain degree, as the whole huge KDE repository switched from CVS in May 2005. (No one, including the SVN admin, did regret the switch).

Subversion (SVN) came up as a replacement for CVS - motto: "CVS done right" - and incorporates its centralized development methology and its straight-forward workflow, while improving on its weak parts. Compared to CVS, Subversion features good stuff like atomic commits, renaming, serverless diffs, symlink support and version-controlled directories, to name the most popular ones. It fulfills its role as a drop-in replacement brilliantly and has kinda deprecated CVS, at least for newly installed repositories. (That, of course, doesn't stop Linus Torvalds from claiming that centralized development methologies are outright wrong.)

There was a quote of someone saying that inexperienced programmers worry about code, while advanced programmers worry about data structures. Don't remember who said that, but personally I find this an excellent analysis.

Let's try to formulate the important questions that need to be answered in order to get the Revision Control API right:

1. What kinds of functionality do users need from the API?
2. What kinds of functionality do different revision control systems provide?
3. How does the data that is delivered to the caller look like?
4. Which functions are required to deliver the data to the caller?