Re: [dna-dev] Version control poll

On Dec 8, 2009, at 3:37 PM, Daniel Florian wrote: > I've gotten by without using local branches so far and don't think I will all of sudden start using them just because we are made to use Git. So if that is the main reason to switch I'm not buying it. To date, we've been very much on a "feature-boxed" release mode, where our releases are determined primarily by the completion of major features. Each of our releases has focused on one or several of the JCR 1.0 features, so the times between releases has varied wildly. This has (sort of) worked to date, but need to move to a "time-boxed" release schedule that is more inline with JBoss Community best practices and more conducive to open-source projects. And because 0.7 and 1.0 will have all of the critical JCR features (except versioning, which is optional and also coming soon), we will be moving to "time-boxed" releases with 1.1. "Time-boxed" releases mean that our releases will be on a fairly regular schedule, and will include all of the features/fixes made up to that point. This means that if a feature is not ready, it will not be included in the release. And rather than remove incomplete features, we will instead be developing all features (and potentially all issues) on separate branches, and merging those changes onto the mainline release branch (and other branches) as deemed appropriate. Working with multiple branches in Git is trivial and light-weight. I can easily merge multiple branches onto my branch (e.g., pull in some fixes that people have committed on other issue branches), and yet merging my branch onto the mainline branch is again very easy even whether or not the branches I pulled in were already merged. Git does all the bookkeeping for me. Now, frankly, SVN merging scares the crap out of me because it's a PITA and very error-prone. JBoss.org is currently running version 1.4.2, which does not have support for "easier" merging, and we'd have to rely upon svnmerge.py[1] or something similar. Plus, even with the "easier" merging abilities of SVN 1.5, it still is difficult to merge a set of changes onto multiple branches (which may be required). Dan, you worked with SVN branches when working on the Eclipse plug-in - can you imagine doing that for every issue and feature? And what worries me even more is that we'd relax our dev policies and practices because of difficulties and limitations of a tool like SVN, when there are other far-superior tools readily available. So please bear this in mind. Best regards, Randall [1] http://www.orcaware.com/svn/wiki/Svnmerge.py _______________________________________________ dna-dev mailing list dna-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/dna-dev