Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Quoting dww's original thoughts:
d.o is full of links to things like http://drupal.org/cvs?commit=356444 -- all of those links are going to break if we turn off the cvs.module. It'd be nice to have a mapping of CVS commits to Git commits during the migration (might be really hard/impossible to get this right, I'm not sure of our repo migration process itself), and then have a custom menu handler that responds to these requests and sends you off to the equivalent Git commit.
Comments
Comment #1
dwwYeah, this is going to be a bit of a mess. It's not a blocker for phase 2, but it'd be nice. Basically, VCAPI is going to have a serial ID for each Git commit. We're going to need something to walk through that table and try to find the corresponding {cvs_messages}.cid based on cvs_user, timestamp, and message. Then, we'd populate a mapping table of vcapi_op_id to cvs_commit_id. Finally, we'd have that custom menu handler that redirects from a given cvs_commit_id to the corresponding VCAPI operation...
Comment #2
sdboyer CreditAttribution: sdboyer commentedGotta do this, or bye-bye google ranking. So yeah, phase 2.
Comment #3
sdboyer CreditAttribution: sdboyer commentedThis'll probably need to be handled with a special one-off module. In any case, it's not infra's problem, so moving it to TGGM.
Comment #4
marvil07 CreditAttribution: marvil07 commentedJust to point that versioncontrol_cvs have a legacy sub-module that do that mapping.
Naturally we should need to start one compatible to our views, but I think is a good start.
Comment #5
eliza411 CreditAttribution: eliza411 commentedTagging for Git Sprint 9
Comment #6
eliza411 CreditAttribution: eliza411 commentedNot likely to be touched this sprint.
Comment #7
sdboyer CreditAttribution: sdboyer commentedLinkrot sucks, but it's not a launch blocker. We can always roll this out after launch; if we do, there'll just be a frustrating window where it doesn't work.
If we're going to do it before launch, though, then it really needs to be done soon. Really soon. End of next week soon.
Comment #8
marvil07 CreditAttribution: marvil07 commentedSounds like the place for this would be customizations, right?
Comment #9
JohnAlbinI paste those CVS commit links into issues that I fix, as it makes it easier for people following the issue to see how the project is changing.
I agree this isn't launch critical. But I would hate for all the links to this break -> http://drupal.org/cvs?commit=374186 ;-)
Comment #10
Dave ReidOh man, just realized I used CVS commit links *all* the time in issues.
Comment #11
dwwWe need 3 things, all of which will have to be handled by the same custom menu item at /cvs
A) check for $_GET['commit'] and map to the right Git commit landing page. Not sure if we have this mapping anywhere. We'll probably want need to do some offline-parsing and build a map table and just use that, instead of trying to query the {cvs_*} tables (which are still in the d.o DB, but should be dropped eventually).
B) check for arg(1) and if it's set, redirect to node/N/commits
C) if neither GET nor arg(1) are there, dump a "we moved to Git, hurray!" landing page with links to Stuff(tm).
This probably can't possibly be solved via an input filter (as I overheard talk in IRC about). We need a menu callback, plain and simple.
Still not sure if a patch for drupalorg_versioncontrol makes sense, or if we want to do the versioncontrol_cvs_legacy thing. I'd have to look much more closely at what that's doing before I could make a recommendation. But, I definitely agree we should look there before writing the mapping logic from A.
Comment #12
Dave ReidComment #13
dwwProgress on this should hopefully be aided by #1076722: Dave Reid wants a working drupal.org development site now being fixed. ;)
Comment #14
andypostAs temporary solution we can use drupalcode's feeds, for example
http://drupalcode.org/project/theme_editor.git/rss http://drupalcode.org/project/theme_editor.git/atom
Comment #15
Dave ReidI've got individual commits working. For example, a Token module commit that I've linked to in a issue comment: http://davereid.redesign.devdrupal.org/cvs?commit=505086
Comment #16
Dave ReidWas initially very confused since the 'versioncontrol_repository_git_base_url_drupalorg_gitweb_rewrite' variable was not set on the staging site. Did it accidentally not get transferred over when creating a staging site?
Comment #17
Dave ReidFor the record, this is all the functionality that we *might* have to duplicate.
I hate cvslog.module.
Comment #18
dwwRe: #15: excellent! Patch please? ;)
Re: #17: Screw that. ;) Let's start with ?commit=n and get that done (along with 11.B and 11.C). That's going to cover at least 90% of all existing cvs.module links, probably more like 99%. I'd be fine letting the rest of those links rot if the basics are working properly.
And yeah, cvs.module is terrible. I'm so very glad it's no longer enabled on d.o. ;)
Thanks for your work on this!
Cheers,
-Derek
Comment #19
Wim LeersSubscribing.
Comment #20
dwwWhenever this is finally closed (either fixed or won't fix) we should re-open #1302028: Drop legacy CVS integration tables from the DB.
I still vote that if we have the common case working, we should go with that. But, I realize there's probably dwindling concern about this linkrot...
Comment #21
marvil07 CreditAttribution: marvil07 commentedA lot of time has passed, and linkrot kind of happened.
Do we still want to add this or just close it?
Comment #22
dww