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

[Rob Barreca]

>
> 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
I second that this approach is valuable. It took me a little bit to wrap 
my head around it, but it's the cleanest way to track the changes in 
Drupal with your own changes.

The lazier way (what I actually do) is to just keep the CVS directory 
info in SVN as well. Since there is rarely a need to hack core in 
Drupal, I'm usually fine with doing a straight CVS update with 
TortoiseCVS every once in a while to update core and make sure to merge 
CVS updates with any essential patches that I applied before they got in 
to CVS.

Rob Roy Barreca
Founder and COO
Electronic Insight Corporation
http://www.electronicinsight.com
rob at electronicinsight.com



Dave Cohen wrote:
> 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
>>     
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20061214/d159f66a/attachment.htm