How to run CVS in parallel with a ("centralized") DVCS repository?

Question

At the moment I am investigating how to introduce a DVCS (in particular I am looking at Hg and Git) while retaining the CVS repository in parallel (or even just the access mechanism via the CVS protocol). There are some developers here that are very reluctant to switch from CVS, but running them in parallel should be fine if they can be synchronized automatically or have a CVS protocol frontend.

The CVS repository has been manually edited (on-disk) in the past, but all seems to be consistent and I can anyway try out the conversion before and we can also retain a copy of the CVS repository in the state it was when we migrated.

My idea, given the Git support for it, was to run the git-cvsserver(1) frontend, but I have no experience with it, nor with the actual conversion that has to take place beforehand. Assuming this is a sane idea overall, can anyone please give pointers to articles that list experiences with this migration path. It would also be great to learn of potential caveats if you have to offer any such advice.

The migration is supposed to be as seamless as possible. So staging it at night after a few "rehearsals" will be fine as long as the CVS frontend works seamlessly afterward.

The workflow with the DVCS will ultimately be centralized again, but I want to leverage the superior merge tracking and other mechanisms that ancient CVS simply doesn't have.

Answer 1

While git offers a CVS server, this server is very limited. You can't create tags or branches, and the git branches appears as CVS modules. Also you can't convert your CVS repo into git in such a way that the file revision numbers are equal afterwards (git cvsserver creates an own database of file revisions for each git branch at the time when they are needed).

OTOH you can use git as a cvs frontend. The workflow is that you use git cvsimport to pull the history from the CVS server, and use git cvsexportcommit to export some git commits into a local CVS checkout. There is an article in Tsuna's blog with more details about this.

Another way to tackle this problem is to analyze why your coworkers don't want to switch. Here it was that they simply did not know/care about new ways of VCS, and where into a we-always-did-it-this-way habit. Having used mercurial in one pilot project was the key to convince the other team members here.