There are a few different things that click for me with git (e.g., local access = lightning fast operations for those things I want to do all the time), but I guess the single biggest win in my opinion is that the tool no longer dictates workflow within a large organization.
Whether you realize it or not, if you've got a group of a thousand developers and you say "let's keep our code in Subversion" (or ClearCase, or... etc.), you've just made a whole host of decisions about how the individual project teams are going to collaborate with one another.
Distributed version control systems let you consciously decide what the workflow will be between project teams, and this hasn't been possible before.
"Whether you realize it or not, if you've got a group of a thousand developers and you say "let's keep our code in Subversion" (or ClearCase, or... etc.), you've just made a whole host of decisions about how the individual project teams are going to collaborate with one another."
As mentioned in the article, what are these choices? What EXACTLY changes about the way teams will collaborate? This seems to be his real question...
In Windows, this [centralised] model breaks down simply
because there are far too many developers to access one
central repository. So Windows has a tree of
repositories: developers check in to the nodes, and
periodically the changes in the nodes are integrated up
one level in the hierarchy. At a different periodicity,
changes are integrated down the tree from the root to the
nodes. In Windows, the node I was working on was 4 levels
removed from the root. The periodicity of integration
decayed exponentially and unpredictably as you approached
the root so it ended up that it took between 1 and 3
months for my code to get to the root node, and some
multiple of that for it to reach the other nodes. It should
be noted too that the only common ancestor that my team,
the shell team, and the kernel team shared was the root.
With a distributed system, it would be possible to send changes directly between the two groups. You might have a problem keeping the whole Windows source code repository stored locally on your development machine though.
Whether you realize it or not, if you've got a group of a thousand developers and you say "let's keep our code in Subversion" (or ClearCase, or... etc.), you've just made a whole host of decisions about how the individual project teams are going to collaborate with one another.
Distributed version control systems let you consciously decide what the workflow will be between project teams, and this hasn't been possible before.