It depends on how closely coupled the modules are. And mainly how closely coupled they are in organizational terms.

All modules developed by the same team in context of the same project (in management sense of the word) should probably go in one repository, especially if it’s possible that a logical change will span more than one of them.

Modules that are developed separately, they should live in separate repositories. But than there should also be at least semi-formal release process for providing the results of one project to the other. Not because of git but to reduce communication overhead especially when a bad commit in one project would affect many people in other projects.

Git will happily work with hundreds of thousands of files. It will work if you split or if you don’t. So the decision to split is organizational. You want some barrier between teams so mistakes don’t affect too many people and you want reasonably small teams to limit the communication overhead (20 people is rather large team).

TFS treats everything as a single repo, so you can’t do much harm starting with all stuff in a single git repo retaining the previous structure. Or splitting off only the obviously disjunct elements.

You can split the big repo with subtree after-the fact anytime preserving the history.

Having a single repo has many actual advantages and unless clone size is considered relevant the drawbacks are easy to mitigate.

If you start with multiple repos you immediately need some tool to sync them all for fetch and tag all on release points. Also moving code around is inconvenient (from app to shared lib, should be common and straightforward).

Sure you may fight your way with submodules, or something similar but many folks find those kept as last resort.

We moved from tfs to git a year and a half ago, I created a bin repo for external components, one for “data”, and kept all the sources that are built with VS in one repo. Only splitting the fortran sources on which one programmer is working and he has a bin repo to release the output — that supplements the bin repo. And I immediately wrote a tool in python that knows about all the repos (we also have installer, tests, tools, etc) and allows basic operations (fetch, status, synch), and more importantly, that “creates” the development environment copying the external includes, libs, dlls…

The source repo has some 1.6M lines of code in ~4000 files and ~90 projects. I have no plans to split it. The bin and data repos are fortunately quite cold. Still a few times it was PITA to go back with sources and need to manually go back with others too bisecting a problem.

Ah, the old “shared projects”.. for those who don’t use TFS (or VSS) you can create a kind of symlink inside your repo so a single project appears to be in 2 places at once. This is what is being used here.

To my knowledge, no other SCM has this feature. IMHO this is a good thing as it makes you think of each project as an independent entity and not mix it up inside projects – I think its only really usefulness is if your IDE doesn’t handle external references well…

So, if you want to migrate away, you’re going to have to split these shared projects into a different project structure, and build them separately. then change your projects so they build with references to the sub-projects. Do not try to keep the same mind-set of keeping these projects in the existing tree/solution structure. Your solutions will not be able to contain all the projects within them. MS has some guidelines for organising your SCM, you’ll have to move from the ‘partitioned solution’ model to the ‘multiple solutions’ model.

you’ll have to manage dependencies between the projects, but that’s not so hard if you have a good CI system that will build a chain of dependencies when 1 changes (I recommend Jenkins, its as powerful yet much simpler than the unmaintainable xaml-based build TFS2012 now uses)