There are too many installed systems, and too many users accustomed to CVS, to abandon it at least in the short term. We need to maintain a CVS export of the new VCS.

One implication of this requirement is that we not only be able to expore *a* CVS repository, but because end users can and do replicate our whole repository, that they not need to re-cvsup an entirely new repository, but rather, incremental changes on the existing repository. If CVS import followed by CVS export can't produce an identical repository, it is sufficient to perform an import, then mirror future commits to the new repository into a copy of the original FreeBSD CVS repository, as long as this done in a reproduceable and accurate way.

The main FreeBSD repositories would be in git. However, we could easily construct a cronjob to export our changes to the old CVS repos, similar to what we do with p4, which would have commit messages like “FreeBSD automated git to CVS import of commit <sha1>”. This allows those who want read-only access without using git to continue using CVS. This leaves trouble debugging, where the user only has version information for $FreeBSD$ CVS IDs (if those even stuck around!) to tell us, while the developers aren't interacting with the CVS revision IDs. So, I would recommend in that export process to create a file at the top level of the repo marking what sha1 the last import was from, which allows users of both cvsup checkout mode and normal CVS to tell developers what git revision their code was from.