Christopher did a very good job of enumerating the disadvantages of a one-project-per-repository model. I would like to discuss some of the reasons you might consider a multiple-repository approach. In many environments I have worked in, a multi-repository approach has been a reasonable solution, but the decision of how many repositories to have, and where to make the cuts has not always been an easy one to make.
In my current position, I migrated a behemoth single-repository CVS repository with over ten years of history into a number of git repositories. Since that initial decision, the number of repositories has grown (through the actions of other teams), to the point where I suspect we have more than would be optimal. Some new-hires have suggested merging the repositories but I have argued against it. The Wayland project has a similar experience. In a talk I saw recently, they had, at one point, over 200 git repositories, for which the lead apologized. Looking at their website, I see now they are at 5, which seems reasonable. It's important to observe that joining and splitting repositories is a manageable task, and it's okay to experiment (within reason).
So when might you want multiple repositories?
- A single repository would be too large to be efficient.
- Your repositories are loosely coupled, or decoupled.
- A developer typically only needs one, or a small subset of your repositories to develop.
- You typically want to develop the repositories independently, and only need to synchronize them occasionally.
- You want to encourage more modularity.
- Different teams work on different repositories.
Points 2 and 3 are only significant if point 1 holds. By splitting our repositories, I significantly decreased the delays suffered by our offsite colleagues, reduced disk consumption, and improved network traffic.
4 and 5 are more subtle. When you split the repos of say a client and server, this makes it more costly to coordinate changes between the client and server code. This can be a positive, in that encourages a decoupled interface between the two.
Even with the downsides of multi-repository projects, a lot of respectable work is done that way -- wayland and boost come to mind. I don't believe a consensus regarding best practices has evolved yet, and some judgement is required. Tools for working with multiple repositories (git-subtree, git-submodule and others) are still being developed and experimented with. My advice is to experiment and be pragmatic.