如何与(“集中式")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 提交导出到本地 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 的新方法，以及我们一直这样做的习惯在哪里.在一个试点项目中使用 mercurial 是说服其他团队成员的关键.

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屋！