OFBiz › OFBiz - User

Best practice to merge your custom OFBiz with official weekly build

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Vedam B

Best practice to merge your custom OFBiz with official weekly build

Hi,

I wanted to customize the OFBiz version. Also, I wanted to get the latest
updates from the official weekly build and merge with my custom OFBiz.
Any one tried this, what are the problems faced?

What are the best practices to achieve this?

Regards
Vedam

BJ Freeman

Re: Best practice to merge your custom OFBiz with official weekly build

I created a separate folder and put my changes there.
if it was a service then I change the name of the service and put in my
folder.

As a note, unless you want to spend time debugging the new submissions,
and you don't need the latests and greatest, I suggest you use the branch.

http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started

Vedam B sent the following on 11/12/2007 4:14 PM:

> Hi,
>
> I wanted to customize the OFBiz version. Also, I wanted to get the latest
> updates from the official weekly build and merge with my custom OFBiz.
> Any one tried this, what are the problems faced?
>
> What are the best practices to achieve this?
>
> Regards
> Vedam
>

Vince Clark

Re: Best practice to merge your custom OFBiz with official weekly build

There is a chapter in the svn book about vendor branch management.
http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general

Probably very useful if you can afford the overhead.

Vince Clark
Global Era
The Freedom of Open Source
[hidden email]
(303) 493-6723

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
Sent: Monday, November 12, 2007 5:44:09 PM (GMT-0700) America/Denver
Subject: Re: Best practice to merge your custom OFBiz with official weekly build

I created a separate folder and put my changes there.
if it was a service then I change the name of the service and put in my
folder.

As a note, unless you want to spend time debugging the new submissions,
and you don't need the latests and greatest, I suggest you use the branch.

http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started

Vedam B sent the following on 11/12/2007 4:14 PM:

BJ Freeman

Re: Best practice to merge your custom OFBiz with official weekly build

There was some discussion before becoming a Apache incubator project
about contributions (/vendor) that is similar to the svnbook, if I
understand it correctly.
it did not meet with much acceptance.
Not sure with current man power levels it is something ofbiz wants to
take on.
also if you going to do a application, like I did, before we had the
branch, it is almost impossible to get any development done if the trunk
is continually changing and I have figure out if it is a bug created by
my coding or from some commit from the trunk.

Vince M. Clark sent the following on 11/12/2007 5:23 PM:

> There is a chapter in the svn book about vendor branch management.
> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
>
> Probably very useful if you can afford the overhead.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 12, 2007 5:44:09 PM (GMT-0700) America/Denver
> Subject: Re: Best practice to merge your custom OFBiz with official weekly build
>
> I created a separate folder and put my changes there.
> if it was a service then I change the name of the service and put in my
> folder.
>
> As a note, unless you want to spend time debugging the new submissions,
> and you don't need the latests and greatest, I suggest you use the branch.
>
> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>
>
>
> Vedam B sent the following on 11/12/2007 4:14 PM:
>> Hi,
>>
>> I wanted to customize the OFBiz version. Also, I wanted to get the latest
>> updates from the official weekly build and merge with my custom OFBiz.
>> Any one tried this, what are the problems faced?
>>
>> What are the best practices to achieve this?
>>
>> Regards
>> Vedam
>>
>

Vince Clark

Re: Best practice to merge your custom OFBiz with official weekly build

I was thinking about it the other way around. If a company or individual developer wanted to maintain their own repository and occasionally sync up with an official OfBiz branch or trunk. And they wanted to maintain a copy of the whole stack, not just an individual component. It is not always realistic to keep customizations separate.

The "vendor branch" would be a clean copy of OfBiz branch or trunk in your local repository with which you could occasionally merge. This chapter in the svn book is a bit complex so maybe I misread it.

Vince Clark
Global Era
The Freedom of Open Source
[hidden email]
(303) 493-6723

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
Sent: Monday, November 12, 2007 7:48:01 PM (GMT-0700) America/Denver
Subject: Re: Best practice to merge your custom OFBiz with official weekly build

There was some discussion before becoming a Apache incubator project
about contributions (/vendor) that is similar to the svnbook, if I
understand it correctly.
it did not meet with much acceptance.
Not sure with current man power levels it is something ofbiz wants to
take on.
also if you going to do a application, like I did, before we had the
branch, it is almost impossible to get any development done if the trunk
is continually changing and I have figure out if it is a bug created by
my coding or from some commit from the trunk.

Vince M. Clark sent the following on 11/12/2007 5:23 PM:

jonwimp

Re: Best practice to merge your custom OFBiz with official weekly build

Yes, the "vendor branch" is a clean copy. You're right.

The point is to be able to bring in "official updates" into your customized branch in a systematic
fashion. And that is to be able to identify *individual* official updates in as unit a granularity
as possible. Some change sets can be huge with many codes being interlinked, but they will almost
always contain independent sub change sets. Being able to systematically evaluate and bring in
individual independent sub change sets is crucial to successful updates to your customized branch.

And how do we get a good clean view of *individual* sub change sets? By comparing one "clean"
(untouched by ourselves) official revision with another "clean" official revision. Maintaining a
clean copy that is the "vendor branch" is a must, unless you know some other version-control
strategy I never learned in my years with CVS/SVN (let me know!).

