But these repos are many months out of sync as I've stopped my personal AWS EC2 instance that was doing the mirroring.
The problem with git mirroring right now is:
1. MapGuide has svn:external links to CS-Map and Fusion repos. If we mirror MapGuide to git, we have to mirror CS-Map and Fusion to git as well at a bare minimum and translate svn:external references to their git equivalents (submodules?) 1.1. CS-Map has really large dictionary data files that break github's repo file limits forcing me to use git-lfs for storing these files. But git-lfs storage is a severely restricted service on GitHub's free tier. Last I checked, I used up my free tier git-lfs quota just doing a single force push of this repository! 1.2. Git submodules are hell in my personal experience, but not using submodules require developers having to set up CS-Map and Fusion source trees manually within MapGuide's source tree. 2. I have not been successful in coming up with a svn -> git conversion scheme that allows commits or merged PRs in github to easily flow back into SVN. This is probably because I've been cleaning out historical baggage (eg. Commits of source/binary tarballs in LinuxApt/Installer) as part of the svn -> git conversion process with bfg repo cleaner so a git clone is not so bloated. But even on pristine converted git repos I could not succesfully get git commits to flow back to its svn counterpart.
Now suppose we give up the notion of trying to have a bidirectional svn <-> git mirror and just bite the bullet and do a full blown one-way migration (leaving the svn repos behind, and not have to worry about #2 above). Then the problems become project management related.
a) You preferably want buy-in from all PSCs involved in this one-way migration, otherwise you're having to setup up and maintain "un-official" git mirrors of all MapGuide upstream repos. b) For FDO particularly, I know Autodesk keeps maintaining a 4.2 commercial branch that I like to selectively merge useful commits from into OS trunk and other OS branches on a semi-regular basis. One-way migrating FDO to git would need Autodesk buy-in to continue their maintenance on the migrated git repository. c) For CS-Map particularly, the dictionary file size limitations have to be addressed. Preferably in a way that does not involve a paid git-lfs storage plan. d) There's organizational questions around whether these migrated repos should fall under the OSGeo github org or another github org. e) There's also setup/integration questions around OSGeo CLAs in these repos as being an OSGeo project, we could not accept external pull requests without confirmation (strongly-and-preferably automated) that the submitter has signed and submitted an OSGeo CLA
Pardon the preceding wall of text, I had thoughts about git migration brewing in my mind for a while but had not put anything to words since nobody else had posed the git migration question until now.
Since you are also from Autodesk, it would probably be more effective to for you to start this conversation with your colleagues who still commit changes to these various projects "from within" to seek some consensus from the Autodesk side as to whether it is worth moving to github in addition to addressing some/all of the points I've raised. I wouldn't want to go all-in on a one-way git migration only to find Autodesk still making commits to the original SVN repos afterwards.