On Sat, June 14, 2008 10:50 pm, Gabriel Sechan wrote: > > > >> From: [EMAIL PROTECTED] >> (Not that CVS/perforce/etc centralized systems force anyone to do so; >> I've worked on teams that happily developed in caves using a centralized >> version control system. Of course, those programmers would also check >> in changes that would break the compile, which is worse than checking >> in buggy code.) >> > What you do in P4 is check in to your own branch if its really a problem. > Although unless the team is large, I haven't had much of a problem with > centralized version control without branches- breaks are found quickly > and you know who did it, he just has to go fix it. In the meantime, you > revert your local copy. On teams of a few dozen people it can be bad, but > on teams of 6 or so central works perfectly well, and has less overhead. > Of course, its just a special case of the n^2 communication problem- the > bigger the team, the more avenues of communication and interaction there > are to cause problems. The number of avenues is always O(n^2). Part of > why I really love small teams. > > Gabe >
One shouldn't branch because code is untested. Branch only when code shouldn't be mixed for good reasons. - different feature sets as in different releases - returning to a baseline to fix a defect in fielded code - creative noodling that may be discarded -- or sometimes show code - when internationalization is hard coded, for different languages etc etc etc But branching just because you want to check something in you don't have working yet makes little sense. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
