您会从 cvs 迁移到 svn 还是直接迁移到 git 或 hg？
我不知道这是否是提问的正确论坛。
我的公司使用 CVS 作为版本控制系统。我们计划转向更现代的版本控制系统。作为风险最小的解决方案，您会推荐什么？
我的想法是使用 Subversion，但我也听到了很多关于 Git 和 Mercurial 的好消息。
但是，我们是一家小公司，我们不需要分布式版本控制系统。除了分布式之外，Git 或 Mercurial 相对于 Subversion 还具有哪些优势？
I don't know if this is the right forum to ask.
My company makes use of CVS as a version control system. We plan to move to a more modern version control system. What would you recommend as the least risky solution?
My idea is to use Subversion but I also hear a lot of good things about Git and Mercurial
However, we are a small company and we don't need a distributed version control system. What advantages do Git or Mercurial have with respect to Subversion, besides the fact that they are distributed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
大约两周前，我们在工作中从 CVS 迁移到了 Mercurial。我们是一个6人的小团队。在迁移之前，我们中只有两个人已经使用过 CVS 以外的其他工具。
我负责新CVS的选择。我考虑过 Git 和 Mercurial。
我们在使用 CVS 时遇到的一些问题是分支可能性差、不支持重命名、冲突算法非常糟糕。
我从来没有考虑过 SVN，因为过去每次我尝试将它与分支一起使用时，合并总是令人头疼。坦率地说，现在所有的炒作都是针对 dvcs 的，这肯定是有原因的；）
在 Git 和 Mercurial 之间，实际上更多的是个人选择。我很喜欢 Mercurial，因为我发现它比 Git 更容易学习，而且不太以“真正的大项目”为导向。
Git / Mercurial 相对于 SVN 的优势
即使你说“除了它们是分布式的这一事实之外”，我认为这确实是一个杀手级功能。 DVCS 允许一些非常巧妙的东西，一开始可能看起来没什么用，但是一旦你使用了它们，你就不能没有它们；）
学习曲线
团队中的两个人对这个变化并不是很高兴。但通过一些幻灯片对整个团队进行了两个小时的解释后，一切都很顺利。
当然，他们有时会问我问题，但自从迁移以来我们没有遇到任何真正的问题。只是对合并工作目录中拉取的更改的方式有一些小误解。没有什么事是几分钟内解决不了的。
我想我可以说，在短短两周内，每个人都至少和以前一样高效，并对新工具充满信心。现在我们可以使用功能分支，而不必担心即将发生的合并:)
将 CVS 迁移到 Mercurial
https://www.mercurial-scm.org/wiki/RepositoryConversion#CVS
官方 wiki 上列出了有关从 CVS 迁移到 Mercurial 的不同方法。我测试了Convert扩展和最终使用的cvs2hg。
来自 CVS 的 Tailor 扩展 hg-cvs-import 似乎是旧代码，不再维护。
Convert 扩展在简单的存储库上工作得很好，但由于我们的 CVS 存储库非常大并且有一些非常奇怪的分支，因此该扩展无法正确导入所有历史记录。 HEAD 是正确的，但缺少一些分支。
因此，最后的选择是 cvs2hg。事实上，它是 cvs2svn 的新后端，它转换为 Mercurial 而不是 Subersion。
自述文件中提出的“快速启动”方法适用于所有分支。但最后我使用选项文件添加一些用户映射并修剪一些有错误的提交或不需要的分支。
文件中提供的选项文件有很好的注释，您可以轻松配置它以适合您。
有关信息，在初始转换后，我使用 Convert 扩展将一些子项目从生成的 Mercurial 存储库提取到另一个 Mercurial 存储库，如所解释的 此处。
We migrated from CVS to Mercurial about 2 weeks ago at my job. We are a small team of 6 people. Only two of us had already worked with something other than CVS prior to the migration.
I was in charge for the choice of the new CVS. I considered Git and Mercurial.
Some of the griefs we've had with CVS were poor branching possibilities, no support for renaming, really bad algorithm for conflicts.
I never considered SVN because, each time I tried to use it with branches in the past, merges were always a headache. And frankly, all the hype is for dvcs these days, and there must be a reason about it ;)
Between Git and Mercurial, it's really more about personal choice. My heart fell for Mercurial because I've found it easier to learn than Git and less "really big project" oriented.
Advantages of Git / Mercurial over SVN
And even if you said "besides the fact that they are distributed", I think this is really a killer feature. DVCS allows some really neat things, it may not seem useful at the beginning, but once you've used them, you can't do without them ;)
Learning curve
Two people on the team weren't really happy about the change. But with a little two hour explanation for the whole team with some slides, everything went smoothly.
Sure, they ask me questions sometimes, but we haven't had any real problems since the migration. Just some little misunderstandings about the way to merge pulled changes in the working directory. Nothing which wasn't resolved in a matter of minutes.
I think I can say that in just about 2 weeks, everyone is at least as productive as before and confident with the new tool. And now we can use features branches without fear of the merge to come :)
Migrating CVS to mercurial
https://www.mercurial-scm.org/wiki/RepositoryConversion#CVS
Different methods are listed on the official wiki about migrating from CVS to Mercurial. I tested the Convert extension and cvs2hg which was finally used.
The Tailor extension, hg-cvs-import, from CVS seems to be old code and not maintained any more.
The Convert extension works just fine on a simple repository, but since our CVS repository was really big and had some really strange branches, the extension wasn't able to import correctly all of the history. The HEAD was correct, but some branches were missing.
So, the last choice is cvs2hg. In fact it is a new backend for cvs2svn, which converts to Mercurial instead of Subersion.
The 'Quick start' approach presented in the Readme worked out of the box with all the branches. But finally I used the option file to add some user mapping and prune some buggy commits or unwanted branches.
The option file in the provided with the files is well commented, it won't be hard for you to configure it to suit you.
For information, after the initial conversion, I used the Convert extension to do some subproject extraction from the resulting Mercurial repository to another Mercurial repository, like explained here.
编辑：伟大的链接 - http://whygitisbetterthanx.com/
============ ================================================
是的，事实上我们刚刚从 SVN 迁移到 Mercurial。
除了分布式方面之外，Mercurial 和 GIT 比 SVN 快得多，而且存储库中的文件夹中没有烦人的 .SVN 文件夹。更不用说合并效果更好了！事实上 yuo 还可以将您的存储库存储在任何共享驱动器上，这很好（无论如何，对于 Mercurial 来说，无需在服务器上安装东西）
更多阅读
我应该使用 SVN 还是 Git？
http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-be-the-future-of- revision-control/
http:// /thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/
http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/
最后是 GIT VS Mercurial
http://gitvsmercurial.com/ - 这个网站看起来现在已经死了:(
Edit : Great Link - http://whygitisbetterthanx.com/
==========================================================
Yes, infact we have just moved from SVN to Mercurial.
Aside from the distributed side of things Mercurial and GIT are alot faster than SVN, and also the repo doesnt have annoying .SVN folders in ever folder. Not to mention the merge works alot better! The fact yuo can also store your repo on any shared drive is nice (No need to install stuff on the server, for Mercurial anyways)
More reading
Should I use SVN or Git?
http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-be-the-future-of-revision-control/
http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/
http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/
And finally GIT Vs Mercurial
http://gitvsmercurial.com/ - This site looks like it's dead now :(
合并代码并解决冲突
使用分布式 VCS 更容易
例如 GIT 或 Mercurial。原因
是 GIT 还是 Mercurial 都有
的中间快照
两个“结束代码”要合并，同时
颠覆才知道结局
快照，除非每个 SVN 用户都是
在他/她自己的分支中工作。
使用分布式 VCS，您不再需要
依赖网络来检查
代码。
每天将内容检查到 VCS 中
基础上，你的SVN服务器最好是
处理并发非常强大
签入/签出。 DVCS 不存在这个问题。
我们从 CVS 切换到 SVN，现在又切换到 Mercurial，我们对这一转变感到非常满意。 Mercurial 中我们没有遗漏 SVN 的任何内容，但回到 SVN 会很痛苦。
Merging code and resolving conflicts
is easier using a distributed VCS
like GIT or Mercurial. The reason
is that GIT or mercurial have all
the intermediate snapshots of the
two "end codes" to be merged while
subversion would only know the end
snapshot unless each SVN user is
working in his/her own branch.
With a distributed VCS, you are not
dependent on the network to check
code in.
checking stuff into VCS on a daily
basis, your SVN server better be
very powerful to handle concurrent
check-ins/outs. DVCSs dont have that problem.
We made our switch from CVS to SVN and now to Mercurial and we are very happy with the transition. There is nothing about SVN we are missing in Mercurial but going back to SVN would be painful.
SVN 拥有的对您的工作流程可能很重要的东西：
部分签出。
只能签出树的一部分（如果您的存储库中有超过 1 个项目，这一点很重要）
混合签出。
结帐的部分内容可以采用不同的版本，直至单个文件。
全局唯一的修订是单调递增的。
在 SVN 中很容易看到 rev 1206 晚于 1100（cfbb0827c67d 晚于 d500c208c3c5 吗？）
许多项目可以共享同一个 SVN 存储库。
如果您的软件包由多个 EXE、DLL 等组成，
在 Hg/Git 领域，您最终可能会使用多个存储库来管理它。
这可能会使标记/修订处理变得有些复杂
Things SVN has that might be important to your workflow:
Partial checkouts.
Can just checkout part of the tree (important if you have more than 1 project in your repository)
Mixed checkouts.
Parts of your checkout can be at different revisions, down to a single file.
Globally unique revision is monotonically increasing.
It's easy to see in SVN that rev 1206 is later than 1100 (c.f., is cfbb0827c67d later than d500c208c3c5?)
Many projects can share the same SVN repository.
If your package consists of several EXEs, DLLs and whatnot,
in Hg/Git land you may end up using several repositories to manage this.
This can complicate tag/revision handling somewhat
我们（诺基亚 OVI 地图）也正在从 SVN 迁移到 HG。选择 HG 而不是 git 的原因是 HG 更加用户友好，与有时晦涩难懂的 git 命令相比，这些命令更有意义。另外，对于 Windows 用户来说，mercurial 的效果要好得多，而且 tortoiseHG 也相当成熟。当我在 Windows 上测试 git 时，我在一些简单的操作（例如检查修改）中观察到严重的性能问题......
我也非常喜欢您可以通过扩展使用您想要的功能。因此学习曲线比 git 更平滑，例如考虑缓存区域。对于来自 SVN 的人来说，我认为 HG 是不错的选择。
他们应该对历史更加小心，例如，我们鼓励执行 hg pull --rebase 以使历史尽可能线性并仅合并分支。
We (Nokia OVI maps) are also migrating from SVN to HG. The reason to choose HG over git is that HG is more userfriendly, the commands make much more sense compared to the sometimes obscure git commands. Also for windows users mercurial works much better, and tortoiseHG is quite mature. When I was testing git on windows, I observed serious performance problems at some simple operations like checking for modifications...
I really like also that you can use features that you want via extensions. So the learning curve is smoother than with git, consider the cache area for example. For people coming from SVN I think HG is good option.
They should be more careful with the history for example, we are encouraging to do hg pull --rebase in order to have history as linear as possible and merge only branches.