And that is the Kafkaesque horror-show we subject any newcomers that would like to publish their code on Drupal.org to. It goes by the name of “Project Applications“.

Never ending reviews

I know several people who've hit this wall when trying to contribute code. It's not uncommon to wait several months to get someone to review your code. And when it does happen, people are often rejected for tiny code style issues, like not ending their comments with a period or similar.

And even if you manage to satisfy all the reviewers (many of whom are just reviewing to earn “Review Bonus”, see below), you can still wait several months for the powers that be to give you the magic stamp of approval.

Consequently, people give up. Who knows how many valuable contributors we lose, because they feel unwelcome and unappreciated? Most of the criticism in this issue from 2010 is still true.

“Review Bonus”

As mentioned before, the common answer to people that are frustrated with the waiting time, is that they should go get some brownie points to expect getting reviewed any time soon.

Basically, the messaging goes a bit like this:

Oh, you're unsatisfied with having to jump through all these hoops to contribute to our open source project? Here's some more hoops to jump through.

If there's a more efficient way to make people angry, I can't really think of it.

And as another problem, because of this sweat-equity requirement, you now have newbies reviewing each other's code, with all sorts of perverse incentives to just review quickly and cursorily to get the review bonus, futher exacerbating the problem.

Only applies to newbies

I've never had to gone through this. Neither have many Drupal developers I know. Because we were grandfathered in from the old CVS access system. It also had reviews, but to my memory, these were a lot less strict.

And once you pass the initial review, you're given the keys to the kingdom. After that, you can create as many new project, and publish as much terrible code on Drupal.org as you want to.

Does it work?

Not really. At the time of this writing, there were about 300 open requests in the Project applications queue, most of them more than a month old.

Is this even necessary?

In a word, no. I think Drupal is pretty unique in this regard. All other big open source communities I know of have no such requirements.

Packagist for Composer, GitHub, npm, Bower, etc. all allow anyone and everyone to create packages.

I imagine that some would argue that scary things can happen if you allow people to publish code without review. But if someone had sinister intentions, it would not be hard to wait with publishing malicious code until after the review, would it?

It's a bit like we're trying to achieve Apple's model for their App Store on Drupal.org, where everything is reviewed and safe to install. With the important difference that we don't have hundreds of full-time employees to make such reviews in a timely and professional manner.

End the madness

We can end the madness. We have the new community role on Drupal.org. How about we just require that for code publication, rather than trying to boil the ocean.

To my great shame, I was part of the initial discussions about this system, at DrupalCon Copenhagen in 2010. Back then, we were concerned about review times, and time has proven us right.

It was a valiant attempt. I think it's pretty clear that it does not, and will never, work to the degree we need it to. So let's change, make new people feel welcome again.

Do you need to tell your visitors when you are open for business? Your office hours, when the service desk is open?

Then Opening Hours might be the module for you. In this post, I’m going demonstrate how the module can be used, as well as some of the API capabilities for extending it.

The backstory

In the autumn of 2011, Copenhagen Public Libraries decided that it was about time they got a better solution for their opening hours.

Since the current site was first launched in 2009, we had been using a hacked up version of another Drupal module, “office hours”, which was, to say it mildly, rather user-hostile. It used a cascading rule system to determine the opening hours, and suffice to say that people other than myself understood how to use it.

So, we were given the task of coming up with something better, so @rasmusluckow, Joan (who sadly didn’t live to see it deployed), and I made a plan, and I started building the module in november 2011.

The plan was to create an administration interface similar to Google Calender, with a very visual representation of what’s going on.

Copenhagen Public Libraries was still on Drupal 6 back (in fact, it still is), so we decided to build it for both versions. That meant we could not easily take advantage of all the new fields hotness in Drupal 7, but it has made it a lot easier to maintain both versions together.

After a lot of development work, tests, and changes, we got the new system live some time in spring 2012. I remember making an informal bet with @kasperg that I had managed to fix all the wierd date and timezone bugs. As it turns out, I lost…

Since the start, the module has been available on Drupal.org, but it has seen rather limited use outside the Ding.TING project for which it was intended.

