Niclas Hedhman wrote:
On Wednesday 24 August 2005 09:34, Brett Porter wrote:
I've found a top level trunk works just fine with interrelated but
individually release components (it just means the structure is not
the same when tagged/branched, but you are going to have the
separation if you go the other way anyway).
I totally agree with Brett. The ttb mentioned in the red-book is a
recommendation, mostly based on the only subversion-based project at the time
(i.e. subversion itself) and that it allows for a simple CVS->SVN conversion
metaphor.
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.
Ok, just to make it a little bit more explicit, I assume you mean
something like:
/felix
/trunk
/framework
/std-bundles
/log
/cm
/http
...
/bundles
/obr
...
...
/releases
/framework-0.9
/framework-1.0
/log-1.0
/cm-1.0
...
makes sense to me. Handles separate release cycles, simple, easy to
understand and no need for doing anything right now.
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.
/Daniel