It's not really that complex to merge in official updates into your customized branch, although
you do need to do manual (human) evaluation of each independent sub change set. I do have some
scripts to help cut down that manual evaluation task.

Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates -- Version Control
Strategies"? Will that be useful to the OFBiz community.

Jonathon

Vince M. Clark wrote:

> I was thinking about it the other way around. If a company or individual developer wanted to maintain their own repository and occasionally sync up with an official OfBiz branch or trunk. And they wanted to maintain a copy of the whole stack, not just an individual component. It is not always realistic to keep customizations separate.
>
> The "vendor branch" would be a clean copy of OfBiz branch or trunk in your local repository with which you could occasionally merge. This chapter in the svn book is a bit complex so maybe I misread it.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 12, 2007 7:48:01 PM (GMT-0700) America/Denver
> Subject: Re: Best practice to merge your custom OFBiz with official weekly build
>
> There was some discussion before becoming a Apache incubator project
> about contributions (/vendor) that is similar to the svnbook, if I
> understand it correctly.
> it did not meet with much acceptance.
> Not sure with current man power levels it is something ofbiz wants to
> take on.
> also if you going to do a application, like I did, before we had the
> branch, it is almost impossible to get any development done if the trunk
> is continually changing and I have figure out if it is a bug created by
> my coding or from some commit from the trunk.
>
>
>
>
>
> Vince M. Clark sent the following on 11/12/2007 5:23 PM:
>> There is a chapter in the svn book about vendor branch management.
>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
>>
>> Probably very useful if you can afford the overhead.
>>
>> Vince Clark
>> Global Era
>> The Freedom of Open Source
>> [hidden email]
>> (303) 493-6723
>>
>> ----- Original Message -----
>> From: "BJ Freeman" <[hidden email]>
>> To: [hidden email]
>> Sent: Monday, November 12, 2007 5:44:09 PM (GMT-0700) America/Denver
>> Subject: Re: Best practice to merge your custom OFBiz with official weekly build
>>
>> I created a separate folder and put my changes there.
>> if it was a service then I change the name of the service and put in my
>> folder.
>>
>> As a note, unless you want to spend time debugging the new submissions,
>> and you don't need the latests and greatest, I suggest you use the branch.
>>
>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>
>>
>>
>> Vedam B sent the following on 11/12/2007 4:14 PM:
>>> Hi,
>>>
>>> I wanted to customize the OFBiz version. Also, I wanted to get the latest
>>> updates from the official weekly build and merge with my custom OFBiz.
>>> Any one tried this, what are the problems faced?
>>>
>>> What are the best practices to achieve this?
>>>
>>> Regards
>>> Vedam
>>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.30/1127 - Release Date: 11/12/2007 9:19 PM

BJ Freeman

Re: Best practice to merge your custom OFBiz with official weekly build

I am a simple person
I find that keeping my code in a separate application folder lets me
dump the newest version in and not worry about overwriting my code.
and you make the human part of the individual evaluation as simple.
from my experience of 25 years of programming I have not found anyway to
have that happen.

but for some this may be the way to go.

Jonathon -- Improov sent the following on 11/12/2007 8:03 PM:

> Yes, the "vendor branch" is a clean copy. You're right.
>
> The point is to be able to bring in "official updates" into your
> customized branch in a systematic fashion. And that is to be able to
> identify *individual* official updates in as unit a granularity as
> possible. Some change sets can be huge with many codes being
> interlinked, but they will almost always contain independent sub change
> sets. Being able to systematically evaluate and bring in individual
> independent sub change sets is crucial to successful updates to your
> customized branch.
>
> And how do we get a good clean view of *individual* sub change sets? By
> comparing one "clean" (untouched by ourselves) official revision with
> another "clean" official revision. Maintaining a clean copy that is the
> "vendor branch" is a must, unless you know some other version-control
> strategy I never learned in my years with CVS/SVN (let me know!).
>
> It's not really that complex to merge in official updates into your
> customized branch, although you do need to do manual (human) evaluation
> of each independent sub change set. I do have some scripts to help cut
> down that manual evaluation task.
>
> Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates
> -- Version Control Strategies"? Will that be useful to the OFBiz community.
>
> Jonathon
>
> Vince M. Clark wrote:
>> I was thinking about it the other way around. If a company or
>> individual developer wanted to maintain their own repository and
>> occasionally sync up with an official OfBiz branch or trunk. And they
>> wanted to maintain a copy of the whole stack, not just an individual
>> component. It is not always realistic to keep customizations separate.
>> The "vendor branch" would be a clean copy of OfBiz branch or trunk in
>> your local repository with which you could occasionally merge. This
>> chapter in the svn book is a bit complex so maybe I misread it.
>> Vince Clark Global Era The Freedom of Open Source [hidden email]
>> (303) 493-6723
>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
>> To: [hidden email] Sent: Monday, November 12, 2007 7:48:01 PM
>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
>> custom OFBiz with official weekly build
>> There was some discussion before becoming a Apache incubator project
>> about contributions (/vendor) that is similar to the svnbook, if I
>> understand it correctly. it did not meet with much acceptance. Not
>> sure with current man power levels it is something ofbiz wants to take
>> on. also if you going to do a application, like I did, before we had
>> the branch, it is almost impossible to get any development done if the
>> trunk is continually changing and I have figure out if it is a bug
>> created by my coding or from some commit from the trunk.
>>
>>
>>
>>
>> Vince M. Clark sent the following on 11/12/2007 5:23 PM:
>>> There is a chapter in the svn book about vendor branch management.
>>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
>>>
>>> Probably very useful if you can afford the overhead.
>>> Vince Clark Global Era The Freedom of Open Source
>>> [hidden email] (303) 493-6723
>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
>>> To: [hidden email] Sent: Monday, November 12, 2007 5:44:09 PM
>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
>>> custom OFBiz with official weekly build
>>> I created a separate folder and put my changes there. if it was a
>>> service then I change the name of the service and put in my folder.
>>> As a note, unless you want to spend time debugging the new
>>> submissions, and you don't need the latests and greatest, I suggest
>>> you use the branch.
>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>
>>>
>>> Vedam B sent the following on 11/12/2007 4:14 PM:
>>>> Hi,
>>>> I wanted to customize the OFBiz version. Also, I wanted to get the
>>>> latest updates from the official weekly build and merge with my
>>>> custom OFBiz. Any one tried this, what are the problems faced?
>>>> What are the best practices to achieve this?
>>>> Regards Vedam
>>
>>
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database:
>> 269.15.30/1127 - Release Date: 11/12/2007 9:19 PM
>
>
>
>

