Michael Wechner wrote:
Ian Boston schrieb:
not least because committed mistakes demand fixing by the committer
and then anyone who can fix the bug. The only downside is that
occasionally trunk wont build/run and if trunk is close to production
that probably matters.
I think another downside is, that (maybe depending on the community)
in reality a proper review often doesn't happen in the case
of CTR and in the case of performance/scalability this can be very
bad, because the actual problems are often detected
at a very late stage and then it can be very hard to solve these
issues, because the code has already advanced too far.
I see the postive sides of CTR re community and progress, but I think
it requires some additional rules, guidelines
in order to make it work.
As a matter of fact, at Directory, we are using CTR since the beginning,
and we have had to define those rules. It's pretty easy :
- if it does not compile locally, don't commit
- when you commit, always try to do it in a way a simple revert restore
the previous state
- when doing some heavy refactoring, do it in a branch
- add some integration tests early in the process
- for new committers, check their commits until they are trustable
- define some code rules (syntax, comments, etc) followed by everyone.
That's pretty much it, and it work quite well considering the project
size (325 000 slocs as of today...)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
