on Wed Jun 06 2007, troy d straszheim <troy-AT-resophonic.com> wrote:
in the previous thread, On Wed, Jun 06, 2007 at 08:49:14AM -0400, David Abrahams wrote:
[snip]
It depends where you're committing things. One of the best reasons for branching in a traditional version control setup is to give authors a place to check in their partially-finished (i.e. "broken") work. That _improves_ results in numerous ways. Obviously, there has to be some kind of check in the system for bad commits, but only those that a library author declares to be "good," and thus, ready for release.
Since we're talking about devel vs. stable and what the meaning of 'trunk' really is, I found Linus Torvald's google tech talk on git (which is source control for the linux kernel) to be *very* interesting (fairly entertaining as well).
I actually took the time to watch this talk. It is, as you imply, extremely enlightening.
He places a very high value on the ability to
* branch at any time * merge easily
Yeah; I get the impression that GIT even deals correctly with fragments of code moving across files. He notes that some people use GIT to solve SVN's merging deficiencies, which I find interesting.
* commit/branch/merge locally (not in the 'central' repository)
Interesting the emphasis on git's being distributed... there is no 'central repository'.
This part I have some trouble buying. In Linus' world, *his* repository is central... well, at least, it's the master from which releases are spun. In a project where we don't have a single arbiter for what goes into a release, I'm not sure we can have a master. Also, although he claims never to do backups, it's clear from Linus' talk that he has a complicated system with layers of firewalls, etc., protecting his data... which means that in a project like ours, individuals can't "play master" with the same level of reliability that Linus does. ...but I might be missing something :) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com