Right now, very few people in this list have an idea of how complicated the Flex codebase in trunk is. We dont even know how to run a single test if we make a change a simple component. As a group, we are not ready to start throwing code into trunk.
I would use the name "alt-trunk" instead of "unstable" for the other branch. Every rule that applies to trunk would apply to the alt-trunk branch. Let us keep keep trunk protected for a while till we figure out how to keep "alt-trunk" stable at all times. When it is release time, we test if alt-trunk is stable. If not, we fix it till we are happy. If we cannot fix it, we identify the committer and ask them to remove the offending parts. Remember that if we do all the development in trunk, we would have to do the same thing except that it would be a much bigger problem because we dont have any place to go when we screw things up. When are happy with alt-trunk's state, we merge alt-trunk into trunk and cut a release off of trunk. Eventually we will become good at keeping 'alt-trunk' stable. At that point, we can get rid of that branch and do all the development in trunk. Thanks, Om On Wed, Aug 8, 2012 at 5:36 PM, Justin Mclean <jus...@classsoftware.com>wrote: > Hi, > > > For those using eclipse, has anyone ever tried CollabNet eclipse plugin? > > It's from the same guys that created subclipse. Their interface makes all > > this merge process smoother and can even prevent you from merging if you > > don't follow SVN best practices. > If we go with a single unstable branch we are not following SVN best > practices so no idea how/if this tool would work but if it makes merging > easier certainly worth taking a look at. > > Thanks, > Justin
