Run CVS move script for OG HEAD

yes. would be great if you write the cvs script like dww posted in the cck reorg issue.

please customize that one that dww wrote. we can't use it as is. i have not looked at it though.

Here is the rename script based on the one used for CCK. I would appreciate if dww or killes could review it on a test repos since I don't really know how to test it. If it looks good, feel free to just run it on cvs.drupal.org.

Oh, for fucks sake. I used the Preview button instead of the Attach button and still no file. I have posted the script to http://www.tejasa.com/og_move.php.txt

Lets put this in the infrastructure queue. Hopefully killes can run the script since dww has been non responsive via private email. Again, the script is at http://www.tejasa.com/og_move.php.txt

I should have access to do this. Should any text be filled in after '#254655:'? Does anyone want to jump into #drupal-infrastructure to be around in case something goes wrong?

@moshe: (for your review):

a) I ran this against a copy of the OG repo directory on my local machine. After I did, I was left with an empty og_notifications directory in the root. Are there supposed to be any files in there? Looks like those files have never been merged/committed to HEAD. Shouldn't that all get moved to /modules? If so, you should commit/merge to HEAD, then add cvs_rename calls for those to the script, too.

b) Are /user-multiple.png and /opml.gif really the right places for those files?

c) Are these typos or intentionally weird file extension changes?

`$cvs_rename node-og-group-post.tpl.php theme/node-og-group-post.tpl.php.tpl.php`;
`$cvs_rename node-og-group.tpl.php theme/node-og-group.tpl.php.tpl.php`;
`$cvs_rename og-mission.tpl.php theme/og-mission.tpl.php.tpl.php`;

d) what's up with includes/group* ? why not includes/og.*.inc instead? Just curious -- there might be a good reason to keep them, but they look a little out of place.

e) Do you have a patch to deal with all the changes to the code necessary after the rename, or are you just going to go in and fix stuff after the fact? It'd be nice to do the rename and commit the fixes as close to each other as possible to minimize the time that HEAD is intentionally broken.

f) Anything else you want to rename/reorg while you've got the chance? ;)

p.s. The issue attachments problem was resolved: #267884: Attachments failing when users preview or use "attach" button
Feel free to attach the new copy of your script here. ;)

@drumm: Thanks for offering to take this on. If Moshe replies and we get this sorted out before Thursday morning (2008-07-10), I'll take care of it. Otherwise, I'm gone again until 2008-07-20, so if Moshe can't wait until after that, feel free to give this a go. It'd probably be nice if someone other than me was familiar with this process, at least as long as versioncontrol_api isn't ready for prime time and we're not using git. ;)

Before you run the script, I recommend making a tarball of the entire og directory in the repo, so that you can easily revert if something goes wrong. In fact, I recommend copying said tarball to your local machine, making a dummy test repo with it, and running this locally to make sure things are cool without messing with the live data in the repo. Also, before you run it, make sure the paths in the top of the script are correct (e.g. you might want to checkout a fresh copy of cvs_rename.pl from contributions/tricks/cvs_rename and use the full path to that instead of relying on your PATH). You'll also need to checkout the working copy that cvs_rename.pl is using, and be sure the sticky tag in that workspace isn't set (a HEAD checkout). If you're doing a test run, be sure you check this out from your dummy repo, not the live contrib repo. ;)

To address your specific question: cvs_rename.pl already provides a CVS commit message about what you renamed. The -m just prepends something to that message (in this case, the issue link). See for example, http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/modules... and search for revision 1.127:

#218973: Renamed from nodereference.module to modules/nodereference/nodereference.module

@hass: Do you insist on being such an unhelpful jerk in every issue you participate in? Do you ever do anything except bark orders and expect other people to jump at the chance to solve your problems for you? In dozens of issues, I've never seen any evidence to the contrary. Moshe asked you twice to do a 5 minute task, and in "months" you never took him up on the offer to even try. Instead, you just waited (and complained) for Moshe, myself, or killes (all of whom have plenty of other demands on our time) to do the work for you. I hate to admit it, but I'm actually reluctant to help out here because of your behavior, but since Moshe wants this to happen, I'll do it. I've tried being mean, and I've tried being nice, and I just can't seem to find a way to get through to you. I'll try again: either start helping or please go away. Seriously.