Jacopo Cappellato

Re: Best practice to merge your custom OFBiz with official weekly build

In reply to this post by jonwimp

Hi Jonathon,

Jonathon -- Improov wrote:
>
> Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates
> -- Version Control Strategies"? Will that be useful to the OFBiz community.
>
> Jonathon
>

That would be great: a good starting point could be reviewing/enhancing
the existing Wiki documents:

http://docs.ofbiz.org/x/l

http://docs.ofbiz.org/x/8gI

Jacopo

jonwimp

Re: Best practice to merge your custom OFBiz with official weekly build

In reply to this post by BJ Freeman

That's a good "shotgun" method, if I understand you right.

First, you kept your customizations separate. That's great! OFBiz framework has many mechanisms
for us to "extend" many things (controller.xml, services, entities, etc), without having to
duplicate original codes nor to change original codes (much).

Next, you dump in the latest changes from official OFBiz SVN, and hope that there will be minimal
conflicts. Your step above (separate customizations) makes this hope feasible or usable.

Still, there will be conflicts every now and then. That's where human intervention comes in.

Then, there's the question of blindly dumping in risky updates into a production OFBiz
implementation. Production implementations cannot tolerate even a single hour of conflict. So,
even if we do take a mere hour to resolve all conflicts, that's still not acceptable in production
environment. Several months back, I suggested dumping risky updates into a "trial branch",
stabilizing it over a matter of days, and then merging it back into production branch.

All in all, it may sound complex, but practice makes it really intuitive. Months back, I think I
tried to use the analogy of "save-points" or snapshots. Imagine being able to go back to any
save-point in your life! That would make prototyping cheaper, and make us more agile to take risky
forays into the near unknown.

Finally, results may be better lessons than theory. You can practice maintaining forks of several
open source projects at once! It's often necessary to correct open source projects for production
use, especially for really beta ones or for barely active ones. If you can do that, the entire
open source hypermart is open to you. It's like a huge hobby shop where you get free materials to
build your remote-controlled model/toy planes or vehicles!

Did I understand you right? By the way, keeping your codes in a separate folder (OFBiz component?)
still won't insulate it from new ECAs in official OFBiz sections. I believe you asked about
gotchas for ECAs? Your codes may be minding its own business, never changing, but then gets
tripped up by a new ECA introduced into a recent OFBiz update.

It may not always be possible to totally insulate your "separate application folder" from OFBiz
changes. If it were totally separated, you would be reusing almost zero OFBiz ERP-related stuff.
Merging is still a necessary exercise, unless the official OFBiz branch takes care to maintain
backward-compatibility.

The release branch 4.0 does (or should) take care to maintain backward-compatibility.

Jonathon

BJ Freeman wrote:

