We are in the process of moving from SVN to Git but are facing some critical practical questions the we were not able to answer yet.
Currently we have one large SVN repository that contains 100+ projects.
They are build by 3 Jenkins jobs, i.e. many projects are built by the same job and they are also always released together (though they are are only loosely coupled).
This setup cannot be changed because it's impossible to maintain 100+ Jenkins jobs and every job will require about 3GB of space on disk (regardless of how many projects it builds).
If you multiply this with 3+ active branches this will completely exhaust our available resources.
The simple solution would be to convert the one SVN repository into one Git repository and everything works as before.
However, as Git doesn't allow setting permissions on directories inside a repo and this also isn't the proper "Git way" as we learned, splitting up the repository would be quite nice.
But then we come back to the many Jenkins jobs issues.
In principle it seems to be possible to specify more then one Git repository per Jenkins job but also this gets quickly unmaintainable if more repositories are added because the Jenkins GUI just isn't good at dealing with many entries. Chances of forgetting to add a new repository to a job are quite high, too.
Therefore we had a look at submodules, subtree, and subrepo in order to create a consistent (read-only) view on a bunch of repositories.
This view (or a few of them) should be managed centrally and the Jenkins jobs would simply checkout this view and get everything that is required for building the projects.
As simple update of the view would pull the latest versions from all included repositories. However, as far as I understood, this doesn't work for any of the approaches because they either require special commands to update the included repositories to the latest remote version (which the Jenkins Git plug-in cannot do) or even a commit to move the module pointer forward to the latest version.
So here is the simple question: how would you solve this problem with Git without using one large repository?
