On 3/13/06, Werner Guttmann <[EMAIL PROTECTED]> wrote: > > I've proposed creating a branch for all of this work in order > > to protect the trunk from any of the major changes. Working > > with branches in SVN is *tremendously* easier than in CVS. > > This is what is driving the conversion from CVS -> SVN. If > > that's not a development reason, then I don't know what is. > > We all know (including myself) that working with branches is > tremendeously easy when it comes down to simple (text book) scenarios > where you create a bug fix branch, make some changes in isolation > (whilst leaving trunk more or less untouched) and the merge your changes > back to trunk. *In real life*, things are not always that easy, and > especially with the structural changes proposed by yourself, I am almost > 100% sure that it will come down to manually merging code, especially in > the context of an imminent 1.0 release. > > In real life, we will have to deal with some (hopefully not many) > regression issues after the 1.0 release. Whilst we are trying to keep > all scenarios in mind when testing before this release, some bugs will > show up, and need to be fixed. And this will necessarily happen on > trunk, whilst you plan to make (structural) changes to the code base to > adopt Castor as described by yourself. > > In other words, I'd prefer for this to happen after 1.0 release, and I'd > like to see some of those changes to be realized in such a way that they > do *not* happen in isolation on a branch, but for the benefit of the > complete project as soon as possible after the changes have been > completed and *before* you embark on implementing JAXB 2.0 > functionality. Just to avoid any confusion: I really dig the idea of > seeing Castor comply with the JAXB specification, but I'd rather not put > the quality of the imminent 1.0 release (and subsequent minor releases) > at risk by introducing those changes now (wrongly assuming that creating > a branch is sufficient for creating perfect isolation). > > We are talking about 4 weeks of delay (which in the lifetime fo an open > source project is pretty much nothing .. ;-)), and I am sure you can > easily bridge this time by familiarizing yourself with the spec, > thinking about architecture, engaging in meaningful discussion (about > e.g. what decisions to take, how to break things up, ..) and *even > bettr* helping the rest to make the 1.0 release what it is meant to be: > a high quality, thoroughly tested 1.0 release with some new > functionality and loads of bugs fixed.
I respectfully disagree that performing work in parallel by using a branch in CVS will jeopardize the quality of the 1.0 release. This would simply make use of the features available in the tools we are currently using and would only require an understanding of how CVS branches operate. Yes, hand merging will be a requirement which is almost always the case with CVS (I've experienced none of this with SVN). But I see you feel strongly about it, so I am going to find another solution so that this work doesn't have to wait for a month or more to begin. Currently, I'm exploring the idea of either just using SVK (http://svk.elixus.org/) in my own environment or creating a second module in CVS. Both have their drawbacks, but I need to be able to start working and saving my work. Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/) ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
