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?

CommentFileSizeAuthor
#34 cck-rename.php_.txt3.1 KBdww
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nedjo’s picture

Title: Reorganize files » Reorganize CCK in CVS

As 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?

yched’s picture

subscribe :-)

dww’s picture

Status: Active » Postponed (maintainer needs more info)

Yes 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

KarenS’s picture

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

yched’s picture

Also, 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.

- /includes (NEW)
  content.admin.inc (RENAMED)
  content.crud.inc (RENAMED)
  content.node_forms.inc (RENAMED)
  content.pathauto.inc (RENAMED)
  content.views.inc (RENAMED)
- /tests
  content.crud.test (RENAMED)
- /translations
- /modules (NEW)
  content_copy.*
  fieldgroup.*
  nodereference.*
  number.*
  optionwidgets.*
  text.*
  userreference.*  
content.css
content.info
content.install
content.module
DEVELOPER.txt
field.tpl.php
README.txt
UPGRADE.txt

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

KarenS’s picture

My 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?

Michelle’s picture

@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

KarenS’s picture

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

Michelle’s picture

@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

merlinofchaos’s picture

KarenS: The 'path' directive is documented in http://api.drupal.org/?q=api/function/hook_theme/head

KarenS’s picture

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

dww’s picture

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

KarenS’s picture

I'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.

Crell’s picture

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

yched’s picture

Status: Postponed (maintainer needs more info) » Active

Alright, 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)

- documentation/
    example_field.php
    simple_field.php
- includes/
    content.admin.inc
    content.crud.inc
    content.node_form.inc
    content.pathauto.inc
    content.views.inc
- modules/
  - content_copy/
       content_copy.info
       content_copy.install
       content_copy.module
  - fieldgroup/
       fieldgroup.css
       fieldgroup.info
       fieldgroup.install
       fieldgroup.module
       fieldgroup.tpl.php
  - nodereference/
       nodereference.info
       nodereference.install
       nodereference.module
  - number/
       number.info
       number.install
       number.module
  - optionwidgets/
       optionwidgets.info
       optionwidgets.install
       optionwidgets.module
  - text/
       text.info
       text.install
       text.module
  - userreference/
       userreference.info
       userreference.install
       userreference.module
- tests/
     content.crud.test
- theme/
     content.css
     field.tpl.php
- translations/
     (...)
content.info
content.install
content.module
DEVELOPER.txt
README.txt
UPGRADE.txt
KarenS’s picture

Just bumping this to keep it visible. It should be ready to go.

hass’s picture

subscribe

wayland76’s picture

subscribe

hass’s picture

I hope dww will find some minutes finish this task... it would be very cool if cck get's ready and out... :-)

KarenS’s picture

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

redben’s picture

Waw everybody is waiting for CCK to go with Drupal 6...If only i could help...
Good luck guys !

Freso’s picture

@hass: I definitely agree. Would be good to get to play with CCK 6.x soon. :)

Beau Gunderson’s picture

subscribe

KarenS’s picture

Derek? Do you have time to get this done?

KarenS’s picture

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

- documentation/
    example_field.php
    simple_field.php
- includes/
    content.admin.inc
    content.crud.inc
    content.node_form.inc
    content.token.inc
    content.views.inc
    content.views_convert.inc
- modules/
  - content_copy/
       content_copy.info
       content_copy.install
       content_copy.module
  - fieldgroup/
       fieldgroup.css
       fieldgroup.info
       fieldgroup.install
       fieldgroup.module
       fieldgroup.tpl.php
  - nodereference/
       nodereference.info
       nodereference.install
       nodereference.module
  - number/
       number.info
       number.install
       number.module
  - optionwidgets/
       optionwidgets.info
       optionwidgets.install
       optionwidgets.module
  - text/
       text.info
       text.install
       text.module
  - userreference/
       userreference.info
       userreference.install
       userreference.module
- tests/
     content.crud.test
- theme/
     content.css
     field.tpl.php
- translations/
     (...)
content.info
content.install
content.module
DEVELOPER.txt
README.txt
UPGRADE.txt
dww’s picture

Cool, 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.

Beau Gunderson’s picture

Is 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

KarenS’s picture

@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:

- documentation/
    example_field.php
    simple_field.php
- includes/
    content.admin.inc
    content.crud.inc
    content.node_form.inc
    content.token.inc
    content.views.inc
    content.views_convert.inc
- modules/
  - content_copy/
       content_copy.info
       content_copy.install
       content_copy.module
  - content_permissions/
       content_permissions.info
       content_permissions.module
  - fieldgroup/
       fieldgroup.css
       fieldgroup.info
       fieldgroup.install
       fieldgroup.module
       fieldgroup.tpl.php
  - nodereference/
       nodereference.info
       nodereference.install
       nodereference.module
  - number/
       number.info
       number.install
       number.module
  - optionwidgets/
       optionwidgets.info
       optionwidgets.install
       optionwidgets.module
  - text/
       text.info
       text.install
       text.module
  - userreference/
       userreference.info
       userreference.install
       userreference.module
- tests/
     content.crud.test
- theme/
     content.css
     field.tpl.php
- translations/
     (...)
content.info
content.install
content.module
DEVELOPER.txt
README.txt
UPGRADE.txt
KarenS’s picture

Oops, we also have a new .inc file from adding diff module code, so it is:

- documentation/
    example_field.php
    simple_field.php
- includes/
    content.admin.inc
    content.crud.inc
    content.diff.inc
    content.node_form.inc
    content.token.inc
    content.views.inc
    content.views_convert.inc
- modules/
  - content_copy/
       content_copy.info
       content_copy.install
       content_copy.module
  - content_permissions/
       content_permissions.info
       content_permissions.module
  - fieldgroup/
       fieldgroup.css
       fieldgroup.info
       fieldgroup.install
       fieldgroup.module
       fieldgroup.tpl.php
  - nodereference/
       nodereference.info
       nodereference.install
       nodereference.module
  - number/
       number.info
       number.install
       number.module
  - optionwidgets/
       optionwidgets.info
       optionwidgets.install
       optionwidgets.module
  - text/
       text.info
       text.install
       text.module
  - userreference/
       userreference.info
       userreference.install
       userreference.module
- tests/
     content.crud.test
- theme/
     content.css
     field.tpl.php
- translations/
     (...)
content.info
content.install
content.module
DEVELOPER.txt
README.txt
UPGRADE.txt
hass’s picture

How many people have CVS access to finish this task?

Freso’s picture

@hass: You need more than CVS access - you need access to modify the files directly in the file system.

@dww: Any updates?

hass’s picture

I'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.

wayland76’s picture

@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?

dww’s picture

Assigned: Unassigned » dww
Status: Active » Needs review
FileSize
3.1 KB

I 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?

dww’s picture

p.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?

KarenS’s picture

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

KarenS’s picture

Derek, 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.

dww’s picture

Assigned: dww » Unassigned
Status: Needs review » Active

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

dww’s picture

Project: Drupal.org infrastructure » Content Construction Kit (CCK)
Version: » 6.x-1.x-dev
Component: CVS » General

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

KarenS’s picture

Status: Active » Fixed

OK, 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!!

yched’s picture

Rock ! Many thanks for this, derek !

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.