On Fri, Jun 11, 2010 at 6:29 PM, Jacob Beard <jbea...@cs.mcgill.ca> wrote: > Hi, > > Thanks for the critiques. I'm almost done with this development cycle, > and so I'll commit my changes soon to SVN. After that, I'll use > branches and standard SVN workflows to version-control my code. > <snip/>
OK. > I have a quick question about use of Apache SVN: in the places I've > worked where we've used SVN, it has been heavily discouraged to check > in broken or unfinished code. We didn't do much branching, but mostly > worked out of trunk. I think that breaking a branch is not as bad as > breaking trunk, but I wanted to check with the community: are broken, > intermediate commits to branches considered poor practice? What about > to trunk? > <snap/> Right, the patterns and conventions can change in various communities. Commons is somewhere along these lines: Trunks are generally expected to work. Its not recommended to break the trunk of a Commons Sandbox component. Breaking the trunk of a Commons Proper component with prior releases is even worse. Branches can be of various types. SVN itself attaches no semantics to the act of creating a branch (beyond a copy). The type of the branch is decided by documented intent of developer at creation time. Branches that serve as lines of development are to be treated with similar criteria as trunks. Here [1] is such an example. There is leeway for branches that are experimental in nature, when clearly marked as such. It is OK for experimental branches to be broken where the breakage may need to be introduced as part of a convenient roadmap to get from some known working state to another anticipated (presumably better, for some definition of better) working state. Such experiments may not always succeed. Here [2] is such an example of an experimental branch. The intent of the developer may be documented by using a BRANCHINFO file which I use by convention, here [3] is the corresponding example. That is to say, in the specific case of [scxml-js] and this discussion, I wouldn't worry if a branch is temporarily broken as part of some refactoring or architectural overhaul. Until such a refactoring or overhaul is completed the trunk serves as the last known working state of the code. If the refactoring is successful, the changes are merged to trunk (effectively, the branch becomes the trunk). -Rahul [1] http://svn.apache.org/repos/asf/commons/proper/digester/branches/1_X_LINE/ [2] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/BETWIXT_IO/ [3] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/BETWIXT_IO/BRANCHINFO.txt > Thanks, > > Jake > > On Tue, Jun 8, 2010 at 11:37 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: >> >> Making your code public early also saves you lots of effort because others >> can jump in and help. That sort of community is a lot of what Apache is all >> about. >> >> On Tue, Jun 8, 2010 at 8:24 AM, Rahul Akolkar <rahul.akol...@gmail.com> >> wrote: >>> >>> Also, in the last paragraph you mention waiting till you finish >>> porting more before checking into the Apache SVN -- whereas I'd >>> actually suggest that you even do all your experimentation in the >>> Apache SVN >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
