Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
We'd like to do some file re-organization in CCK to create some sub-folders and move the field modules into them instead of having all the files at the top level, but we don't want to lose the history that goes with them.
Is there a way to do this and bring the history along?
Comment | File | Size | Author |
---|---|---|---|
#34 | cck-rename.php_.txt | 3.1 KB | dww |
Comments
Comment #1
nedjoAs preparation for refactoring CCK fields for inclusion in core, we need to clean up the existing CCK structure. Currently, all modules are in a single directory. We need to move all the supporting modules (field types, etc.) into their own directories.
Derek, IIRC you managed to do this sort of restructuring for core files without losing CVS history (through running a script?). Can the same be done here?
Comment #2
yched CreditAttribution: yched commentedsubscribe :-)
Comment #3
dwwYes it's possible, but it requires shell access on cvs.d.o.
Yes, I have a script for this, but it'll still take about 1/2 hour of work, maybe a little more. The details can be found in the issue where core's files were moved.
I'm almost completely unavailable for drupal work this week, since I have a massive deadline with my day job, and I've got family visiting and a bunch of personal stuff to take care of.
Is this a burning priority? I could potentially carve out some time to work on this, but I'd need a very detailed write up of what you want moved where. Ideally, this could wait until next week, when I'd have more time to deal with it. But, either way, someone should draw up the definitive directory layout you're aiming for. Also, I assume you want this done in HEAD and the existing branches should stay organized as they are now, but that needs to be explicitly stated, too.
Cheers,
-Derek
Comment #4
KarenS CreditAttribution: KarenS commentedThis could absolutely wait, no problem. We will want the changes in HEAD only, I think, or ultimately in a 6.2 branch. We'll post more details here.
Comment #5
yched CreditAttribution: yched commentedAlso, D6-core splitted include files are named 'node.pages.inc', where ours were named 'content_admin.inc' ('_' instead of '.'). While we're moving the files around, it would be a good opportunity to switch to the newly introduced core convention.
No big deal, obviously - Derek, if that's too much overhead, we can definitely live without.
I suggest the following structure. I'm not sure we really need to have one folder per supporting module.
Karen : what do you think ?
Dww : Next week would be just great, if you have some time. Then we can branch for D6, and officially call for testers (at last...)
Comment #6
KarenS CreditAttribution: KarenS commentedMy only change would be to have separate folders for each module under 'modules' to be consistent with core, and just for clarity, but I could live with it either way.
Also, we had talked about the .tpl files all being at the top level because there was no documented way to give them a path to another location, but Views 2 has them in a templates folder, so there is an undocumented method to do that. I think that would be better since we may want to add other .tpl files, so maybe move field.tpl into a templates folder?
Comment #7
Michelle@Karen:
The docs say: "When implemented as a template, the .tpl.php file is required. It should be in the same directory as the .module file (though the 'path' directive can be used to place these templates in another directory or a sub-directory)". I wasn unable to find this "path directive" documented, though. If you find it, could you post it here or to me privately? I would like to put the .tpl files for advforum in a subdirectory as well.
Michelle
Comment #8
KarenS CreditAttribution: KarenS commentedLook at the Views 2 code and you'll see all the tpl files are in a templates directory, so it works that way in Views 2. I am still looking for the exact place where that was identified in the code. I'll have to come back to this later, though, because I have to leave for a while.
Comment #9
Michelle@Karen:
I think I figured out what the "path directive" is. If you look at http://api.drupal.org/api/function/hook_theme/6 there is an option to set the path. Unfortunately I can't test it out, yet, because I'm having other issues with my templates, but I think that's it. :)
Michelle
Comment #10
merlinofchaos CreditAttribution: merlinofchaos commentedKarenS: The 'path' directive is documented in http://api.drupal.org/?q=api/function/hook_theme/head
Comment #11
KarenS CreditAttribution: KarenS commentedSure enough, there it is :)
Thanks Earl and Michelle. Not sure how I missed it before. I think it is not documented in the handbook page, which is what I was reading, but obviously is documented in the API. We should add that to the handbook page that explains the new template system. Unfortunately, I don't have time to do that right now.
Comment #12
dwwPerhaps someone could make a wiki page in the cck group at g.d.o so that y'all can finalize a directory layout, instead of iterative revisions via more comments in here. Sure, we can do a thorough renaming if we're going to spend the time on it at all. However, I only want to do it once, so let's get very clear on exactly what everyone wants.
fwiw, i agree w/ KarenS about subdirectories for each module.
Comment #13
KarenS CreditAttribution: KarenS commentedI'll let yched post a final layout here, based on his reactions to my comments. We had talked about this previously, so the only issue is the templates folder for .tpl files, which we weren't sure we could do and whether or not to create separate folders for each module in the modules section. I'll let yched make the final call and post the layout.
Comment #14
Crell CreditAttribution: Crell commentedJust a note, the Registry follow-up to the page-split system from Drupal 6 (http://drupal.org/node/221964) determines the module that a function is associated with by the file name, $module.something.inc or $module.module. If that fails, it looks to the directory name. It's probably best to target that format now and be done with it, which I believe yched's list does. Just be careful about multiple modules living in the same directory, as they will *all* need to have the full $module.something.inc filenames to avoid being confused with each other.
Comment #15
yched CreditAttribution: yched commentedAlright, so here it is :
- content.module files stay on top level
- .inc files go in /includes
- supporting modules get their own directory, below /modules in order not to clutter the top-level dir
each folder will need its own 'translations' folder, but we'll add them later.
- theme files for content.module go under 'theme/' (currently, only content.css and field.tpl.php - more to come, we hope)
Comment #16
KarenS CreditAttribution: KarenS commentedJust bumping this to keep it visible. It should be ready to go.
Comment #17
hass CreditAttribution: hass commentedsubscribe
Comment #18
wayland76 CreditAttribution: wayland76 commentedsubscribe
Comment #19
hass CreditAttribution: hass commentedI hope dww will find some minutes finish this task... it would be very cool if cck get's ready and out... :-)
Comment #20
KarenS CreditAttribution: KarenS commentedI just removed content_pathauto.inc and added content.token.inc. Everything else stays the same as above.
Derek has renamed the file so we now have a file with the D6 name, he is still planning to re-organize the file but is not going to do it today so we can get some patches committed during the code sprint without any worry about breaking things.
Comment #21
redben CreditAttribution: redben commentedWaw everybody is waiting for CCK to go with Drupal 6...If only i could help...
Good luck guys !
Comment #22
Freso CreditAttribution: Freso commented@hass: I definitely agree. Would be good to get to play with CCK 6.x soon. :)
Comment #23
Beau Gunderson CreditAttribution: Beau Gunderson commentedsubscribe
Comment #24
KarenS CreditAttribution: KarenS commentedDerek? Do you have time to get this done?
Comment #25
KarenS CreditAttribution: KarenS commentedSince there have been a couple small file additions (content.views_convert.inc and content.token.inc) I have updated the list, just to be sure it's clear.
Comment #26
dwwCool, thanks. FYI: yes, I'm still planning to do this, and it's possible I'll have an hour this afternoon to take care of it. Sorry for the delays -- life threw a very nasty curve-ball my way and it's been hard to juggle everything as a result.
Comment #27
Beau Gunderson CreditAttribution: Beau Gunderson commentedIs there anyone else with time and access to do this so we're not placing the burden on dww when he's dealing with what sounds like a not-so-fun situation? I see dww's instructions for a previous CVS rename here:
http://drupal.org/node/73507
Comment #28
KarenS CreditAttribution: KarenS commented@dww, so sorry to add more work to you at this time, let us know if this is not going to be possible to do.
Another update, we've added more files for the new field permissions patch from Moshe, so the list is now:
Comment #29
KarenS CreditAttribution: KarenS commentedOops, we also have a new .inc file from adding diff module code, so it is:
Comment #30
hass CreditAttribution: hass commentedHow many people have CVS access to finish this task?
Comment #31
Freso CreditAttribution: Freso commented@hass: You need more than CVS access - you need access to modify the files directly in the file system.
@dww: Any updates?
Comment #32
hass CreditAttribution: hass commentedI'd like to create the POT files for all submodules and this is much easier after the restructuring... and then start translations what would take *some* time and shouldn't be done short before a release.
Comment #33
wayland76 CreditAttribution: wayland76 commented@Freso: I think he means to ask how many people have the required access -- is it only dww, or do others also have this access?
Comment #34
dwwI finally had a chance to spend some time on this.
A) I fixed the cvs_rename.pl script to do some extra steps to make the rename better. Namely, it uses cvs admin -s to mark every revision of the new name of the file dead, except for a new revision where the file is "added" back to HEAD. This way, date-based checkouts always work correctly, too. The latest copy is now available here: http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/cvs_rename
B) I wrote a script to automate the renames requested in #29 above. Ran it a few times locally and it seems to be fine. Script attached here. For future reference, if someone needs something reorganized in CVS, anyone could write a script like this (now that you have an example to start from). Only myself (and maybe killes if you can convince him to do it) can actually run this script and do the deed, but anyone could write it.
C) However, the plan from #29 doesn't agree with the filesystem in 2 ways:
C.1) content_copy.install is mentioned in the plan, but doesn't exist.
C.2) content.js is on disk, but not mentioned in the plan.
I'm just ignoring both of those, assuming that content.js should stay at the top level, and that content_copy.install is just a mistake in the plan. If either assumption is wrong, please let me know ASAP.
So, we're basically ready to go with this. All we need is to agree on a ~15 minute downtime for CVS activity for the cck directory, and I can do the deed. Some time later today (2008-04-22) PDT (GMT-700) would work for me. How about 5:30pm PDT (12:30am GMT). Does that work for everyone?
Comment #35
dwwp.s. I was planning to actually do the renames by doing the following:
1) tar the existing cck directory in the official drupal-contrib CVS repo.
2) transfer the tar to my local machine and set it up as a local CVS repo.
3) run the above script to rename everything on my local copy of the repo.
4) tar the local copy of the (now renamed) cck CVS repo directory.
5) transfer this back to cvs.d.o, and clobber the ,v files there with the renamed versions.
The reasons I plan to do it this way:
A) I don't have to disable all the access control and project/release integration that's going to be all confused.
B) The rename itself will be mostly "atomic" from the standpoint of people using cvs.d.o -- basically, the change will only take the time for a single untar command to finish, instead of the whole time the rename script is running.
C) There won't be a ton of cvs tags and commits sent out to the CVS RSS feed, etc.
So, the only "downside" of this approach is that as far as http://drupal.org/cvs or http://drupal.org/project/cvs/48429 are concerned, there won't be any record of the rename (until someone commits some stuff post-rename to change the include paths in various files to get things working again after the rename).
Any objections?
Comment #36
KarenS CreditAttribution: KarenS commentedThanks Derek! I have no objections to your plan, and I can stay out of there at 5:30 PDT (or for the rest of the night, for that matter).
You're right that there's no content_copy.install, that was a mistake.
I'm not sure of the best place for content.js, that's a new file, but it has no history so it's probably not critical to worry about moving it in a way that will bring history along.
I'm not sure yched is available this week, I'm pretty sure he's not going to be committing anything anyway, so there should be no problem with doing things this afternoon. If you don't hear from him, assume there is no problem.
Once you get this done, I'll go in and clean up the include file paths.
Comment #37
KarenS CreditAttribution: KarenS commentedDerek, there was a translation patch by hass in the queue that touched nearly every file and he emailed me to see if I could get it in before the re-org. Since I haven't see any change yet in cvs, I went ahead and committed it, so if you haven't started this task yet, be sure to pick up the latest changes first. If you've already got things ready to go offline and the patch didn't get in, don't worry about starting over, I'll add the patch back in manually afterward.
Comment #38
dwwAfter coordinating with KarenS via IRC, I just did the deed. Everything seems fine from the CVS side of things (though I've got tarball backups of the cck directory in the repo from just before and just after the rename, in case we discover any problems).
Setting this back to active and unassigning myself since now KarenS has a bunch of references and filenames that need to be fixed in the code for CCK to understand itself with the new directory layout.
Comment #39
dwwIn fact, this is no longer an infrastructure task at all ... moving this into the CCK queue.
p.s. Karen and I decided the renames from examples/* to documentation/* weren't a good idea. Those files are examples, and they're not documentation, so that change didn't make any sense.
Comment #40
KarenS CreditAttribution: KarenS commentedOK, I think I have all the renaming done for files and file paths. Be forewarned that everything will appear to be broken at first because of bad data stuck in the cache and maybe even in the $_SESSION, so clear everything!!
Comment #41
yched CreditAttribution: yched commentedRock ! Many thanks for this, derek !
Comment #42
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.