我们正在从Clearcase迁移到另一个版本控制系统（可能是SVN或Mercurial）。对于已经完成此过渡的公司来说，选择另一个版本控制系统工具时发现哪些因素很重要？他们发现什么样的实践使得过渡更容易？
7个回答
3
还有两个需要补充的是：
- 性能：开发工具慢会打断开发者的思路。
- 功能强大：合并操作如何？像Git这样的新工具比CVS和SVN等传统工具具有更好的合并支持和跟踪功能。Git还提供了非常方便的工具，例如二分查找，可以加速开发过程。
- 社区支持：该工具的普及程度如何？你不想选择一个在未来五年将被淘汰的工具。
- Don Branson
1
+1 必须承认，Git和Mercurial都具有更好的合并支持。 - grenade
3
SVN和Mercurial都是很好的版本控制工具。许多开源项目都在使用它们。如果你的选择只缩小到这两个，那么你和你的团队必须考虑以下问题：
工作流程
你想如何提交和分支？分布式还是纯粹的集中式？这也与公司政策有关。如果你希望一切都集中管理，那就选择SVN。但这并不意味着你不能在Mercurial中拥有中央仓库。 如果你的团队选择像Mercurial这样的分布式版本控制系统，那么会有很多好处：
- 每个人都有自己的本地副本。这使得他们可以在家工作并进行本地提交。
- 每个人都可以在自己的本地机器上进行本地分支。不用担心在版本之间合并，Mercurial对合并有很好的支持，相对于SVN来说比较容易。
- 并非每个人都必须拥有提交权限，因为你可以指定某人为门卫，从其他开发者的机器上拉取修订版本。这使你能够在提交代码到中央仓库之前进行代码审查。
- Joshua Partogi
1
2许多人不明白分布式版本控制系统并非必须去除中央服务器。当他们意识到在无需中央仓库的情况下合并操作更加有效时，就会逐渐认同这一观点。 - grenade
2
通常情况下，我会选择使用分布式版本控制系统（DVCS）。虽然我没有尝试过mercurial但是 git可以，但前提是相同的。
如果你使用中央集中的系统，你就束缚于这种结构了。 如果您使用分布式系统，则不受此限制。 但仅仅因为您可以分发它，并不意味着必须要这样做。 如果在您的团队中使用单个中央存储库更合理，则应该采用这种方式。
您不应低估本地分支的作用。 在集中式系统中进行分支比较麻烦，很少有开发者或特性分支。 开发人员更喜欢拥有多个工作副本或保留不安全的更改以避免破坏构建。 使用分散式系统，开发人员创建本地分支并在其上工作。 当遇到停机问题时，他切换回主分支修复问题，将更改推送到中央存储库，然后再切换回功能分支。 工作流程非常顺畅。
此外，系统的分布性使其具有强大的韧性。 如果服务器关闭，对于开发人员而言也是一如既往的，他们甚至可以彼此交换更改。
最后，开发人员可以带着工作回家，在飞机上，火车上或任何他们喜欢的地方。 他们从不失去版本控制的能力，可以进行适当的提交。
结果是：开发人员对于版本控制系统的行为受公司政策的定义，而非技术限制，您可以随时更改政策。
如果你使用中央集中的系统，你就束缚于这种结构了。 如果您使用分布式系统，则不受此限制。 但仅仅因为您可以分发它，并不意味着必须要这样做。 如果在您的团队中使用单个中央存储库更合理，则应该采用这种方式。
您不应低估本地分支的作用。 在集中式系统中进行分支比较麻烦，很少有开发者或特性分支。 开发人员更喜欢拥有多个工作副本或保留不安全的更改以避免破坏构建。 使用分散式系统，开发人员创建本地分支并在其上工作。 当遇到停机问题时，他切换回主分支修复问题，将更改推送到中央存储库，然后再切换回功能分支。 工作流程非常顺畅。
此外，系统的分布性使其具有强大的韧性。 如果服务器关闭，对于开发人员而言也是一如既往的，他们甚至可以彼此交换更改。
最后，开发人员可以带着工作回家，在飞机上，火车上或任何他们喜欢的地方。 他们从不失去版本控制的能力，可以进行适当的提交。
结果是：开发人员对于版本控制系统的行为受公司政策的定义，而非技术限制，您可以随时更改政策。
- rioki
2
你需要考虑几个标准，例如：
如果不是（Base ClearCase），你需要考虑你真正需要导入多少历史记录。
- 你能支持什么样的数据政策（严格的中央存储库，只加载部分数据到开发者工作区，意味着SVN）
- 中央或分散式存储库，是否完全复制历史记录？（像Mercurial或Git这样的DVCS）
- 你可能会遵循什么样的合并工作流程（长期分支与复杂合并，或频繁的rebase）
如果不是（Base ClearCase），你需要考虑你真正需要导入多少历史记录。
- VonC
1
如果你正在迁移离开好老的Clearcase ;-)，快速查看一下Plastic SCM。大部分基本概念仍然存在，但所有痛苦的部分都已经消失了。而且它是分布式的。请查看以下链接： http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html
- pablo
1
这是一篇旧帖子，但我想做出一些贡献。在我看来，SVN已经走过了它的时代。公正地说，如果你有大约50个用户，并且不会分支太多，那么它不会比CC更糟。然而，尽管CC很古老，也很复杂，但它仍具有很多成熟的功能，因此如果你是一个成熟的CC团队，SVN将无法满足你的需求。实际上，最佳实践是尽量少分支并从主干工作。因此，在以上选择中，更好的选择是Hg。此外，我对DVCS有偏见。真正的DVCS只有两个OSS选择：Hg和git，以及目前的一个商业系统：Plastic SCM。如果你习惯于文件历史的可视化表示（vtree浏览器或者CC UCM中的组件树浏览器，我认为它就是这样被称呼的），那么Plastic可能是一个更可行的选择。正如我所见，它具有图形vtree和其他一些东西，例如分支树浏览器。我记得当我支持CC时，我们很多人会轮流在白板上画出“过程”模型。Plastic已经内建了此功能。总之，我对DVCS有偏见......我已经足够忍受SVN和CC以及尝试使用昂贵的复制工具和主控脚本了。DVCS是如此简单！如果你是一个钢铁直男的Linux / Unix开发团队，git可能是更好的选择。如果更多的是Windows或混合环境，则Hg和Plastic看起来是更好的选择，其中Plastic具有更多图形和可视化效果。我认为Hg缺少很多你在CC中习惯的权限控制和访问控制...所以Plastic在这里可能更胜一筹。希望这可以帮到你，祝你好运！
- jimmy2pinz
1
第三方支持。系统是否具有成熟的Visual Studio SCC提供程序？（SVN是，Hg不够成熟）。
Eclipse？两者都有良好的支持。
您的开发人员习惯于成为命令行专家吗？那么第三方支持/插件可能不是问题。
- Garen
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接