如何与(“集中式")DVCS存储库并行运行CVS? [英] How to run CVS in parallel with a ("centralized") DVCS repository?

问题描述

目前，我正在研究如何引入DVCS(特别是我正在研究Hg和Git)，同时保持CVS存储库并行(甚至只是通过CVS协议的访问机制).这里有一些开发人员非常不愿意从CVS切换，但是如果可以自动同步它们或具有CVS协议前端，则并行运行它们应该没问题.

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.

过去，CVS存储库已经过手动编辑(在磁盘上)，但是似乎都是一致的，无论如何我都可以尝试转换，并且我们还可以将CVS存储库的副本保留为原来的状态当我们迁移时.

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.

考虑到Git的支持，我的想法是运行git-cvsserver(1)前端，但是我没有使用它的经验，也没有事先进行过的实际转换的经验.假设这总体上是一个理智的想法，那么谁能给我一些指向列出使用此迁移路径的经验的文章的指针.如果您必须提供任何此类建议，那么也很可能了解潜在的警告.

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.

迁移应该是尽可能无缝的.因此，只要CVS前端事后无缝运行，在几次排练"之后的晚上进行分阶段就可以了.

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.

DVCS的工作流程最终将再次集中化，但是我想利用高级合并跟踪和其他CVS根本不具备的机制.

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.

推荐答案

尽管git提供了CVS服务器，但该服务器非常受限制.您无法创建标签或分支，并且git分支显示为CVS模块.同样，您也不能以这样的方式将CVS仓库转换为git，以至于事后文件版本号相等(git cvsserver在需要时为每个git分支创建一个自己的文件版本数据库).

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，您可以将git用作cvs前端.工作流程是您使用git cvsimport从CVS服务器提取历史记录，并使用git cvsexportcommit将一些git commit导出到本地CVS检出中. Tsuna的博客中有一篇文章，其中提供了有关以下内容的更多详细信息:这个.

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.

解决此问题的另一种方法是分析为什么您的同事不希望切换.在这里，他们只是根本不知道/不在乎VCS的新方法，也不知道我们一直在这种方式养成什么习惯.在一个试点项目中使用Mercury是说服这里的其他团队成员的关键.

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.

这篇关于如何与(“集中式")DVCS存储库并行运行CVS?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！