Breaking up a monolithic patch

[Florent Thoumie]

On Jun 8, 2005, at 12:12 PM, Loren M. Lang wrote:

> On Wed, Jun 08, 2005 at 07:16:59AM +0200, Florent Thoumie wrote:
>
>> Le Mardi 07 juin 2005 ? 12:50 -0700, Loren M. Lang a ?crit :
>>
>>> I have been working on porting Cinelerra to freebsd and I  
>>> currently have
>>> one large monolithic patch that will make cinelerra compile and  
>>> run on
>>> freebsd.  Now I am trying to figure out how to break it up.  It  
>>> looks
>>> like the simplest method would be to break it up for each file  
>>> that's
>>> modified, then I could use the existing update-patches framework to
>>> maintain it.  But I think the better solution would be to break  
>>> it up
>>> functionally, though it's harder to maintain.  I could make a  
>>> series of
>>> patches to be applied in order, where one patch would modify  
>>> cinelerra
>>> to have a customizable prefix, another would disable the linux  
>>> firewire
>>> support.  This approach would make several patches that will overlap
>>> some and touch some of the same files, but it would be more  
>>> useful in
>>> the long run.  It would be easy to see what was modified to disable
>>> firewire and figure out how to update it to use the freebsd firewire
>>> support instead of disabling it.  If I do this though, I'll probably
>>> need to spend some time making a script to help generate the patches
>>> appropriately.
>>>
>>
>>     Use Tools/scripts/splitpatch force !
>>
>
> Actually I was able to accomplish this already with the update-patches
> target, all it does it split the monolithic patch into one patch per
> file that was modified.  What I'd really like to do is patch it per
> change in functionality.  At the moment there are about 69 files  
> that I
> need to patch and splitting 1 patch into 69 doesn't help much as it's
> still just as hard to figure out what all is happening.
>
> I'd prefer to have about 6 or 7 patches as that is how many problems I
> am having to patch.  For example, I'd have one patch that fixes the
> PREFIX so it's configurable instead of hard-coded like the original  
> is.
> To fix this, I have to patch several .c and .h files, plus the a  
> couple
> of makefiles.  Another patch I'd have would disable the firewire code,
> at least until I can port it to freebsd properly.  That patch touchs
> several files as well with some overlap in the makefiles.  The problem
> is that this touches some of the same files as the first patch, but  
> that
> isn't a big problem as long at I apply them in order and create  
> them in
> reverse order.
>
> Doing this will help much more as it will be obvious what all the
> patches are for.  They'll be named by their goal, not the target  
> files.
> Also, it will be easier to send in patches to the maintainer as he  
> won't
> want the code to disable the firewire, but may accept the PREFIX  
> patch.
> Lastly, this will make it easier to audit and deal with later.  I can
> easily see what I need to do to get firewire working again as it's all
> in one place.
>
> Is there anything to help with this or should I just work on  
> developing
> my own scripts to automate this procedure.

     Try to use ${REINPLACE_CMD} in place of patches
     when you can.

     Send patches upstream so we don't have to put them
     in the ports tree.

     Not sure you will ever find a script that will read
     your mind.

-- 
Florent Thoumie
flz at xbsd.org