On Sun, June 15, 2008 7:06 pm, Gabriel Sechan wrote: > > > >> Date: Sun, 15 Jun 2008 18:50:13 -0700 >> From: [EMAIL PROTECTED] >> To: [email protected] >> Subject: RE: Some articles about the social issues of version control >> >> >> On Sat, June 14, 2008 10:50 pm, Gabriel Sechan wrote: >>> 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. >> > > Sure it does. You have something you're implementing (or fixing, or > restructuring, etc) that takes a significant amount of code. You can't > check it in to the main branch, that would break it and inconvenience > others. But you don't want this big chunk of code uncommitted- what if > your hard drive crashed? Or maybe you just want to be able to save this > point in time in your work so you can revert back to it. The easiest way > to do it is to make a branch. > > As an example- I had to get a codebase to work on a new compiler. As it > turned out, this ended up with multiple small edits to almost every file. > I couldn't check it in midstream, because it was broken on all platforms > at that time. I couldn't even check it in at the end, because I hadn't > even tried to make sure the other platforms weren't broken. But I had > branched, and I could check in to the branch as needed. In fact, > branching allowed me to revert my own work once or twice, if I had been > without revision control on my work it would have been painful. > > In my experience, I'd say about 95% of all branches are due to people > implementing large features on their own branch, then integrating at the > end. > > Gabe >
Fair enough. I shouldn't respond on weekends anyway. I think my real beef is using the compiler as the primary debugging/testing tool. Developers who want to check in to the tip and then have a continuous integration build locate problems. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
