On Wed, 18 Oct 2006, Matthew D. Fuller wrote: > On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of > Andreas Ericsson, and lo! it spake thus: > > > > It's just that we have this one place where gitweb is installed, > > which management likes whereas devs don't have that on their laptop. > > It's also convenient to have one place to find all changes rather > > than pulling from 1-to-N different people just to have a look at > > what they've done. > > I think this just by itself lends support to: > > > The point I'm trying to make here is that the star config might be > > the most common case today because > > c) Stars work well as a mental model for humans. I really don't think that's even true. Most projects do tend to have a star-like setup, but I think that's largely due to historical tools, not mental models. For example, I used CVS professionally for too long a few years ago, and the thing I _really_ hated was exactly how it forced people who were working on "experimental stuff" to be so tightly organized around the central repository (and how they had to do things that were visible and annoying to the mainline). And I think that's where the "star-like" situation breaks down: when you have a group of people who go off to do something experimental. Suddenly the "mainline" in that case isn't the central and most important repository any more, and instead you really have another second (and third, fourth etc) "centerpoint" that another group works around. Now, what does that mean? It means that whenever you look at a big project from the outside, you tend to see a star-like thing: there's the "big common thing", and you won't even be _seeing_ the off-shoots, because they tend to be used by developers to try out new ideas etc. So it looks like a star, but it really isn't, and shouldn't be. An SCM should support the _developers_, not the users. The users don't need an SCM, they just need a place to fetch the "standard" thing (preferably with a vendor that supports them or at least makes them feel comfy). But an SCM really should support the off-shoots, because that's where the exciting stuff happens. Btw, this is also why distribution is so fundamentally important: Most of the off-shoots tend to be failures, but that is as it should be. Again, this is where SVN and CVS and other centralized models fail _miserably_. Because branches are in a centralized repository, the cost of failure is visible to all, and thus people don't like creating branches for things that don't look "obviously viable" to the people around the central repository. In contrast, in a truly distributed environmen, a failed branch is something that people don't even KNOW about. Anybody can take the kernel git tree, start his own development line (with ten other people) and try to improve it. And if it fails, I'd never even know: there is literally _zero_ cost to everybody else from failed branches. And if they succeed, they'll just say "hey, pull this, it works, and it makes Xyz go five times faster". Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html