On Tue, 27 Mar 2007, Daniel Barkalow wrote: > > This is actually the case I'm personally interested in. But in that case, > you want to reverse the superproject/subproject organization, because that > way each project part can use the desired version of the common stuff, and > people can modify the common stuff without then testing the whole > universe. The build infrastructure is only a small part of the superproject thing. A much more interesting thing in many ways is the "how do the pieces fit together" question, ie the "which library version X do I need for program version Y?" And that needs to be at the superproject level, obviously. The person who works on the application will want to fetch the library too, but he likely isn't interested in all the *other* libraries that don't affect his app, and he likely isn't interested in things like standard libraries (which may be in the superproject too, but since their versioning doesn't affect any normal subproject, you'd not expect application developers to have all of libc checked out and built, would you?). So yes, you could have several levels: the top level for "versioning", the middle level for "applications and libraries" and some third level for "build infrastructure that can be shared". However, I've never actually seen any project work that way. People *always* seem to put the build infrastructure at either the top level, or as one of the subprojects that is required for all the other subprojects. Of course, it's possible that the reason people do that is that things like CVS are really really bad at the versioning stuff, and since they aren't distributed, you cannot put the shared build infrastructure in multiple projects at the same time anyway. So with a distributed environment like git, doing the shared build infrastructure as a separate sub-sub-project would work in ways it does *not* work in a centralized model, but I think we also want to just support the way people are used to working, and that definitely involves having the build infrastructure at or under the top level.. 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