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 [EMAIL PROTECTED]
(303) 493-6723
----- Original Message ----- From: "BJ Freeman" <[EMAIL PROTECTED]>
To: user@ofbiz.apache.org 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
[EMAIL PROTECTED] (303) 493-6723
----- Original Message ----- From: "BJ Freeman" <[EMAIL PROTECTED]>
To: user@ofbiz.apache.org 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