> I am a simple person
> I find that keeping my code in a separate application folder lets me
> dump the newest version in and not worry about overwriting my code.
> and you make the human part of the individual evaluation as simple.
> from my experience of 25 years of programming I have not found anyway to
> have that happen.
>
> but for some this may be the way to go.
>
>
>
> Jonathon -- Improov sent the following on 11/12/2007 8:03 PM:
>> Yes, the "vendor branch" is a clean copy. You're right.
>>
>> The point is to be able to bring in "official updates" into your
>> customized branch in a systematic fashion. And that is to be able to
>> identify *individual* official updates in as unit a granularity as
>> possible. Some change sets can be huge with many codes being
>> interlinked, but they will almost always contain independent sub change
>> sets. Being able to systematically evaluate and bring in individual
>> independent sub change sets is crucial to successful updates to your
>> customized branch.
>>
>> And how do we get a good clean view of *individual* sub change sets? By
>> comparing one "clean" (untouched by ourselves) official revision with
>> another "clean" official revision. Maintaining a clean copy that is the
>> "vendor branch" is a must, unless you know some other version-control
>> strategy I never learned in my years with CVS/SVN (let me know!).
>>
>> It's not really that complex to merge in official updates into your
>> customized branch, although you do need to do manual (human) evaluation
>> of each independent sub change set. I do have some scripts to help cut
>> down that manual evaluation task.
>>
>> Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates
>> -- Version Control Strategies"? Will that be useful to the OFBiz community.
>>
>> Jonathon
>>
>> Vince M. Clark wrote:
>>> I was thinking about it the other way around. If a company or
>>> individual developer wanted to maintain their own repository and
>>> occasionally sync up with an official OfBiz branch or trunk. And they
>>> wanted to maintain a copy of the whole stack, not just an individual
>>> component. It is not always realistic to keep customizations separate.
>>> The "vendor branch" would be a clean copy of OfBiz branch or trunk in
>>> your local repository with which you could occasionally merge. This
>>> chapter in the svn book is a bit complex so maybe I misread it.
>>> Vince Clark Global Era The Freedom of Open Source [hidden email]
>>> (303) 493-6723
>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
>>> To: [hidden email] Sent: Monday, November 12, 2007 7:48:01 PM
>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
>>> custom OFBiz with official weekly build
>>> There was some discussion before becoming a Apache incubator project
>>> about contributions (/vendor) that is similar to the svnbook, if I
>>> understand it correctly. it did not meet with much acceptance. Not
>>> sure with current man power levels it is something ofbiz wants to take
>>> on. also if you going to do a application, like I did, before we had
>>> the branch, it is almost impossible to get any development done if the
>>> trunk is continually changing and I have figure out if it is a bug
>>> created by my coding or from some commit from the trunk.
>>>
>>>
>>>
>>>
>>> Vince M. Clark sent the following on 11/12/2007 5:23 PM:
>>>> There is a chapter in the svn book about vendor branch management.
>>>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
>>>>
>>>> Probably very useful if you can afford the overhead.
>>>> Vince Clark Global Era The Freedom of Open Source
>>>> [hidden email] (303) 493-6723
>>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
>>>> To: [hidden email] Sent: Monday, November 12, 2007 5:44:09 PM
>>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
>>>> custom OFBiz with official weekly build
>>>> I created a separate folder and put my changes there. if it was a
>>>> service then I change the name of the service and put in my folder.
>>>> As a note, unless you want to spend time debugging the new
>>>> submissions, and you don't need the latests and greatest, I suggest
>>>> you use the branch.
>>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>>
>>>>
>>>> Vedam B sent the following on 11/12/2007 4:14 PM:
>>>>> Hi,
>>>>> I wanted to customize the OFBiz version. Also, I wanted to get the
>>>>> latest updates from the official weekly build and merge with my
>>>>> custom OFBiz. Any one tried this, what are the problems faced?
>>>>> What are the best practices to achieve this?
>>>>> Regards Vedam
>>>
>>> ------------------------------------------------------------------------
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database:
>>> 269.15.30/1127 - Release Date: 11/12/2007 9:19 PM
>>
>>
>>
>
>

jonwimp

Re: Best practice to merge your custom OFBiz with official weekly build

In reply to this post by Jacopo Cappellato

Jacopo,

Those docs are fine. Maybe the problem (if any?) is that they are not in "plain English"? I
understand those docs just fine, though.

For eg, "Finally do a merge between ofbiz r482800, ofbiz r483333 and my working copy", really means:

"Finally, find the difference between rNew and rOld, and apply those differences into my working
copy."

So, to any concerned:

As with all newly ingested medication (new OFBiz updates merged in), complications may arise. In
case of complications or allergies, cease medication immediately, and revert to former healthy
self before medication was started. Fortunately, you can do that with SVN and software codes,
though you can't always do that in real life. :)

Then, reverse-engineer the new medication to see if any part or even all of that medication is
incompatible with your custom OFBiz. Yes, that means you will need someone who knows about that
type of medication (OFBiz know-how, in this case).

Note that we cannot assume OFBiz rNew is agreeable with your custom OFBiz, just because rOld was
agreeable. Your cutom OFBiz could have taken a new diet. Maybe soy products and potato chips would
cause incompatibilities with rNew. The OFBiz contributors cannot hope to predict whether your
custom OFBiz had ingested any new factors to cause incompatibilities with rNew. Please consult
them on a regular basis, to ensure your custom OFBiz develops compatibly with official OFBiz and
future medications.

Step 5 "resolve the conflicts" may prove to be extremely difficult if your custom OFBiz had gone
through many long years of un-monitored diet modifications. Your OFBiz would've veered terribly
off-course in that case. Regular synchronizations with official OFBiz trunk should make that step
easily. Visit your doctor for regular check-ups.

Hope that helps. If not, you need a doctor... or, OFBiz developer, rather. :)

This is really in answer to BJ, who seemed to claim that evaluation of new medication in case of
incompatibilities isn't possible or necessary(??). I think I misunderstood him again.

Jonathon

Jacopo Cappellato wrote:

