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.
myProject) with multiple folders. But then you are talking about branching folders
coreas if they were respositories rather than folders.