TODO list: Eventual Version Control migration for drupal.org

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Posted by hunmonk on January 10, 2008 at 5:14pm
Last updated by dww on Mon, 2011-06-27 22:05

This is a loose checklist of items that need to be taken care of to get Version Control API working on drupal.org. The bulk of the required work has been done, and the current plan is to get the 6.x-1.x branch deployed on drupal.org before the d.o redesign is done.

Script for migrating from cvs.module to versioncontrol_cvs -- partially done
~~http://drupal.org/node/346362 -- Print warning message after branch creation to update workspace (port over from cvs.module)~~ -- done
~~http://drupal.org/node/339981 -- Prevent clobbering of CVSROOT/passwd file when a database error happens (port over from cvs.module)~~ -- done
~~http://drupal.org/node/216371 -- Move item handling and commit branches into the API module~~ -- done
~~http://drupal.org/node/209402 -- add legacy 'cvs' menu path, to prevent link rot~~ -- done
~~http://drupal.org/node/364085 -- Finish the D6 port for versioncontrol_project~~ -- done
~~http://drupal.org/node/363883 -- Keep track of nids for operations in the db~~ -- done
~~http://drupal.org/node/216373 -- Provide direct hook access to the commit retrieval query~~ -- done
Script for migrating from cvs.module to versioncontrol_project -- done, but could use more testing and needs to be adapted to http://drupal.org/node/363883
http://drupal.org/node/229350 -- Extend the CVS backend so that it supports the optional API function get_directory_contents(), so the release node integration can determine whether or not to package files of a specific branch or tag. -- done
~~http://drupal.org/node/354564 -- Implement versioncontrol_cvs_get_parallel_items(), as a precondition for branch/tag selection on the release node form.~~ -- done
Release node integration, part 1: 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. Preferably in a VCS-agnostic way, but if we can replace cvs.module sooner then a few hardcoded CVS dependencies should be no problem - we can always abstract out more stuff later. -- done
Release node integration, part 2: Port the package release scripts to use the new infrastructure. Will involve using a new versioncontrol_export_directory() (http://drupal.org/node/381540) function that allows to extract directory contents from a VCS that supports this. -- done
Script for migrating from cvs.module to release node conversion
Install CVS dummy repo at http://project.drupal.org
Full test install on p.d.o

Comments

URL rewrites?

Posted by dww on January 11, 2008 at 4:22pm

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?

hm...

Posted by jpetso on January 13, 2008 at 2:16am

Sounds pretty reasonable, even if I'd like a "Legacy cvs.module paths for Version Control API" module even better :D

done

Posted by jpetso on January 5, 2009 at 3:09pm

There's now a module called 'versioncontrol_cvslog_compat' in versioncontrol_cvs/legacy, implementing the paths on top of Commit Log which has grown more reusable in 5.x-2.x. Hope you like it, if not, oh well.

I can't edit that page,

Posted by jpetso on January 13, 2008 at 1:21am

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.

More stuff

Posted by jpetso on January 13, 2008 at 2:13am

~~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.

Even more stuff

Posted by jpetso on January 31, 2008 at 6:21pm

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

have no ph33r

Posted by jpetso on January 31, 2008 at 6:26pm

Note that none of these issues is expected to change the public API (only one added API function), so the only cause of #1a, #1b and #2 will be yet another change of the table structure. We're getting there, though, this will be cleaner and remove the performance bottleneck that we would experience with the current state of the module. (So, I'm not doing this because I like shifting table structures so much.)

I'm probably off for skiing holidays now, see you in 10 days or so.

Just curious - is this list

Posted by moshe weitzman on January 24, 2009 at 3:01pm

Just curious - is this list still up to date? Any new items to add? I think the core committers are up for converting core to use git and offer git-cvsserver for anon cvs access to core.

positive

Posted by jpetso on January 24, 2009 at 4:23pm

Yup, up to date. Sorry that it's still not yet ready for d.o, any help with those issues is appreciated.

now also complete

Posted by jpetso on January 25, 2009 at 11:39am

I've added a few items that I always understood to be necessary implicitly, but it's probably a good thing if they are specced out for the public. Issues are up for grabs! Most of them are small, well-contained and easy, but of course there's also challenges for the ambitious in there.

Update?

Posted by damienmckenna on March 12, 2009 at 12:07am

Any chance of posting an update, especially given d.o's recent successful migration to D6? Potential helpers are eager to know! Thanks :)

sure

Posted by jpetso on March 14, 2009 at 10:20pm

Actually I did keep the list of issues pretty much updated, just the "postponed for D6" header is kinda obsolete by now. So that's now removed.

hunmonk pledged to finish up the conversion scripts that he started, and I'm working on the last features that are required for the d.o deployment, so I guess there's little coding work left for the actual d.o todo list. From the issues in this list, you might try http://drupal.org/node/339981 (bullet point #3) as that one's nicely independent from the others and I'd only go at it when all my other stuff is done. (Maybe hunmonk would also be happy to hand off the conversion scripts to motivated new contributors, that might very well speed up the deployment process :-] )

For developers wanting to contribute to Version Control API in general, you might also have a look at the SoC 2009 ideas list for larger undertakings, or try to solve unassigned issues in the various versioncontrol_* issue queues (e.g. http://drupal.org/node/328035 would make for a great introductory & useful issue, I think).

Issue tag?

Posted by sun.core on December 8, 2009 at 3:48pm

Could we add a special tag for this effort to all issues on d.o that need to be done? I.e. instead of updating this static list, have a more dynamic issue tag queue.

For example, just like all issues tagged with "wysiwyg" (across projects) on d.o