> Hi Jonathon,
>
> Jonathon -- Improov wrote:
>>
>> Maybe we could write an eBook on "Keeping Up With Official OFBiz
>> Updates -- Version Control Strategies"? Will that be useful to the
>> OFBiz community.
>>
>> Jonathon
>>
>
> That would be great: a good starting point could be reviewing/enhancing
> the existing Wiki documents:
>
> http://docs.ofbiz.org/x/l
>
> http://docs.ofbiz.org/x/8gI
>
> Jacopo
>
>

BJ Freeman

Re: Best practice to merge your custom OFBiz with official weekly build

In reply to this post by jonwimp

The continual updates and addition of new stuff most certainly has been
a bane of mine.
So I am comfortable putting in the energy to work with ver 4.0 release.
Have a lot less to keep track of for changes.
Mostly bug fixes.

Since it is running in production I have a pretty good stress test.
so far we have been able to avoid any major meltdowns.

Jonathon -- Improov sent the following on 11/13/2007 1:00 AM:

> That's a good "shotgun" method, if I understand you right.
>
> First, you kept your customizations separate. That's great! OFBiz
> framework has many mechanisms for us to "extend" many things
> (controller.xml, services, entities, etc), without having to duplicate
> original codes nor to change original codes (much).
>
> Next, you dump in the latest changes from official OFBiz SVN, and hope
> that there will be minimal conflicts. Your step above (separate
> customizations) makes this hope feasible or usable.
>
> Still, there will be conflicts every now and then. That's where human
> intervention comes in.
>
> Then, there's the question of blindly dumping in risky updates into a
> production OFBiz implementation. Production implementations cannot
> tolerate even a single hour of conflict. So, even if we do take a mere
> hour to resolve all conflicts, that's still not acceptable in production
> environment. Several months back, I suggested dumping risky updates into
> a "trial branch", stabilizing it over a matter of days, and then merging
> it back into production branch.
>
> All in all, it may sound complex, but practice makes it really
> intuitive. Months back, I think I tried to use the analogy of
> "save-points" or snapshots. Imagine being able to go back to any
> save-point in your life! That would make prototyping cheaper, and make
> us more agile to take risky forays into the near unknown.
>
> Finally, results may be better lessons than theory. You can practice
> maintaining forks of several open source projects at once! It's often
> necessary to correct open source projects for production use, especially
> for really beta ones or for barely active ones. If you can do that, the
> entire open source hypermart is open to you. It's like a huge hobby shop
> where you get free materials to build your remote-controlled model/toy
> planes or vehicles!
>
> Did I understand you right? By the way, keeping your codes in a separate
> folder (OFBiz component?) still won't insulate it from new ECAs in
> official OFBiz sections. I believe you asked about gotchas for ECAs?
> Your codes may be minding its own business, never changing, but then
> gets tripped up by a new ECA introduced into a recent OFBiz update.
>
> It may not always be possible to totally insulate your "separate
> application folder" from OFBiz changes. If it were totally separated,
> you would be reusing almost zero OFBiz ERP-related stuff. Merging is
> still a necessary exercise, unless the official OFBiz branch takes care
> to maintain backward-compatibility.
>
> The release branch 4.0 does (or should) take care to maintain
> backward-compatibility.
>
> Jonathon
>
> BJ Freeman wrote:
>> I am a simple person
>> I find that keeping my code in a separate application folder lets me
>> dump the newest version in and not worry about overwriting my code.
>> and you make the human part of the individual evaluation as simple.
>> from my experience of 25 years of programming I have not found anyway to
>> have that happen.
>>
>> but for some this may be the way to go.
>>
>>
>>
>> Jonathon -- Improov sent the following on 11/12/2007 8:03 PM:
>>> Yes, the "vendor branch" is a clean copy. You're right.
>>>
>>> The point is to be able to bring in "official updates" into your
>>> customized branch in a systematic fashion. And that is to be able to
>>> identify *individual* official updates in as unit a granularity as
>>> possible. Some change sets can be huge with many codes being
>>> interlinked, but they will almost always contain independent sub change
>>> sets. Being able to systematically evaluate and bring in individual
>>> independent sub change sets is crucial to successful updates to your
>>> customized branch.
>>>
>>> And how do we get a good clean view of *individual* sub change sets? By
>>> comparing one "clean" (untouched by ourselves) official revision with
>>> another "clean" official revision. Maintaining a clean copy that is the
>>> "vendor branch" is a must, unless you know some other version-control
>>> strategy I never learned in my years with CVS/SVN (let me know!).
>>>
>>> It's not really that complex to merge in official updates into your
>>> customized branch, although you do need to do manual (human) evaluation
>>> of each independent sub change set. I do have some scripts to help cut
>>> down that manual evaluation task.
>>>
>>> Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates
>>> -- Version Control Strategies"? Will that be useful to the OFBiz
>>> community.
>>>
>>> Jonathon
>>>
>>> Vince M. Clark wrote:
>>>> I was thinking about it the other way around. If a company or
>>>> individual developer wanted to maintain their own repository and
>>>> occasionally sync up with an official OfBiz branch or trunk. And they
>>>> wanted to maintain a copy of the whole stack, not just an individual
>>>> component. It is not always realistic to keep customizations separate.
>>>> The "vendor branch" would be a clean copy of OfBiz branch or trunk in
>>>> your local repository with which you could occasionally merge. This
>>>> chapter in the svn book is a bit complex so maybe I misread it.
>>>> Vince Clark Global Era The Freedom of Open Source [hidden email]
>>>> (303) 493-6723
>>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
>>>> To: [hidden email] Sent: Monday, November 12, 2007 7:48:01 PM
>>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
>>>> custom OFBiz with official weekly build
>>>> There was some discussion before becoming a Apache incubator project
>>>> about contributions (/vendor) that is similar to the svnbook, if I
>>>> understand it correctly. it did not meet with much acceptance. Not
>>>> sure with current man power levels it is something ofbiz wants to take
>>>> on. also if you going to do a application, like I did, before we had
>>>> the branch, it is almost impossible to get any development done if the
>>>> trunk is continually changing and I have figure out if it is a bug
>>>> created by my coding or from some commit from the trunk.
>>>>
>>>>
>>>>
>>>>
>>>> Vince M. Clark sent the following on 11/12/2007 5:23 PM:
>>>>> There is a chapter in the svn book about vendor branch management.
>>>>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
>>>>>
>>>>>
>>>>> Probably very useful if you can afford the overhead.
>>>>> Vince Clark Global Era The Freedom of Open Source
>>>>> [hidden email] (303) 493-6723
>>>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
>>>>> To: [hidden email] Sent: Monday, November 12, 2007 5:44:09 PM
>>>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
>>>>> custom OFBiz with official weekly build
>>>>> I created a separate folder and put my changes there. if it was a
>>>>> service then I change the name of the service and put in my folder.
>>>>> As a note, unless you want to spend time debugging the new
>>>>> submissions, and you don't need the latests and greatest, I suggest
>>>>> you use the branch.
>>>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>>>
>>>>>
>>>>> Vedam B sent the following on 11/12/2007 4:14 PM:
>>>>>> Hi,
>>>>>> I wanted to customize the OFBiz version. Also, I wanted to get the
>>>>>> latest updates from the official weekly build and merge with my
>>>>>> custom OFBiz. Any one tried this, what are the problems faced?
>>>>>> What are the best practices to achieve this?
>>>>>> Regards Vedam
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database:
>>>> 269.15.30/1127 - Release Date: 11/12/2007 9:19 PM
>>>
>>>
>>>
>>
>>
>
>
>
>

