begin quoting Gabriel Sechan as of Sun, Jun 15, 2008 at 09:06:29PM -0500: > > 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
Can I just point out how much I dislike this sort of attribution? > > 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 Yup. I've seen that break a couple of times, mostly due to developer obnoxiousness. PhDs don't much like it when you roll back their commit with a reason of "unprofessional low-quality code breaks build". > >> 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. I've seen centralized VCS work reasonably well up to a couple of dozen developers. > > 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 Those et ceteras encompass a multitude of sins. > > 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 restruct > uri > ng, etc) that takes a significant amount of code. You can't check it in to t > he > main branch, that would break it and inconvenience others. But you don't wan That depends on how you go about reworking that code. "Let's break everything and then fix it" is what the really confident folks do, but there's a huge risk that the "fix" will be broken upon integration. Been there, done that, it's a toss-up. I've seen it work, I've seen it fail, but mostly, I've seen it turn into a half-week marathon integration effort. When it fails, it can have repercussions for months. > t t > his big chunk of code uncommitted- what if your hard drive crashed? Or mayb > e y > ou just want to be able to save this point in time in your work so you can re > ver > t back to it. The easiest way to do it is to make a branch. Yup. I'm actually tempted to put the intern's development into a branch, just to allow for a review-before-integration step. > As an example- I had to get a codebase to work on a new compiler. As it tur > ned > out, this ended up with multiple small edits to almost every file. I couldn' > t c > heck it in midstream, because it was broken on all platforms at that time. I And you didn't use a refactoring tool or unit tests, I'm guessing. > co > uldn'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 o > r t > wice, if I had been without revision control on my work it would have been pa > inf > ul. Excessive branching is still better than no version control, or the zip-up-everything-and-mail-it-to-the-team approach. > In my experience, I'd say about 95% of all branches are due to people impleme > nti > ng large features on their own branch, then integrating at the end. This is where branching seems the least useful, and where the criticism lies. Branch for releases. Branch for code forks. Branch for spike solutions (although a DVCS seems better for this). Branch to develop new features in isolation? Bleah. But then, I suppose it's a function of the size and capability of the team... half-a-dozen decent people? It would work, but then, you probably wouldn't need to. -- Time to set up a DVCS/CVCS hybrid, I think. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
