[consulting] Patching code on client's site, and general packaging of customizations

[Dave Cohen]

I too use subversion, and I follow the practice described in their manual 
called vendor branches: http://svnbook.red-bean.com/en/1.1/ch07s05.html

To summarize, I have a branch called drupal-4-7.  This branch contains drupal 
(and some modules I use a lot, such as devel) without any of my 
modifications.  Occasionally I will update the code in this branch, and tag 
it as drupal-4-7-2, drupal-4-7-3, drupal-4-7-4, etc...

I create a new branch for each project I work on.  So if when drupal-4-7-3 was 
the latest release I needed to start projectX, I create a branch with:

svn copy MY_REPO/drupal-4-7-x/drupal-4-7-3 MY_REPO/sites/projectX -m "creating 
projectX for clientX"

Then I make all the changes I need, add new modules etc, to projectX.

Later, after drupal-4-7-4 has come out, I may need to update the client's 
site.  After I've created my drupal-4-7-4 tag in my repository I can do this 
with (in the projectX directory):

svn merge MY_REPO/drupal-4-7-x/drupal-4-7-3 MY_REPO/drupal-4-7-x/drupal-4-7-4

Thus all the changes from 4-7-3 to 4-7-4 get made to the site I'm developing.  

It may seem like a burden at first to maintain a vendor branch, but I find it 
very worthwhile.

-Dave


On Wednesday 13 December 2006 17:41, Gary Feldman wrote:
> Here's a real beginner's (consulting) question:
>
> How do you handle cases where there's a bug that you need fixed for a
> customer long before any fix will show up in CVS?  Or there's a change
> that can't be done via a hook?
>
> Short term, you can just go ahead and make the change on the customer's
> site, but that doesn't scale.  Every time you do an update, you need to
> worry about keeping those changes.  I've been tracking my changes in a
> personal Subversion repository, but it's still not particularly
> efficient.  (Looking at some of the tools layered on top of Subversion
> is on my list of things to do.)
>
> On a more general, related note:  How do you package up customizations?
> For themes, poor man's inheritance works ok.  For hooks, a simple
> obvious approach is to create a custom module for any given client, and
> put the hooks (form alters, etc.) there.  This works, but doesn't feel
> right to me.  I have yet to do anything large enough to justify a
> dedicated module for a specific feature, so this general module turns
> into a grab bag of miscellaneous hooks.
>
> Gary
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting