Description
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 export *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. This would allow users to continue to cvsup the repository in order to track existing branches, as well as to query past CVS history in its original CVS format.
Current Implementation
SVN Implementation
With SVN, we would do it the same way as we would with the P4->cvs gateway. A script or hook would monitor changes to parts of the tree that were tagged for export to cvs and replicate the changes across.
Hg Implementation
Exporting our changes in a read-only CVS is certainly doable and easy in this direction. The main thing is that we would be aggregating several Hg repositories into a single CVS one so it must be done cerefully to ensure that changesets from the src6 repo would end up in the RELENG_6 branch.
Committing in the CVS tree could be done either through a hook or through the Patch_Queue_Manager.
Git Implementation
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.