On Jan 27, 2007, at 9:27 PM, Daniel Kunkel wrote:
I was just trying to use the best example I could think of. My thinking ran the lines of: There are people in production using the Si's Financial module inproduction, and I didn't think it would be possible for these people to update to the latest svn trunk during the development of the accountingmodule as there would probably be conflicts. If I'm wrong, that's great... but it's likely to cause some real trouble if an update ever caused any mistakes.
This is always a bit of a risk for things going into SVN, which is why committers need to be careful, and also check on things regularly just in case one of their changes messes something up they can fix quickly and such.
For this type of thing there are a lot of ways to develop it so that it does not conflict with another module that does similar thing. On the webapp side the URLs and webapps would be totally separate. On the logic side it is all triggered through ECA rules, and anything else done for accounting should do the same thing.
With ECA rules we simply leave them commented out (probably the whole file inclusion commented out in the ofbiz-component.xml file) until it is stable. Whenever those ECAs are enabled those who with to use the OSS financials module would simply exclude that ECA file again.
Fortunately for most parts of OFBiz there are facilities to build things and mount them on links or ECA rules or whatever that do not conflict with existing functionality.
Finally I think you and I are thinking along the same lines from Jacques original idea. The Apache Lab is really great for collaborative projects that stand apart from the svn source tree, but it's better to bring thedevelopments as close to the svn trunk as possible to ease the source conflicts.
Yes, I think we're on the same page here. That sounds like an accurate summary of that part of things.
-David
On Sat, 2007-01-27 at 20:25 -0700, David E. Jones wrote:On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:I think you may be on to something great here, however I still wonder if a branch and merge would work even better. For the fun of it, I'll take an example David mentioned a while back, a clean room accounting system. This is a large project that is likely totake a long time to develop, even in a collaborative environment, and will probably require significant testing before being dumped into svntrunk. Because it's likely to take a long time during development, a branch and merge might make more sense instead of merging and upgrading in the way Jonathan mentioned, since there are likely to be lots of conflicts that will need to be resolved over time.Why not build that, as with everything else in OFBiz, directly into the main code base? That's certainly how I would do it... The main reason to use a branch is when you need to break existing functionality and leave it broken for an extended period of time. When adding new functionality even if it is incomplete it can, and most definitely should, go right into the trunk as the work is done. -David
smime.p7s
Description: S/MIME cryptographic signature
