I usually like to keep all of my site specific changes in one place as well - makes it easy to figure out where I customized something. But recently I've come across a couple of other techniques that you might be interested in trying.
Feature specific modules: these end up being modules that are customizing certain features - so if you have a blog feature for your site and you need to form alter it, or add a new view, or what ever, you create a site_blog.module and have all the various components there. Then you can simply svn up these particular changes in the particular modules. But most recently, I've gotten introduced the wide world of actual 'features', i.e the features module, which in a couple words is just a module wrapper which can hold configuration, upgrade paths, and makes the actual features generally easier to lump together when you have a particular feature that is implemented across multiple modules. The feature itself has a .module file as well so you can do your form alters, theme registry alters, or whatever customizations you need for that particular feature. So I guess in both instances it's separating your customizations out into whatever specific functionality that particular customization effects. This may mean multiple instances of hook_form_alter(), but it's a bit more reusable with the separation. On Wed, Apr 28, 2010 at 9:42 AM, nan wich <[email protected]> wrote: > At my current location, I have developed a major site-specific module (well > over 100K). I have already split the admin, pages, and blocks out into > separate files. I have largely done this on the same model as I use for my > DO contribs. > > At any given time I may have four or five changes in place at various stages > of testing, and working on the next change. The problem is that the > powers-that-be occasionally want one change moved to production quickly. I > can't do that without potentially moving untested changes too. > > So I'm looking for ways that others get around this situation. Certainly I > can move various smaller pieces into include files; this is not a major > problem as we use eAccelerator to cache all the modules any way. Is that the > best way or only way? We do have SVN available. > > > Nancy E. Wichmann, PMP > > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, > Jr. -- ~Jerad Bitner Lead Developer and Drupal Trainer at Lullabot http://lullabot.com
