SoC 2007

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:

This is the second in a series of articles on Phing the fantastic PHP application build framework which DAST extends. Although DAST will come with quite a number of ready-made scripts, its real power lies in providing the foundation for Drupal developers, testers, admins and distro maintainers to quickly and easily create their own build scripts. A distro builder may choose to bundle their build script which painlessly downloads the required modules, sets up the user's database, and runs basic smoke tests to verify the Drupal web site on the user's web server is ready to use. DAST applies the concept of a software project build to creating Drupal sites and has a wide range of uses - See the upcoming article "10 cool Drupal things to do with DAST."

In Part I I looked at the basic structure of a Phing build file - projects, targets, and tasks. I posted a use case http://groups.drupal.org/node/4477 which is now implemented as the dast-patch build file for automating creating patch test-beds. In Part III we'll look at how this build file was implemented using the stuff we've covered before. First I'll wrap up this dive into basic Phing with a a description of properties and types which are present in every useful build file, mappers and filter chains which are used for file I/O, and the ever-important conditional execution and iteration. Remember Phing is a feature complete implementation of Ant - all concepts in Phing are identical to their Ant counterparts, so if you're familiar with writing Ant build files, using Phing will be easy like Sunday morning.

Just a short update on what I'm working on right now
1. LAMP config - each build script derived from the base site-configure script can specify server config directives - I'm using the Pear::Config (http://pear.php.net/package/Config/) for writing and reading from the Apache conf, MySQL and PHP configuration files

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:

With the midpoint of the summer passed, it's time to evaluate how things stand so far and then looking forward to what should be done next. The first three objectives I listed at the start have been accomplished.

1. A command-line toolkit for automatically downloading specific versions of Drupal code and building the site-code tree; consisting of:
   1.1 A schema for describing a Drupal site deployment with the following information:
   a) CVS revision of core .inc and .php files
   b) CVS revisions of core module files
   c) Name and CVS revisions of contrib- modules

The first release of DAST is available on d.o: http://drupal.org/project/DAST. See the INSTALL.txt and README.txt - you'll need to download additional dependencies from http://www.abeharry.info/stuff/dast-deps.tar.gz or http://www.abeharry.info/stuff/dast-deps.zip A guide to using the dast-patch build file is available here: http://groups.drupal.org/node/5124 I'd appreciate feedback from anybody who wants to try it out - for what the project is trying to accomplish see here: http://groups.drupal.org/node/3913 .

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.

Hello, all

In case you're interested:

http://drupal.org/project/googleauth

Cheers,

Bill

Actually, I wanted to write a piece on how the Version Control API is maturing, but I've got to leave here in a few minutes and won't have internet available until tomorrow, so this must wait for now. Instead, a short coverage of the Version Control / Project Node Integration module (versioncontrol_project.module).

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