Ok for me : +1 Bennett, Timothy (JIS - Applications) a écrit :
Summarizing SVN structure and usage suggestions by Daniel and Niclas below. I'm unclear on how the rest of the community feels about this proposal. If no objections, I'd like to move with these SVN changes. Next step after this (I believe) is "mavenizing" the current code base that Richard contributed.Comments? Felix SVN structure model: /felix /trunk /framework /std-bundles /log /cm /http ... /bundles /obr ... ... /releases /framework-0.9 /framework-1.0 /log-1.0 /cm-1.0 ... /sandbox /tbennett /erodriquez /akarasulu ... SVN usage guidelines: <quote="niclas"> Personally, I don't use tags and branches at all. Code that are released, are copied into a proper directory named "releases", and straight after made read-only. Branches are handled differently depending on whether it is an "experiment" (in which case it is just copied to my laboratory) or it is "maintenance" of released code, in which case I first copy the "release" into a temporary area, do the changes and then create a new "release" make readonly and so forth. </quote> <quote="daniel"> Also agree about the branch handling that seem to imply a very diciplined use of branching. My experience this far of having one branch for "the next generation" and one "stable branch" is that it diffuses community energy and that it takes for ever to get to the next generation of the product and that most of the original arguments for creating a branch not are fulfilled in the end. </quote>
