I like this production/development patching system, I was also looking for
an efficient way to follow ofbiz improvements while keeping my own
modifications, great!

BTW I find some difficulties working with binary files and patches (sorry if
OT); for instance my development patch should add to my working copy the
mysql-connector-java-5.1.5-bin.jar file in the entity lib folder.

I cannot make TortoiseSVN patch command to handle this; in the patch file I
find:

Index: entity/lib/jdbc/mysql-connector-java-5.1.5-bin.jar
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

Property changes on: entity\lib\jdbc\mysql-connector-java-5.1.5-bin.jar
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Do you think this is something that can be fixed? Or should I go with a
batch file that applies the patch for the text files and than add binary
files by copying them?

Thank you,
-Bruno

2008/5/23 Adrian Crum <[EMAIL PROTECTED]>:

> The folder that contains our custom code is kept in a local SVN repository.
>
> -Adrian
>
>
> Ray Barlow wrote:
>
>> Adrian,
>>
>> When I thought through your method more and under what circumstances I
>> might adopt it I was a little unsure as to whether you do any source
>> control on your own changes other than effectively creating the patch.
>> Personally I like to have my mods committed to a source control system
>> as well so I can see history and manage change etc but wasn't sure if
>> you are doing that and how?
>>
>> I suppose as your custom app is not part of the standard SVN it could be
>> added to another local SVN server...although if you want to get the
>> product version on another machine you've got to checkout a specific
>> trunk revision that you need to document somewhere as well as apply the
>> production patch and checkout the custom app SVN which could be tagged
>> in the local SVN.
>>
>> Sorry Adrian email is rambling a bit as I think aloud. I like your idea
>> as it is certainly simper and as Jacques suggested it's good to add to
>> the list of options people can look at because it's very much an area
>> where people can choose to use a method that suits them or even
>> different for different projects.
>>
>> Thanks,
>>
>> Ray
>>
>>
>> Adrian Crum wrote:
>>
>>> Here is the system I use, for what it's worth:
>>>>>
>>>>> 1. I keep two main patch files - basic_development.patch and
>>>>> basic_production.patch. Both patch files change the OFBiz
>>>>> configuration to work with our network environment, each one using
>>>>> settings chosen for the task - development or production. Only one
>>>>> patch is used at a time.
>>>>>
>>>>> 2. I keep all of my custom development in a single folder under the
>>>>> ofbiz/applications folder. I avoid touching the trunk code at all
>>>>> costs - except for the configuration patches mentioned above.
>>>>>
>>>>> 3. To keep my local copy updated, I do an SVN revert (to reverse the
>>>>> changes made by the patch), then an SVN update, then re-apply the
>>>>> patch. My custom development folder is untouched by the SVN
>>>>> commands, because SVN doesn't "know" about the folder.
>>>>>
>>>>> This works really well and it doesn't involve any complicated
>>>>> merging - since the configuration files changed by the patches
>>>>> seldom change in the trunk.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>

Reply via email to