rajsaini

Re: Best practice to merge your custom OFBiz with official weekly build

In reply to this post by Vince Clark

I use vendor branch to merge trunk with my customization. There is an
article on wiki as well. It should not be much difficult to use vendor
branch.

Thanks,

Raj

Vince M. Clark wrote:

> I was thinking about it the other way around. If a company or individual developer wanted to maintain their own repository and occasionally sync up with an official OfBiz branch or trunk. And they wanted to maintain a copy of the whole stack, not just an individual component. It is not always realistic to keep customizations separate.
>
> The "vendor branch" would be a clean copy of OfBiz branch or trunk in your local repository with which you could occasionally merge. This chapter in the svn book is a bit complex so maybe I misread it.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 12, 2007 7:48:01 PM (GMT-0700) America/Denver
> Subject: Re: Best practice to merge your custom OFBiz with official weekly build
>
> There was some discussion before becoming a Apache incubator project
> about contributions (/vendor) that is similar to the svnbook, if I
> understand it correctly.
> it did not meet with much acceptance.
> Not sure with current man power levels it is something ofbiz wants to
> take on.
> also if you going to do a application, like I did, before we had the
> branch, it is almost impossible to get any development done if the trunk
> is continually changing and I have figure out if it is a bug created by
> my coding or from some commit from the trunk.
>
>
>
>
>
> Vince M. Clark sent the following on 11/12/2007 5:23 PM:
>
>> There is a chapter in the svn book about vendor branch management.
>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
>>
>> Probably very useful if you can afford the overhead.
>>
>> Vince Clark
>> Global Era
>> The Freedom of Open Source
>> [hidden email]
>> (303) 493-6723
>>
>> ----- Original Message -----
>> From: "BJ Freeman" <[hidden email]>
>> To: [hidden email]
>> Sent: Monday, November 12, 2007 5:44:09 PM (GMT-0700) America/Denver
>> Subject: Re: Best practice to merge your custom OFBiz with official weekly build
>>
>> I created a separate folder and put my changes there.
>> if it was a service then I change the name of the service and put in my
>> folder.
>>
>> As a note, unless you want to spend time debugging the new submissions,
>> and you don't need the latests and greatest, I suggest you use the branch.
>>
>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>
>>
>>
>> Vedam B sent the following on 11/12/2007 4:14 PM:
>>
>>> Hi,
>>>
>>> I wanted to customize the OFBiz version. Also, I wanted to get the latest
>>> updates from the official weekly build and merge with my custom OFBiz.
>>> Any one tried this, what are the problems faced?
>>>
>>> What are the best practices to achieve this?
>>>
>>> Regards
>>> Vedam
>>>
>>>
>
>

Jacques Le Roux

Re: Best practice to merge your custom OFBiz with official weekly build

Administrator

In reply to this post by jonwimp

Interesting metaphor. Maybe comments in links at bottom would be easier for futur...

Anyway thanks