I hope to rectify that, and one of the ways is to provide more documentation, making it easier to get started with the module.

Installation and configuration

The module is fairly simple to install as Drupal modules go. It depends on the Tipsy and Date module (for date popups). If you use drush, you can get and install the requirements with a couple of commands:

drush dl date tipsy opening_hours
drush en taxonomy date_popup tipsy opening_hours

If not, download these modules manually, and enable Date Popup, Tipsy tooltips, as well as Opening hours on the modules page. You might also want to enable taxonomy for categorising opening hours, but more on that later.

The Date API settings will allow you to configure which day the week starts with (monday in most places, sunday in the U.S.).

Nota bene

While writing this, I found a bug in the Opening Hours module, that causes the admin interface not to load correctly, when the opening hours block is inserted on all pages. If you want to follow this tutorial, you will need to get the latest version of this module, at the time of this writing, 7.x-1.5-beta1.

Node type settings

First off, we need to enable Opening Hours on the node type. In this example, we’re using car dealerships, but it could anything that needs opening hours.

Your first opening hours

To use the opening hours, go to a node of the type you just enabled opening hours on, and click the opening hours tab. Then you should see something like this:

Click the empty cells below the dates to add hours to that date. This brings up this dialog:

The basic use case is quickly managed. Fill out open and closing times, and if this is the general rule, you can set it to repeat every week.

So if you have open every monday 9:00-17:30, you would do something like this:

Repeating this for all week days, we get something like this:

If you made a repeat rule, you can use the navigation at the top to switch to one of the following weeks and see the same hours.

Displaying your hours

Now, you have your hours entered, you probably also want to display them on your site. The easiest way to accomplish this, is to insert the opening hours block on the page via the Drupal’s block administration:

Once done, you can see the opening hours on the node page, like this:

Overriding

Now, that’s all well and good, but how about exceptions. Next week, monday is closed?

No problem, just go back to the administration interface, navigate to the week in question and click the hours for the day in question.

To mark this day as closed, simply delete its opening hours by clicking “Delete this instance”.

If you switched weeks before deleting, you should be presented with a dialog like this one:

This is presented, since you’re deleting something from the middle of the chain of repeated events, so your intentions might be different, depending on the situation. You can choose between:

1. Deleting the hours instance for just this week. In this example, that means that this monday will be closed, but all previous and following mondays will remain the same.
2. Deleting this week and all following instances. In this example, it means that the monday in question will be close, as well as all mondays after it.
3. Deleting the entire series. In this example, that means that all mondays ever will appear to be closed.
4. Cancelling the deletion, leaving everything as it was.

There’s a similar workflow when you edit hours, so you can go to say, week 42 and change the hours, and then apply them to all the following weeks to have different winter opening hours, for example.

To be continued

There’s a lot more ground to cover – categorisation, segments, customisation and API, and this already took half a day to write, so I’m going to pick this up later and expand on it.

When I started using Octopress, it only had a site-wide Atom feed, and despite my little experience with Ruby or Liquid, I managed to hack together category-specific feeds for Octopress. These were merged into Octopress core, so if you get the latest version from the master branch, you should have these.

Sadly, despite my feed being valid Atom 1.0, Planet Drupal does not parse it properly, and my blog posts were still not included in its feed. This might not be all that surprising to someone more familiar with the history of the aggregator.module, which is the feed aggregation module that ships with Drupal, that Planet Drupal uses for its syndication.

Politely said, this module is not one of the parts of Drupal core that gets the most attention, and its feed parsing code is not exactly state-of-the-art. In fact, it only supports a subset of the Atom spec and a particular version of the older and inferior RSS. Now, I won’t get into the nasty history of web syndication technology, but suffice to say that this is one of the instances where I find myself wishing that the Drupal community wasn’t so NIH-prone. (that goes for you, too, project.module).

So, long story short, if you want to be on Drupal planet, you have to implement a feed format it understands, so I made an old-school RSS format, that should correspond almost exactly to what Drupal itself outputs when it generates feeds.

