I am migrating a 10-years-old big CVS repository to Git. The current projects managers were developers of their projects 10 years ago (and became team leaders, then project managers year after year). Therefore they have the CVS point of view only.

When I told them I was planning to split THE repo into many small Git repositories, they were afraid and they said ***NO we want one repo!*** I did not anticipate this case so my arguments (It is the way it has to be on Git) did not convinced them :-/

=> I need to educate them! The success of this change depends on it! 

I have already thought about the branches/tags impacting the whole Git repository files. I was also thinking about the [max 4 GB Git repo size](http://code.google.com/p/support/wiki/GitFAQ) but [it is wrong](http://stackoverflow.com/a/11043582/938111) ;-p Maybe {{git annotate}} is slower on *bloat* Git repo... As I am still a newbie on Git, I need your help/experience/feedback :-)

**What are the arguments to split one multiple-libraries/applications CVS repository into multiple Git repositories?**

( Just for the fun: At the meeting end, I explained the `cvs2git` takes so much time (23 hours) that my workload is very low and many attempts because many issues (CVS repo internal errors, disk full, more Git checks...). Suddenly they wanted to split to multiple Git repositories to make my life simpler and to save money ;-) But it is not the right reason to do so. I just want to convince/educate them with the right arguments. )

NB: The managers also want to keep everything within the repository (dead projects, 10-years-old tags, third parties, old unused files `*.xls`, `*.ppt`, `*.dll`, `*.pdb`, `*.so`...). *The repo is their memory, their work life!* I can manage that ;-)