将 CVS 升级到 git/hg 的技巧？
我们仍然使用 CVS，我使用 git 和 hg 供我个人使用，虽然我对这两者都还是新手，但我意识到它们更现代、更好、更快、分布式等等。
只是每个人都太习惯 CVS我觉得如果我是推荐并实际将我们当前的 CVS 服务器升级/移植/转换为 git 或 hg 的人，可能会出现一系列问题。
最近有人真的这样做过吗？您能否提供有关影响人们使用 git/hg 的任何见解或提示，以及有关实际更新/转换（如果要发生）的一般提示？是否有我应该注意的常见问题？
We still use CVS, I use git and hg for my personal use though I'm still a novice at both, but I realize they're much more modern and better, faster, distributed, etc.
It's just everyone is so accustomed to CVS that I feel a whole slew of issues could arise if I were to be the one that recommended and actually did the upgrading/porting/transitioning of our current CVS server to git or hg.
Has anyone actually done this, recently? Could you offer any insight or tips in terms of influencing people to use git/hg, and just generic tips on the actual updating/transitioning if it were to take place? Are there common issues I should be aware of just in general?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我刚刚遇到这个问题，并且我曾在尝试实现这种转变的地方工作过。它不起作用。
我这么说并不是为了阻止任何人，而是为了强调人们可能遇到的问题。
问题很多，但基本上都归结为人们没有看到 CVS 的问题。我知道这很神奇，但它已经存在这么久了。他们已经习惯了这些特质，现在却对它给他们带来的问题视而不见。引入一些新的东西，他们无法理解为什么事情需要以不同的方式完成。
其中最大的问题之一是原子提交的概念。人们无法忽视这样一个事实：修订现在是整个项目树的状态，而不是文件的状态。因此，在
文件 B中存在未完成的更改的同时，检查文件 A中的更改突然成为针对版本控制系统的抱怨平台。当您在该级别上遇到困难时，您可能会忘记尝试引入“高级”概念，例如比发布代码时更频繁地提交，或者在用户之间共享更改。
致命一击是，他们将一个拥有数百名开发人员和大约 70 个子项目的庞大项目放在一个集中存储库中。这意味着这个中央存储库每天会收到 1-200 次提交。每个人总是将每个提交推送到它（因为
cvs commit == commit; Push对吧？）。它还提交了大量的自动化构建和测试报告。将所有这些放在一起，您就无法在不需要重新pull;merge的情况下执行pull;merge;(无测试);push，因为你已经过时了。当你等待那个巨大的拉力完成时，有人推动了一些东西。...并且因为人们没有测试他们的合并，所以发生了破坏。
哦，还有一个人将大约 10 个分支合并在一起，因为他知道必须合并，但他不明白要合并什么或为什么。
结果......他们买了Perforce。
原因：它带有支持合同，因此当出现问题时有人可以[责备/修复]。
因此：
如果可以的话，在开发人员数量较少的项目中慢慢地进行。教育他们；设置正确；让他们成为公司其他成员的布道者。消息会传开，每个人都会想要这个新的神奇工具，因为“当我们一直在使用 CVS 时，为什么 Bob 的团队会获得新工具？您是否意识到我们因此而遇到的所有问题？ ”
I've just come across this question, and I've worked somewhere that tried to make this transition. It didn't work.
I don't say this to discourage anyone, but to highlight issues that people may come across.
The problems were numerous, but basically they all came down to the fact that people didn't see the problems with CVS. Amazing I know, but it had been there for so long. They'd become used to the idiosyncrasies and were now blind to the issues it was causing them. Bring in something new and they couldn't understand why things needed to be done in a different way.
One of the biggest ones was the notion of an atomic commit. People couldn't get past the fact that revisions were now a state of the whole project tree, rather than a state of a file. So checking in a change in
file Awhilst there were unfinished changes infile Bsuddenly became a platform for a rant against the version control system.When you're stumbling at that level, you can forget trying to introduce "advanced" concepts like committing more frequently than when you want to release code, or sharing changes between users.
The death blow was the fact that they'd taken a huge project, with hundreds of developers, and about 70 sub-projects, and put it in one centralised repository. This meant that this central repo was getting 1-2 hundred commits a day. Everybody was always pushing every commit to it (because
cvs commit == commit; pushright?). It also got large automated build and test reports committed into it. Put it all together and it got to the stage that you couldn't do apull;merge;(no testing);pushwithout needing to re-pull;mergebecause you were out of date. Someone had pushed something whilst you were waiting for that big pull to finish.... and because people weren't testing their merges, breakages happened.
Oh, and one guy merged about 10 branches together because he knew he had to merge, but he didn't understand what to merge or why.
The result.... They bought Perforce.
Reason: It came with a support contract, so there was someone to [blame / fix it] when it went wrong.
So:
If you can, bring it in slow on a project with a small number of developers. Educate them; set it up right; make them evangelists for the rest of the company. Word will spread and everyone will want this new wunder-tool, because "Why does Bob's team get new tools when we're stuck working with CVS? Do you realise all the problems we have because of it?"
也许这个 StackOverflow 问题（及其答案）会有所帮助：
Perhaps this StackOverflow question (and its answers) would be of help:
不确定您是否正在寻找有关迁移的一般指南或两种服务的完整比较，但这里是 前。
编辑
由于提到了 SVN 这里是我在一些 SVN 到 Git 迁移中使用过的很棒的指南。
编辑
我发现了这个很棒的网站，为什么 Git 比 X 更好，我想我将其添加到此答案中，以供其他考虑切换到 Git 进行版本控制的人使用。
Not sure if your looking for a general guide on migration or a full on comparison of the two services, but here is the former.
EDIT
Since SVN was mentioned here is a great guide I've used in a few SVN to Git migrations.
EDIT
I came across this great site, Why Git is Better than X, I thought I'd add it to this answer for other people thinking of switching to Git for version control.
我现在正在经历这个，所以我要加上我的 2 美分（游戏后期）。
我负责带领我们的团队从 CVS 转向 Subversion、Mercurial 或 Git。您团队的专业知识、您的项目和您的发布方法可能会改变您给出的答案。坦白说，我的团队致力于一系列较小的 Java 项目，并使用 Netbeans IDE 和 Maven 来开发和发布软件。
Subversion
是的，抱歉，有点偏离主题，但它仍然是 CVS 的明确升级。它将带来原子项目提交、广泛的现有用户群和一些良好的社区工具。这可能是最简单的过渡，所需的培训也最少，但您绝对不具备 DVCS 的力量。我推荐 cvs2svn 工具。
Mercurial
Mercurial 拥有丰富的文档，即使对于一些更奇怪的用例也是如此。启动存储库很容易。易于安装（只需使用 Python、安装工具和“easy_install Mercurial”）。易于转换，讨厌命令行的开发人员可以立即使用出色的 TortoiseHg 工具。
我发现 cvs2hg 工具在转换方面比内置的“hg Convert”扩展准确得多，但是ymmv。
要向所有人教授 hg，请尝试 Joel 的网站：HgInit。有很多书籍和在线教程，但让每个人都习惯推和拉（以及它与发布过程的关系）将是最疯狂的部分。我个人认为 DVCS 的推/拉模型更可取，但其他人可能不同意。这实际上就像强迫每个人对他们正在做的每一件事进行分支。
在决定是否使用 subrepo 还是只是将整个内容整合到一个大存储库中时，请选择单一存储库。事实证明，处理多个子存储库比仅拥有一个具有相互混合历史记录的存储库要麻烦一些。 （您的项目列表以及它们如何交互将极大地影响这个决定）您的 IDE 和 GUI 工具将有助于克服一些奇怪的情况。转换后，浏览每个分支并知道会发生什么。切换到分支不再意味着您将获得一些更改的文件。这意味着一切没有分支的东西都不存在。
Git
我真的很惊讶我对这个工具的喜爱程度。我们的 IDE 集成更好，该工具比 hg 更快（根据我的经验），并且更容易设置 ssh 存储库等内容。
安装、转换和设置是一件很麻烦的事。最后我认为这部分比所需的努力更有价值。根据 this 问题，“git cvsimport”工具在较大的 CVS 项目上被破坏。另外，我的首选转换工具： cvs2svn 非常需要帮助改进 Git 功能。在我弄清楚所有 blob/dump-file-then-import-to-bare-git-repo 业务之后，我发现它忘记从 CVS 获取我的所有分支。也许我对这些工具的理解不够深入，但从 CVS 到 Git 最安全的方法似乎是通过 SVN。
此外，还有很多反对 DVCS 的好论据，例如每个开发人员都在使用整个存储库的问题。如果你把一些坏的 jojo 推上来，然后它被拉了，那么移除它将会是一个巨大的痛苦。
要托管 http 存储库，请查看 scm-manager 和 罗德代码。 RhodeCode 更难设置，但功能更多。这两种工具都很难与子存储库一起使用，因此请做好准备。
至于说服你的老板。我通过创造“CVS 手术”这个术语来做到这一点。就像其他事情一样，跟踪您浪费在 CVS 和修复提交/回滚错误上的所有时间。然后将您的案例描述为“如果我们只转换到此工具，您现在可以免费使用我的 X 小时时间”。我发现回滚到 CVS 中未标记的提交、文件级提交以及查找正在发生哪些分支更改是 CVS 最大问题。
I'm going through this at the moment, so I'm going to add my 2 cents (late to the game).
I'm in charge of leading our team off of CVS onto either Subversion, Mercurial, or Git. Your team's expertise, your project(s), and your release methodologies will probably change what answer you give. For disclosure, my team works on a series of smaller Java projects and use the Netbeans IDE and Maven to develop and release software.
Subversion
Yeah, sorry, it's a little off-topic, but it's still a definite upgrade from CVS. It'll result in atomic project commits, a wide existing user-base, and some good community tools. It's probably the easiest transition with the least training necessary, but you definitely don't have the power of DVCS. I recommend the cvs2svn tool.
Mercurial
Mercurial has great documentation, even for some of the weirder use-cases. It's easy to spin up a repository. Easy to install (just use Python, setup-tools, and 'easy_install mercurial'). Easy to convert to, and the developers who hate command line get the great TortoiseHg tool out of the box.
I found the cvs2hg tool far more accurate in converting than the built-in 'hg convert' extension, but ymmv.
For teaching everyone hg, try Joel's site: HgInit. There's plenty of books and online tutorials, but getting everyone used to pushing and pulling (and how it relates to your release process) is going to be the craziest part. I personally find this push / pull model of DVCS preferable, but others may disagree. It's practically like forcing everyone to branch every piece they're working on.
When deciding whether to go with subrepo's or just meshing the entire thing into one big repository, opt for the single repository. Dealing with multiple subrepo's proved to be a bit of a pain over just having one repository with inter-mixed history. (Your list of projects and how they interact will affect this decision greatly) Your IDE and GUI tools will help overcome some of that weirdness. After conversion go through each branch and know what to expect. Swapping to a branch no longer means you'll get a few changed files. It means everything that wasn't branched doesn't exist.
Git
I really ended up being surprised at how much I liked this tool. Our IDE's integration was better, the tool was faster than hg (in my experience), and it was easier to set up stuff like ssh repositories.
Installation and conversion and setup was a bear. In the end I decided this part was worth more than the effort required. According to this question, the 'git cvsimport' tool is broken on larger CVS projects. Also, my go-to conversion tool: cvs2svn sorely needs help improving the Git functionality. After I figured all that blob/dump-file-then-import-to-bare-git-repo business, I found that it forgot to pick up all of my branches from CVS. Maybe I just never understood the tools well enough, but the safest way off of CVS to Git seems to be through SVN.
Also, there's plenty of good arguments against DVCS, such as the issue of every developer walking around with the entire repository. If you ever push some bad jojo up and it gets pulled, it's gonna be a huge pain removing it.
For hosting an http repostiory, take a look at scm-manager and RhodeCode. RhodeCode's harder to setup, but has far more functionality. Both tools are difficult to use with subrepos, so be prepared for that.
As for convincing your boss. I did it through coining the term 'CVS-surgery'. Just like anything else, keep track of all the time you're wasting going back through CVS and fixing commit / rollback errors. Then present your case as "You'd have X hours of my time for free right now if we'd just convert to this tool". I found rolling back to an untagged commit in CVS, file-level commits, and the difficulty involved in finding what branches changes were taking place in the biggest issues with CVS.