SoC

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.

Since everyone else in a true computer science fashion decided to count weeks starting at 0, this is a second week 2 for me. As usual, I posted an update on my development site on how the coding is going. There was also a mid-week update that went over the general structure of the client component.

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?

This is copied from my current project site:

Things are finally getting started. So for the first week Drupal 6 was settled on. So I was able to get a little familiar and get a good test environment set up for development. Some initial changes were made to file saving so that a private/public flag would be set (right now everything is considered public). Unfortunately the power supply on the computer I use for development died. So things might be a little slow until I get the new power supply on Thursday. Thus is life and so I'll get to really push myself over the next weekend ;).

Not whole lot of new things to report as far as my project goes. I started reading over the relevant RFCs, I'm still in the processes of setting up the servers that I need to write and test this project, and I spent most of today playing around with a new version control system that I found called Mercurial. Other SoC students who would like to keep track of their projects in another location besides the Drupal CVS might want to take a look at it. More info on my development site.

The first week of summer of code is nearly over. So it’s time for a short report what I’ve done so far with the “Taxonomy Manager”.

First of all, a short description of my project. At the moment, the Drupal’s taxonomy module provides only a simple administration page for adding / editing terms. When having a bigger amount of terms, it gets hard to manage the list of terms. My project will implement an additional powerful interface for managing longer lists of terms.

There's a great introduction on git for SVN people like me, which made it twice as easy for me to look into how this thing works. Git only recently released their 1.5 version which is the first one that's supposed to be usable to the masses. (It might not yet be available pre-packaged for your Linux distribution, or available at all if you're running Windows, which could be a small hurdle at the beginning.) After reading the introductory couse and trying it out by myself, I must say I'm hooked.

For those who didn't know, git is the distributed RCS that was created by Linus and the other kernel folks because they needed to get rid of BitKeeper, and as the Linux kernel is a very demanding project both in code size and in patch management, git is quite capable indeed from an efficiency point of view. Currently in use by the Linux kernel itself, X.org, Wine, and One Laptop Per Child, to name a few popular projects.

As promised in my SoC application, here's a short rundown of features that are important to this abstraction layer.