[development] Move all core modules into their own directories.

[Derek Wright]

On May 2, 2006, at 12:19 PM, Neil Drumm wrote:

> - I would do things as I usually do with CVS- mv; cvs rm; cvs add. 
> Then someone would yell at me for losing the history.

the really nice thing about the way drupal needs to rely on CVS for 
this is that there's no external dependency on the locations of these 
files that also needs to be tracked in CVS.  most software projects 
can't just rename source files without also changing a Makefile 
somewhere (for example), which makes CVS's limitations in this regard 
more of a show-stopper.  however, since there's no Makefile, and the 
core code will search for book.module in either modules/book.module or 
in modules/book/book.module, nothing needs to know when we rename these 
files (other than the humans involved).

so, you don't have to loose any history at all.  here's the (sneaky, 
don't-try-this-at-home) approach that you could use.  this requires 
shell access to the repository, so it's really something only killes or 
dries could do.

1) go into the actual repository directory for "drupal/modules"
2) mkdir book
3) cp book.module book
4) [pseudo]: foreach tag on modules/book.module {
         cvs rtag -dB $tag modules/book/book.module
     }
5) in a workspace checked out from head:
  - rm modules/book.module
  - cvs rm modules/book.module
  - cvs commit -m "moved book.module into modules/book" 
modules/book.module

obviously, you'd need to repeat these 5 steps for each module you want 
to move.  step #4 is important, so that if someone does "cvs co -r 
DRUPAL-4-7 drupal", they don't get duplicate copies of everything.  
however, it's a big potential time-sink, too.  i've got a script 
somewhere that automates this, which i could dig out, polish off, and 
give to whomever wants to do this task if you're interested in going 
this route.  i'd be happy to answer any questions about all this, if 
anyone's confused as to what i'm describing here.

> - It kinda feels like shuffling the files around for the sake of 
> shuffling. Maybe this should be coupled with something I talked with 
> Kieran about last friday, help in separate human-readable files 
> instead of PHP. The other option of course is making .install files 
> for core modules, but I think thats less doable.

yeah, i can see some good reasons to do all this, but until we've hit 
one and are actively ready to use it, i'd vote against doing the 
reshuffling just yet.  i think we can all agree there will be a flurry 
of 6.7.0 activity, and despite our best efforts, bugs.  therefore, we 
might as well keep it easy to apply patches to both branches as long as 
possible.

-derek (dww)