On 24.12.2014 17:41, Dmitriy Setrakyan wrote:
> By the way, I am not sure if the process I suggested qualifies as CTR or
> RTC. Essentially, you commit to your own branch before the review, but you
> are allowed to commit to the main release branch only after review.
The problem with such branch fragmentation is that it tends to lead to
sloppy reviews. Any developer will typically look only at their current
branch; other developers will review before the merge, but they will not
review the changes as they are coming in but as a single code bomb. It's
far easier to review changes in small increments, and it also gives
better results overall because errors tend to be caught earlier.
The policy that the mainline must remain stable (for some definition of
"stable") is a good one. But I would recommend that you try to keep as
much development on the mainline as possible, creating branches only for
long-lived feature development, which you can be reasonably sure is
going to destabilize the code for a while.
If you go with the feature-branch model, then of course you need
separate branches for stable release lines.
You may want to read parts of
http://subversion.apache.org/docs/community-guide/
to get a better idea about the proces I'm talking about.
-- Brane
