Walter,
> The *only* problem that drives me slightly crazy is that the svn
> generated merges aren't foolproof. It's more like 99 44/100% foolproof.
> But it typically takes only a minute or two to figure it out once in a
> while, or writing your local customizations so they are more "svn
> visible" so it's not creating a ton of extra work.
A more regular (higher frequency) merge routine will mean less work.
You can also write scripts to flag merge sections that hit sections you last updated, and to
ignore (pass-through) those merge sections that are nowhere close to your active development.
For potential functional conflicts (eg. changing codes in file A will affect file B because B uses
A), you have to rely on regression tests. A good way to do this is to always apply merges into an
"interim" branch, test it over time, debug whatever conflicts there are, and then bring that
"interim" branch back to your main branch. Think of the "interim" branch as a massive set of
changes by an indepent outsourced team (OFBiz community, in this case).
If you're adventurous, you can also try building a functional dependencies map, and use scripts to
flag merge sections that potentially hit sections in your active development, BOTH in terms of
actual physical file conflicts as well as functional conflicts. If you do develop this map, it'll
be a great documentation for OFBiz, by the way. So far, I've only relied on some search routines
to build sub-maps on-demand.
I've never tried SVK before. But looking at its merge functions (star-merge, cherry picking), it
seems very similar to some scripts I've developed. I'll try it soon.
Jonathon
Walter Vaughan wrote:
Ed Summers wrote:
I'm new to ofbiz and was wondering if I could get some feedback on how
folks typically put their code under revision control and then build
and deploy their applications. I would like to enable layering in my
code with the latest/greatest ofbiz code as it becomes
available--instead of putting the whole lot under revision control and
having to merge in changes.
A few of us ( mostly who are utilizing Opentaps add-ons AFAIK ) are
utilizing "svk". What this does allows us to do is download the daily
changes from the parent project and maintain our local customizations in
a more organized fashion.
Leon Torres ([EMAIL PROTECTED]) I believe is the expert on
it this topic for opensourcestrategies. I'd expect a few hours of
contracted training with them will have you up, running, and happy.
The *only* problem that drives me slightly crazy is that the svn
generated merges aren't foolproof. It's more like 99 44/100% foolproof.
But it typically takes only a minute or two to figure it out once in a
while, or writing your local customizations so they are more "svn
visible" so it's not creating a ton of extra work.
YMMV
==
Walter