The template

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---
layout: nil
---
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="{{ site.url }}" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
  <title>Planet Drupal | {{ site.title | xml_escape }}</title>
  <link>{{ site.url }}/planet_drupal.xml</link>
  <atom:link href="{{ site.url }}/planet_drupal.xml" rel="self" type="application/rss+xml" />
  <language>en</language>
  <generator>Octopress</generator>
  <description>Planet Drupal RSS feed for {{ site.url }}</description>

{% for post in site.categories['Drupal'] limit: 10 %}
  <item>
    <title>{{ post.title | xml_escape }}</title>
    <link>{{ site.url }}{{ post.url }}</link>
    <dc:creator>{{ site.author | xml_escape }}</dc:creator>
    <guid isPermaLink="true">{{ site.url }}{{ post.url }}</guid>
    <pubDate>{{ post.date | date: "%a, %d %b %Y %H:%M:%S %z" }}</pubDate>
    <description><![CDATA[{{ post.content | expand_urls: site.url | cdata_escape }}]]></description>
  </item>
{% endfor %}

</channel>
</rss>

How to do it

1. Download the feed template attached above.

2. Put it somewhere in the source folder of your Octopress site.

   I have it at source/planet_drupal.xml, but the name and location should make no difference at all. Since I have it at the route of the source tree, my feed is available at http://mikkel.hoegh.org/planet_drupal.xml

3. Change the {% for post in site.categories['Drupal'] limit: 10 %} line to match the name of the category you want to make a feed of. In my case, the category name is Drupal. This is probably case sensitive, so be sure to be consistent when categorizing your posts.

4. If you haven’t done so already, tag your posts with the right category to have them included in the feed.

   This is how this post is tagged, for reference. This is standard Octopress post metadata.

    ---
    layout: post
    title: "How to configure Octopress for Drupal Planet syndication"
    date: 2012-08-12 22:32
    comments: true
    categories: [ Drupal, Octopress ]
    ---
    [post body here]
   

5. Redirect your current feed address or report your new feed address to the Drupal.org webmasters.

I recently found a clean way to get rid of a couple of those. These two were introduced in Drupal 7, and you will probably find them on almost all Drupal 7 sites – they look like this:

Or in markup:

1
2
3
4
5
6
7

<div class="region region-content">
  <div id="block-system-main" class="block block-system">
    <div class="content">
    <!-- Actual page content here -->
    </div>
  </div>
</div>

Now, the last of these wrappers are actually useful, the rest stems from one of the changes in Drupal 7, namely that the main page content is now a block, that can be positioned on the page via Drupal’s block system.

Now, that’s a nice concept, but all the site I’ve seen do business as usual, and get around this inconvenience by creating a block region called “content” and sticking the content-block in there as the only thing, leaving the region and block wrappers as more DIV-spam in your site’s markup.

So unless you’re actually doing something different with the content block and/or region, you can just get rid of these extra wrappers by sticking the two following templates in your theme’s template folder:

1
2
3
4
5
6
7
8

<?php
/**
 * @file
 * Render the main content block region.
 *
 * We don't print all kinds of wrapper divs and titles, just the content.
 */
print $content;

1
2
3
4
5
6
7
8

<?php
/**
 * @file
 * Render the main content block.
 *
 * We don't print all kinds of wrapper divs and titles, just the content.
 */
print $content;

Short and sweet :)

With database-level foreign keys, it becomes impossible to break your data by deleting data referenced by other data, without also dealing with the referenced data.

In practice this means that deleting a node from the database could be as simple as DELETE FROM node WHERE nid = 53 CASCADE, and conversely it would not be allowed to delete the row from the node table, as long as it is referenced in node_revision, field_something_something and the umpteen other tables a Drupal site is likely to have that depends on the node table.

Currently, it’s neigh-impossible to delete a node or another entity from the database without using Drupal’s API. This is a sticky problem if you ever need to share the database between systems.

In Drupal 7, the syntax to define foreign keys were introduced to Drupal’s schema API. The schema API is used to explain the database structure to Drupal, so it can be understood and utilised by modules like Views. This understanding is also translated into SQL code, when tables are created by Drupal’s install scripts.

