twinge

Three big problems with a split up codebase:

1) Instead of doing one large release every week (which facebook does: http://www.facebook.com/video/video.php?v=10100259101684977) you now have dozens or hundreds of smaller releases, a lot more heterogeneity to test for.

2) If you have inter-dependencies on modules you have to grapple with the "diamond dependency" problem. Say module A depends on module B and C, and suppose that module B also depends on C. However, module B depends on C v2.0 but A depends on C v1.0. If they're all split across repositories it's not possible to update a core API in an atomic commit.

3) Now you rely on changes being merged "up" to the root and then you have to merge it "down" to your project. This is one of the reasons Vista was such a slow motion train wreck: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c... -- kernel changes had to be merged up to the root, then down to the UI, requiring months of very slow iterations to get it right.

Control is part of it, but it's also due to the fact that it is hard to implement features to work in a heterogeneous environment. The temptation is to dev and test a fully deployed environment, when really you should test probable configurations with several pieces either missing or performing badly.

A majority of the search results are from Bing, blended with some other sources (Wolfram, Wikipedia, others).

Careful with that, git operations aren't atomic. Safer to keep two git dirs and flip a symlink between them between pulls.

Cedric used to work for Google. He was, on occasion, a brilliantly hilarious troll.