3 ms·

You end up with less developers having to pull & merge/rebase if you have things in separate repos. Individual libraries/dependencies get worked on by themselv

• taeric 12y ago
  The problem with this, is that you are assuming the APIs change in some sort of odd isolation to the parts that use them. That is, the reason an API changes is because a use site has need of a change. So, at a minimum, you need to make that change and test it against that site in a somewhat atomic commit. Then, if the change has any affect on other uses, you need a good way to test that change on them at the same time. Otherwise, they will resist pulling this change until it is fixed. Add in more than a handful of such use sites, and suddenly things are just unmanageable in this "manageable" situation. Not that this is "easy" in a central repo. But at least with the source dependency, you can get a compiler flag at every place an API change breaks something. And, true, you can do this with multiple repos, too. But every attempt I have seen to do that just uses a frighteningly complicated tool to "recreate" what looks like a single source tree out of many separate ones. (jhbuild, and friends) So, if there is a good tool for doing that, I'd certainly love to hear about it.