Jacques

De : "Jonathon -- Improov" <[hidden email]>

> Jacopo,
>
> Those docs are fine. Maybe the problem (if any?) is that they are not in "plain English"? I
> understand those docs just fine, though.
>
> For eg, "Finally do a merge between ofbiz r482800, ofbiz r483333 and my working copy", really means:
>
> "Finally, find the difference between rNew and rOld, and apply those differences into my working
> copy."
>
> So, to any concerned:
>
> As with all newly ingested medication (new OFBiz updates merged in), complications may arise. In
> case of complications or allergies, cease medication immediately, and revert to former healthy
> self before medication was started. Fortunately, you can do that with SVN and software codes,
> though you can't always do that in real life. :)
>
> Then, reverse-engineer the new medication to see if any part or even all of that medication is
> incompatible with your custom OFBiz. Yes, that means you will need someone who knows about that
> type of medication (OFBiz know-how, in this case).
>
> Note that we cannot assume OFBiz rNew is agreeable with your custom OFBiz, just because rOld was
> agreeable. Your cutom OFBiz could have taken a new diet. Maybe soy products and potato chips would
> cause incompatibilities with rNew. The OFBiz contributors cannot hope to predict whether your
> custom OFBiz had ingested any new factors to cause incompatibilities with rNew. Please consult
> them on a regular basis, to ensure your custom OFBiz develops compatibly with official OFBiz and
> future medications.
>
> Step 5 "resolve the conflicts" may prove to be extremely difficult if your custom OFBiz had gone
> through many long years of un-monitored diet modifications. Your OFBiz would've veered terribly
> off-course in that case. Regular synchronizations with official OFBiz trunk should make that step
> easily. Visit your doctor for regular check-ups.
>
> Hope that helps. If not, you need a doctor... or, OFBiz developer, rather. :)
>
> This is really in answer to BJ, who seemed to claim that evaluation of new medication in case of
> incompatibilities isn't possible or necessary(??). I think I misunderstood him again.
>
> Jonathon
>
> Jacopo Cappellato wrote:
> > Hi Jonathon,
> >
> > Jonathon -- Improov wrote:
> >>
> >> Maybe we could write an eBook on "Keeping Up With Official OFBiz
> >> Updates -- Version Control Strategies"? Will that be useful to the
> >> OFBiz community.
> >>
> >> Jonathon
> >>
> >
> > That would be great: a good starting point could be reviewing/enhancing
> > the existing Wiki documents:
> >
> > http://docs.ofbiz.org/x/l
> >
> > http://docs.ofbiz.org/x/8gI
> >
> > Jacopo
> >
> >
>

Jacques Le Roux

Re: Best practice to merge your custom OFBiz with official weekly build

Administrator

In reply to this post by BJ Freeman

De : "BJ Freeman" <[hidden email]>
> The continual updates and addition of new stuff most certainly has been
> a bane of mine.
> So I am comfortable putting in the energy to work with ver 4.0 release.
> Have a lot less to keep track of for changes.
> Mostly bug fixes.

Yes, releases should definitively help to increase community and especially business interests !

Jacques