However, the foreign key syntax introduced in Drupal 7 does not affect the database structure at all, it is only used inside Drupal for relating one table to another. Perhaps in time, Drupal will also create the foreign keys at the database level, but until that happens, you will need to create them manually. Here’s how to do it.

An example

In the following example, I define two tables, and then use hook_install and hook_uninstall to set up and dismantle the foreign keys.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

<?php
/**
 * @file
 * Installation and upgrade code for Zavod supplier.
 */

/**
 * Implements hook_schema().
 */
function zavod_supplier_schema() {
  $schema = array();

  $schema['zavod_suppliers'] = array(
    'description' => 'Stock suppliers for Zavod.',
    'fields' => array(
      'supplier_id' => array(
        'description' => 'The primary identifier for a supplier.',
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ),
      'title' => array(
        'description' => 'The title of this supplier, always treated as non-markup plain text.',
        'type' => 'text',
        'not null' => TRUE,
      ),
    ),
    'primary key' => array('supplier_id'),
  );

  $schema['zavod_supply_orders'] = array(
    'description' => 'Supply orders for Zavod.',
    'fields' => array(
      'order_id' => array(
        'description' => 'The primary identifier for a supply order.',
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ),
      'supplier_id' => array(
        'description' => '{zavod_suppliers}.supplier_id of the supplier that the order is made to.',
        'type' => 'int',
        'not null' => TRUE,
        'unsigned' => TRUE,
      ),
      'title' => array(
        'description' => 'The title of this order, always treated as non-markup plain text.',
        'type' => 'text',
        'not null' => TRUE,
      ),
    ),
    'foreign keys' => array(
      'zavod_suppliers' => array(
        'table' => 'zavod_suppliers',
        'columns' => array('supplier_id' => 'supplier_id'),
      ),
    ),
    'primary key' => array('order_id'),
  );

  return $schema;
}

/**
 * Implements hook_install().
 */
