TODO list: Eventual Version Control migration for drupal.org

how do you see these rewrites happening? Seems like we want settings in each module to add menu items @ the legacy locations that redirect to the new ones, no? I don't think we want a custom hack for d.o, since anyone migrating from cvs.module will want this. Thoughts?

I can't edit that page, error message:

An illegal choice has been detected. Please contact the site administrator.

My guess is on the groups checkbox, because I'm not in the Access Control group and thus can't select that one when saving. But maybe it's something different.

add 'commit' as a valid GET arg - done, and also the issue about removing the source_revision table (which was not yet in that list).

As for release node integration stuff, the following todo items are crossing my mind:

• Determine whether the release node conversion should be done quick-and-dirty for CVS only (like is the current state of the packaging script) or if it should go all the way with proper caller/API/backend modularization. Considering that hunmonk wants this to get done as quickly as possible, I guess the reasonable thing to do is to follow the quick-and-dirty approach and leave the rest for a time when drupal.org is running on Drupal 6 already.
• Extend the CVS backend so that it supports the optional API functions get_item_branches() and get_item_tags() at least (so that a project's branches and tags can be retrieved, by directly querying CVS). For a "proper" solution we might need more hooks being implemented ("ls" aka get_directory_contents(), and probably a not-yet-existing "cvs export" like function, maybe even more), but for now we should get by with the mentioned tag/branch retrieval functions.
• Port the package release scripts to use the new infrastructure.
• Port or rethink the Form API magic that transforms the harmless file-based release page into a multi-form CVS release drupal.org specific form monster. That's the only part that's left in cvs.module and hasn't been reworked into Version Control API based code by now.

More items:

• Introduce a commit<->node association table in versioncontrol_project, as discussed on IRC. When we have this, adapt versioncontrol_project and commitlog so that it asks the API for commit numbers rather than paths.
• Depending on how well it runs by then: optimize path and branch based commit queries by letting backends alter the query, those doing stuff more efficiently than the API module can do without having detailed knowledge of the backend's table structures. Imho this screams for a query builder, we might have a closer look at depending on Views for that purpose or wait for Drupal 7. Anyways, having commit<->node associations, I don't believe that we will need this.

As expected, the GHOP backend module projects are yielding good input, so I've opened up a couple more issues that would now be the most pressing ones:

http://drupal.org/node/216371 - Major issue #1a: Move item handling into the API module
http://drupal.org/node/216401 - Major issue #1b: Move commit branches to the API module
http://drupal.org/node/216373 - Major issue #2: Direct hook access to the query (optional in case the former two are implemented)
http://drupal.org/node/216375 - Major issue #3: Port to Drupal 6