Should each software project have it's own repo?

[Bruce Strickland]

We are currently in the process of moving to Stash GIT/ Bamboo. Although we have .Net projects, we have VB6, C, C++ and Cobol projects dated back to the late 90's that are still in service. That's another topic.   We have over 3000 software projects that make up 25 different applications that, when combined, make one product. 30k files at 17 gig. We only modify a fraction of those each release but they are all valid and could be subject to change in any release. 

So my question is: Would we need a repo for each of the 3000 projects or should we only have a repo for each of the 25 application folders that contains a few hundred projects each? I think it would be infeasible to have one repo for all of them because of the size of the repo during clones. I'm also thinking that 3000 repos would be unmanageable branch-wise since we are planning on a model like http://nvie.com/posts/a-successful-git-branching-model/ . We are also using SourceTree on the developer end. I would like to hear if anyone has faced this dilemma and the route they took. Please note my definition of a project is what you would create in Visual Studio or similar. For example a Hello World project.

All responses are welcome! Thanks very much!

[Mike Friedrich · Accepted solution]

It is totally up to ypu. I would recommend organizing it so that the developers can work with it. Means it depends a bit on your team structure. Also look how much is shared between the applications. I guess you have to find the right trade off between one huge repo and 3000 small repos.

[Rich Duncan]

Consider what work gets done as a unit. You can put whatever file structure you want in a git repository, but branches and tags are for an entire repository.  Let's say you want to create a new feature, so you create a branch for it.  If you had 3000 repos, would you create 1 branch or dozens of branches all of which are for the same feature?  If you had 25 repositories (per application) would the branch contain a large number of projects that don't pertain to the feature in question?

[Tim Crall]

In addition to what other people have said, one rule of thumb is that things that version together should be in a the same repo and things that version independently from one another should be in their own repo. Also it's good to put relatively stable code in different repos from dynamic code.

[Mike Friedrich]

When you say projects, do you mean visual studio projects or something similar?