> Since it is running in production I have a pretty good stress test.
> so far we have been able to avoid any major meltdowns.
>
>
> Jonathon -- Improov sent the following on 11/13/2007 1:00 AM:
> > That's a good "shotgun" method, if I understand you right.
> >
> > First, you kept your customizations separate. That's great! OFBiz
> > framework has many mechanisms for us to "extend" many things
> > (controller.xml, services, entities, etc), without having to duplicate
> > original codes nor to change original codes (much).
> >
> > Next, you dump in the latest changes from official OFBiz SVN, and hope
> > that there will be minimal conflicts. Your step above (separate
> > customizations) makes this hope feasible or usable.
> >
> > Still, there will be conflicts every now and then. That's where human
> > intervention comes in.
> >
> > Then, there's the question of blindly dumping in risky updates into a
> > production OFBiz implementation. Production implementations cannot
> > tolerate even a single hour of conflict. So, even if we do take a mere
> > hour to resolve all conflicts, that's still not acceptable in production
> > environment. Several months back, I suggested dumping risky updates into
> > a "trial branch", stabilizing it over a matter of days, and then merging
> > it back into production branch.
> >
> > All in all, it may sound complex, but practice makes it really
> > intuitive. Months back, I think I tried to use the analogy of
> > "save-points" or snapshots. Imagine being able to go back to any
> > save-point in your life! That would make prototyping cheaper, and make
> > us more agile to take risky forays into the near unknown.
> >
> > Finally, results may be better lessons than theory. You can practice
> > maintaining forks of several open source projects at once! It's often
> > necessary to correct open source projects for production use, especially
> > for really beta ones or for barely active ones. If you can do that, the
> > entire open source hypermart is open to you. It's like a huge hobby shop
> > where you get free materials to build your remote-controlled model/toy
> > planes or vehicles!
> >
> > Did I understand you right? By the way, keeping your codes in a separate
> > folder (OFBiz component?) still won't insulate it from new ECAs in
> > official OFBiz sections. I believe you asked about gotchas for ECAs?
> > Your codes may be minding its own business, never changing, but then
> > gets tripped up by a new ECA introduced into a recent OFBiz update.
> >
> > It may not always be possible to totally insulate your "separate
> > application folder" from OFBiz changes. If it were totally separated,
> > you would be reusing almost zero OFBiz ERP-related stuff. Merging is
> > still a necessary exercise, unless the official OFBiz branch takes care
> > to maintain backward-compatibility.
> >
> > The release branch 4.0 does (or should) take care to maintain
> > backward-compatibility.
> >
> > Jonathon
> >
> > BJ Freeman wrote:
> >> I am a simple person
> >> I find that keeping my code in a separate application folder lets me
> >> dump the newest version in and not worry about overwriting my code.
> >> and you make the human part of the individual evaluation as simple.
> >> from my experience of 25 years of programming I have not found anyway to
> >> have that happen.
> >>
> >> but for some this may be the way to go.
> >>
> >>
> >>
> >> Jonathon -- Improov sent the following on 11/12/2007 8:03 PM:
> >>> Yes, the "vendor branch" is a clean copy. You're right.
> >>>
> >>> The point is to be able to bring in "official updates" into your
> >>> customized branch in a systematic fashion. And that is to be able to
> >>> identify *individual* official updates in as unit a granularity as
> >>> possible. Some change sets can be huge with many codes being
> >>> interlinked, but they will almost always contain independent sub change
> >>> sets. Being able to systematically evaluate and bring in individual
> >>> independent sub change sets is crucial to successful updates to your
> >>> customized branch.
> >>>
> >>> And how do we get a good clean view of *individual* sub change sets? By
> >>> comparing one "clean" (untouched by ourselves) official revision with
> >>> another "clean" official revision. Maintaining a clean copy that is the
> >>> "vendor branch" is a must, unless you know some other version-control
> >>> strategy I never learned in my years with CVS/SVN (let me know!).
> >>>
> >>> It's not really that complex to merge in official updates into your
> >>> customized branch, although you do need to do manual (human) evaluation
> >>> of each independent sub change set. I do have some scripts to help cut
> >>> down that manual evaluation task.
> >>>
> >>> Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates
> >>> -- Version Control Strategies"? Will that be useful to the OFBiz
> >>> community.
> >>>
> >>> Jonathon
> >>>
> >>> Vince M. Clark wrote:
> >>>> I was thinking about it the other way around. If a company or
> >>>> individual developer wanted to maintain their own repository and
> >>>> occasionally sync up with an official OfBiz branch or trunk. And they
> >>>> wanted to maintain a copy of the whole stack, not just an individual
> >>>> component. It is not always realistic to keep customizations separate.
> >>>> The "vendor branch" would be a clean copy of OfBiz branch or trunk in
> >>>> your local repository with which you could occasionally merge. This
> >>>> chapter in the svn book is a bit complex so maybe I misread it.
> >>>> Vince Clark Global Era The Freedom of Open Source [hidden email]
> >>>> (303) 493-6723
> >>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
> >>>> To: [hidden email] Sent: Monday, November 12, 2007 7:48:01 PM
> >>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
> >>>> custom OFBiz with official weekly build
> >>>> There was some discussion before becoming a Apache incubator project
> >>>> about contributions (/vendor) that is similar to the svnbook, if I
> >>>> understand it correctly. it did not meet with much acceptance. Not
> >>>> sure with current man power levels it is something ofbiz wants to take
> >>>> on. also if you going to do a application, like I did, before we had
> >>>> the branch, it is almost impossible to get any development done if the
> >>>> trunk is continually changing and I have figure out if it is a bug
> >>>> created by my coding or from some commit from the trunk.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Vince M. Clark sent the following on 11/12/2007 5:23 PM:
> >>>>> There is a chapter in the svn book about vendor branch management.
> >>>>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
> >>>>>
> >>>>>
> >>>>> Probably very useful if you can afford the overhead.
> >>>>> Vince Clark Global Era The Freedom of Open Source
> >>>>> [hidden email] (303) 493-6723
> >>>>> ----- Original Message ----- From: "BJ Freeman" <[hidden email]>
> >>>>> To: [hidden email] Sent: Monday, November 12, 2007 5:44:09 PM
> >>>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your
> >>>>> custom OFBiz with official weekly build
> >>>>> I created a separate folder and put my changes there. if it was a
> >>>>> service then I change the name of the service and put in my folder.
> >>>>> As a note, unless you want to spend time debugging the new
> >>>>> submissions, and you don't need the latests and greatest, I suggest
> >>>>> you use the branch.
> >>>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
> >>>>>
> >>>>>
> >>>>> Vedam B sent the following on 11/12/2007 4:14 PM:
> >>>>>> Hi,
> >>>>>> I wanted to customize the OFBiz version. Also, I wanted to get the
> >>>>>> latest updates from the official weekly build and merge with my
> >>>>>> custom OFBiz. Any one tried this, what are the problems faced?
> >>>>>> What are the best practices to achieve this?
> >>>>>> Regards Vedam
> >>>>
> >>>> ------------------------------------------------------------------------
> >>>>
> >>>>
> >>>> No virus found in this incoming message.
> >>>> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database:
> >>>> 269.15.30/1127 - Release Date: 11/12/2007 9:19 PM
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
>