> Reason 1
> --------
> The checkout from trunk and build could take a while ie (10~15sec). The
> developer would have to wait a while before knowing if his changes are
> committed.
Agree, this would be my first question, how it feels in practice.
(Actualy the "checkout" would take no more than 1-2 secs, I just update
a working copy.)
> Reason 2
> --------
> The source control repository is used to store source code. So rejecting
> a commit because trunk does not build (not the fault of the current
> committer as his code is not in trunk) actually defeats the fundamental
> purpose of a source control repository.
You did not get the idea. I would test the code that the developer
wants to commit. Using this method it's sure that trunk always builds.
> Reason 3
> --------
> It could take day(s) to fix the problem in trunk. So during this period
> no one else can commit any work. I believe the risk of loosing source
> code from a developers machine is greater than a trunk that does not
> build.
I agree again, but my idea was that anybody can commit to a branch a
broken code, but trunk must build all the time. The policy would be
that if you can't fix it immediatelly (that never happened here) you
have to commit it to a branch.
Continuous integration build system is the next level. Thanks for
pointing to that, I read about them but never used and this time it did
not come to my mind. I will surely investigate that solution for my
case.
Currently we have a small code that builds quickly and is broken
frequently. Rollback is possible, but it's easier for me to force
frequent "breakers" and better for them as well, 'coz if I roll back and
commit my changes on the previous version it's not so easy for them to
get back their version (and come to me again).
WP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 18 13:02:29 2006