@dww - thanks for the outstanding review. i have addressed all your suggestions and am attaching a new script. replies below:

a) i copied those files to HEAD and added them to the script.
b) those are in /images now. not part of the script.
c) fixed
d) good catch. fixed.
e) i will do that after the fact
f) nope. thanks for asking.

Removed 2 lines related to views since those i moved those manually into a new subdirectory. Still RTBC.

Did another trial run just now. Mostly looks fine. My only lingering concerns are:

G) Why are some modules in modules/ and others in the root?
/modules/og_access
/modules/og_panels
vs.
/og_actions
/og_notifications
/og_views

H) Why do og.panels*.inc live directly in /includes, instead of something like modules/og_panels/includes?

G) You are right. I have added those modules to the script. Please retest.

H) OG Panels is really not the general placeholder for panels integration. It is a specific use case where group admns manage their displays. There are othr use cases for panels and OG that have nothing to do with group admins. So, I think we can keep these in /includes.

Removed the line for og_workflow.inc and added og.rules.inc

Removed spurious line for content_crud.inc - we don't have a file by that name.

Still RTBC.

OK, updated for latest OG changes. RTBC again.

Which translation files need moving. Anyway, I am not willing to take this out of RTBC for translation files. If anyone cares to run the script now, please proceed.

@hass: You certainly have the technical ability to modify the script from #18 to handle this. Please do so if you care about the translation folders. Thanks.

@moshe: I don't blame you for not caring about the translation folders. a) None of this should be in CVS anyway -- long live the translation server and b) who really cares about the revision history of the translations enough that they can't find the history at the older location? It's not like you need to run cvs blame when you're "debugging" a faulty translation. If you just do cvs rm old/location; cvs add new/location; cvs commit -m "moved old/location to new location" you can still do "cvs log old/location" and see the old history if you need it for some obscure reason.

I just tried this again and it's missing a few important things:

`$cvs_rename og_actions/og_actions.install modules/og_actions/og_actions.install`;

`$cvs_rename og_notifications/README.txt modules/og_notifications/README.txt`;

And a bunch of views related files:

og_views
og_views/includes
og_views/includes/og_views_handler_argument_og_group_nid.inc
og_views/includes/og_views_handler_argument_og_uid_nid.inc
og_views/includes/og_views_handler_field_og_group_nids.inc
og_views/includes/og_views_handler_field_og_is_active.inc
og_views/includes/og_views_handler_field_og_is_admin.inc
og_views/includes/og_views_handler_field_og_is_manager.inc
og_views/includes/og_views_handler_field_og_managelink.inc
og_views/includes/og_views_handler_field_og_managelinkadmin.inc
og_views/includes/og_views_handler_field_og_managelinkmy.inc
og_views/includes/og_views_handler_field_og_member_count.inc
og_views/includes/og_views_handler_field_og_post_count.inc
og_views/includes/og_views_handler_field_og_post_count_new.inc
og_views/includes/og_views_handler_field_og_selective.inc
og_views/includes/og_views_handler_field_og_subscribe.inc
og_views/includes/og_views_handler_filter_og_group_nid.inc
og_views/includes/og_views_handler_filter_og_is_admin.inc
og_views/includes/og_views_handler_filter_og_picg.inc
og_views/includes/og_views_handler_filter_og_selective.inc
og_views/includes/og_views_handler_filter_og_type.inc
og_views/includes/og_views_handler_filter_og_type_all.inc
og_views/includes/og_views_plugin_argument_validate_og_group_types.inc
og_views/og_views.views_default.inc

New patch to fix all that, based on IRC conversation with moshe.

There's also a trivial shell script to just move those translation directories entirely, since they've never been tagged for a release. I don't see how 3 auto-generated .pot files are "hard work!" that are worthy of spending any time on saving, but so be it. *sigh*

Worked with Moshe in IRC, and we decided to run this. Everything is renamed/moved, and Moshe is now committing fixes to HEAD so that the new paths are used when necessary.