function zavod_supplier_install() {
  // Make real foreign keys.
  db_query('
    ALTER TABLE {zavod_supply_orders}
    ADD CONSTRAINT {zavod_suppliers}
    FOREIGN KEY (supplier_id) REFERENCES {zavod_suppliers} (supplier_id)
  ');
}

/**
 * Implements hook_uninstall().
 */
function zavod_supplier_uninstall() {
  // Make real foreign keys.
  db_query('
    ALTER TABLE {zavod_supply_orders}
    DROP CONSTRAINT IF EXISTS {zavod_suppliers}
  ');
}

It’s pretty self-explanatory if you’re used to Drupal’s schema API. If you’re not, you should definitely learn.

There are two widely published ways to accomplish that. One is to set up completely separate Solr instances with whatever Java-server you’re using. That is somewhat inefficient, and I was unable to get such a setup working properly anyways. So here’s the alternative, “multi core”.

The benefit of using multi core is that you avoid most of the configuration overhead associated with figuring out how to get multiple WebAppContainerDeploymentContextFactoryGeneratorWidgetClass instances (or whatever they’re named in your brand of Java-server) to coexist by using the same WAR-file but not the same configuration. I spent a lot of hours trying to accomplish just that.

Instead, all the interesting stuff happens in the Solr configuration, which is a lot less confusing for a Java novice like me.

Instructions

1. Install a Java JRE.

   You may want to see my explanation on how to do this.

2. Install Jetty and Solr.

   If you use portmaster, this can be as simple as running portmaster www/jetty textproc/apache-solr

3. Create a folder for your Solr multi core instance’s configuration and data files. This could be anywhere, but in this example, I’m going to use /srv/solr.

4. Create a /srv/solr/solr.xml file for the configuration, setting up the different cores into folders.

   Mine looks like this:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   <?xml version="1.0" encoding="UTF-8" ?> <!— All (relative) paths are relative to the installation path persistent: Save changes made via the API to this file sharedLib: path to a lib directory that will be shared across all cores —> <solr persistent="false"> <!— adminPath: RequestHandler path to manage cores. If 'null' (or absent), cores will not be manageable via request handler —> <cores adminPath="/admin/cores" sharedLib="lib"> <core name="dev" instanceDir="dev" /> <core name="prod" instanceDir="prod" /> <core name="stg" instanceDir="stg" /> </cores> </solr>

5. Create all the folders referenced in the config file.

   We specified four folders, so lets create them via a simple mkdir dev lib prod stg (while standing in the /srv/solr folder).

6. Make these folders owned by the user that will run our Solr instances. In this example, I’ll use the www account, but it would be more secure to set up a separate account for running Solr if you have other web servers running on the same machine.

   chown www:www dev lib prod stg

7. For each core you want to set up, copy or symlink the schema and other configuration files you need into the conf folder in each core folder. In this example, I’m copying the example configuration from /usr/local/share/examples/apache-solr/solr/conf/. If you’re working with Drupal, be sure to copy the solr configuration it ships with into each core.

   mkdir prod/conf
cd prod/conf
cp -r /usr/local/share/examples/apache-solr/solr/conf/* ./
cd ../.. cp -r prod/conf dev/ cp -r prod/conf stg/

8. Enable Jetty

   In this example, we’re going to use Jetty to run the Solr service. I am not well versed in the Java lingo for this, but Jetty is a servlet container, so I guess that means Solr is being run as a servlet. I also tried this with Tomcat, but that was a lot harder to configure properly.

   Add jetty_enable="YES" on a new line in /etc/rc.conf.

9. Copy /usr/local/jetty/etc/jetty.xml to /usr/local/etc.

10. Symlink solr.war into /usr/local/jetty/webapps

cd /usr/local/jetty/webapps
ln -s /usr/local/share/java/classes/apache-solr-3.2.0.war solr.war

1. Symlink /srv/solr into /usr/local/jetty

cd /usr/local/jetty ln -s /srv/solr

1. Start Jetty by running service jetty start

Hopefully, after all this work, Solr should be ready once its done booting up.

You can check that it’s working by running curl -iL localhost:8080/solr/prod/admin/. This should output the HTML for the admin interface.

If you have problems, try running tail -f /usr/local/jetty/jetty.log in one terminal, and then service jetty restart in another, and look what goes on as Jetty restart (there’ll be a lot of messages flying by, but the error should be in there somewhere).

I am not a big delicious user anymore (actually, I deleted my account when Microsoft was trying to purchase Yahoo!), but this recent closing made me wonder if the Drupal community couldn’t do better…

One of the great strengths of Drupal is self-hosting, and a bookmarking service is not a complicated thing.

Thus, I am planning to put in a bit of effort into having my own bookmarks section here on this very site. A bookmark content type should not take long to configure with the Links module, Automatic Nodetitles to make sure the nodes have the same title as the link itself, and a bit of Views work should make it presentable.

Workflow

The main issue here is workflow. Nowadays, I use Google Reader’s sharing interface for “bookmarking” links, since it has a nice interface for tagging, putting notes on there, etc.

So what’s really missing in my workflow is some way of getting that data into Drupal, and since Google provides a very tasty atom feed with lots of metadata for all my shared entries, it should be doable with a bit of add-on code for the Feeds module.

What to do?

The main thing I would like to know here is if other Drupallers would be interestered in such a thing, and if anyone has input as to how it best could be built? I suppose a Features module could be in order, but I have not seen a whole lot of those published on Drupal.org. Is it wise?

And where to put my Google Reader for Feeds module integration? I suppose I could make a separate project for that on d.o, but that seems a bit overkill-like. Any takers?

However, since that has all been resolved now, I figured it was about time I moved my blog over. I have obviously been preparing for this for some time, as I will get back to in later blog posts.

However, I would once again like to encourage fellow developers to experiment with Drupal 7. The process of building a real, public-facing website with Drupal 7 so soon in the process have taught me a lot of Drupals innards, and helped me uncover a fair number of bugs in Drupal core and contributed modules that have since been fixed.

As you can also see in the 7.0 beta 1 accouncement, there is a lot to be exited about, and as we have entered the beta-phase, upgrades will be supported from now on, so the site you create with beta 1 should be upgradable all the way to the final release.

So if you can spare the time to fiddle with it, I highly recommend it. It is an educative challenge – enjoy :)

Mozilla has a good blog post explaining HSTS, so I won’t try to replicate that here, but I’d just like to make it clear that if you have a site that should always use SSL, be it Drupal or Django or any other system, this is definitely something you should get set up.

Good examples of these are webmail, server administration and monitoring tools and general admin backends. If you are running a large Drupal-site, you should perhaps consider restricting admin-access to a SSL-protected subdomain.

Currently, it is only supported in Chrome 4 and above, and Firefox 4 beta 5 and beyond, but hopefully the other browser makers will catch up soon. Its fully backwards compatible, in that it will have no effect if the browser does not support HSTS.

How to use it

Setting it up is very simple. In your Apache VHost, where you do your SSL config, just add this line:

1

Header add Strict-Transport-Security "max-age=15768000"

This will tell the browser to remember that this site is SSL/HTTPS only for the next 6 months. During that time it will simply rewrite any and all requests to that site to use HTTPS instead of HTTP without ever communicating insecurely with the server.

If you use nginx, the syntax is subtly different. Adding this to the server section does the trick:

1

add_header Strict-Transport-Security max-age=15768000;

Keep your redirects

An important point is that HSTS only works after the user has received the header via HTTPS. So you will still need to have a redirect from your HTTP-site to HTTPS, also for supporting browsers that still do not understand HSTS.

This is easily accomplished using Apache’s mod_rewrite:

1
2
3
4
5

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

Thus, with a few lines of configuration, you can make the web a safer place to be for your users. So, what are you waiting for?

Aug  8 18:41:05 s002 postgres[90076]: [5-1] WARNING:  nonstandard use of \\ in a string literal at character 32
Aug  8 18:41:05 s002 postgres[90076]: [5-2] HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
Aug  8 18:41:05 s002 postgres[90076]: [6-1] WARNING:  nonstandard use of \\ in a string literal at character 122
Aug  8 18:41:05 s002 postgres[90076]: [6-2] HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.

The immediate cause for this is bug #426008 in Drupal core, but the issue stems from the fact that PostgreSQL does not conform exactly to the SQL standard with regards to backslashes in strings. The reasoning behind this and why its going away (as a default setting) in PostgreSQL 9.1 can be read in this excellent blog post by Bruce Momjian.

But how do I fix it?

The good news is that this behavior is configurable. You can set standard_conforming_strings = on in your postgresql.conf and be done with it. This will be the default setting from PostgreSQL 9.1, and hopefully the other applications using your database do not depend on the legacy behavior (if they do, they need fixing).

If that’s not suitable for your setup, there is a few other suggestions in this forum thread.

The problem is that CVS outputs dates in RCS tags in the somewhat nonstandard format 2009/10/19 (ISO 8601 specifies dashes, not slashes as separator). The git-cvsimport tool used for creating the mirrors, however, uses cvsps, that updates the RCS tags to use the correct format (2009-10-19). Adhering to standards is generally a good thing, but in this case it was causing merge conflicts when trying to merge patches created with Git into Drupal (or vice versa).

Damien found a way to resolve the issue, however:

Adding DateFormat=old to the CVSROOT/config file fixes the problem.

Changing this, however, required a reimport of the entire repository. Due to the way Git works with commit-ids being a cryptographic hash of their contents, changing the contents (even if just the RCS tags) means a rewrite of Git history.

So while the new repository contains the same code, you will not be able to merge new changes from it into your current checkouts. Damien will continue both imports for a while, but updates for the old repository with the incompatible date format will be discontinued at a future date.

What is the bottom line then?

The executive summary

1. The Git mirror at git://github.com/drupal/drupal.git has been rewritten with it’s RCS tag date format compatible with CVS defaults. Please use this mirror for all your future projects.
2. The Git mirror at git://github.com/mikl/drupal.git will continue to have the CVS-incompatible format, and will, for a time, continue to be updated, so you will be able to use it for a little while longer.
3. There is now no excuse for not using Git for your Drupal core development work. Enjoy.

Finally, I’d like to thank Damien for doing all the hard work. I was maintaining the git-cvsimport process myself for a while, and I do not miss it.