Maybe I'm missing somthing but I'm not convinced by the 'branches are
bad' argument. Is there some published documentation that says that this
is so ? I was under the impression that creating a release branch and
merging any bug fixes back in was the 'standard' way of doing things
with cvs.
From my reading of the docs they are not orthogonal. ie when you are
satisfied that the source is in a releasable state then you add the
rtags so you can always get that version at a later date. Branching
however gives you a seperate dev line which enables you to polish a
release while still
Thanks Stefan,
that kinda gels with my feeling on it. Maintaining a branch for a long
beta cycle can be painful but maintaining development thru a long beta
without branches can be even more so. If there are a bunch of patches
coming thru to go against HEAD - ie new features that wouldn't make
I've been thinking about some of the target dependency functionality,
and I was wondering what people thought about having some extra
specification of target ordering. There's a couple of types in here, so
I've broken them up. I'm interested in hearing opinions of what people
think of these.
Hi All:
I am a cvs expert and would like to referr you to the following
branching patterns assembled by Brad, et al:
http://www.cmcrossroads.com/bradapp/acme/branching/
Using these patterns, I have effectively managed projects
in the past. The ones I recommend for CVS are:
Branching Policy:
I'd just like to ask anyone submitting patches to run the following
astyle command on the sources before posting them:
astyle -j -s4 -o -a -p --convert-tabs
this will enforce most of the nant coding guidelines with regard to formatting and layout and makes the reviewer/committers job much
Actually make that:
astyle -j -s4 -o -a -p -a --convert-tabs file
the -a forces curly brackets to attach to the previous line.
Ian
I'd just like to ask anyone submitting patches to run the following
astyle command on the sources before posting them:
astyle -j -s4 -o -a -p --convert-tabs
this
