8

我们正在从 Clearcase 迁移到另一个 VCS（可能是 SVN 或 Mercurial）。对于已经完成这一转变的公司，他们认为哪些因素在选择另一种 VCS 工具时很重要，他们发现哪些实践可以缓解这种转变？

4

7 回答 7

3

SVN 和 Mercurial 都是很好的 SCM。许多开源项目都使用它们。如果您的选择仅限于这两个，那么您和您的团队必须考虑的是：

工作流程和工作流程

你想如何进行提交和分支？分布式还是纯中心化？这也与公司政策有关。如果您希望一切都集中，请使用 SVN。但这并不意味着您不能使用 Mercurial 拥有中央存储库。如果您的团队选择像 Mercurial 这样的 DVCS，这是非常有益的，因为：

  • 每个人都有自己的本地副本。这使他们能够在家工作并进行本地提交
  • 每个人都可以在他们的本地机器上进行本地分支。不用担心修订之间的合并，Mercurial 对合并的支持很好，相对于 SVN 相对容易。
  • 不是每个人都必须拥有提交访问权限，因为您可以指定某人作为看门人，从其他开发人员的机器中提取修订。这使您能够在将代码提交到中央存储库之前进行代码审查。

除此之外，两者都非常好，因为它们都具有良好（足够）的性能，良好的 Windows 支持（SVN，Hg）和良好的文档/书籍（SVN，Hg）。

于 2009-08-07T23:41:17.923 回答
3

要添加的一对是：

  • 性能：缓慢的开发工具打断了开发者的思维过程
  • 电源（功能性）：合并有多好？git 等较新的工具比 CVS 和 SVN 等旧式工具具有更好的合并支持和跟踪。Git 还提供了非常方便的工具，例如加速开发过程的 bisect。
  • 社区支持：该工具的接受程度如何？您不想选择五年后将处于观望状态的东西。
于 2009-08-07T11:39:33.370 回答
2

您需要考虑几个标准，例如：

  • 你可以支持什么样的数据策略（严格的中央存储库，只有一部分加载到开发人员工作区，即 SVN）
  • 中央或分散的存储库，完整的历史重复？（DVCS，如 Mercurial 或 Git）
  • 您可能会遵循什么样的合并工作流程（具有复杂合并或频繁变基的长期分支）

在迁移（到 SVN 或 Mercurial）方面，如果您使用 ClearCase UCM 会更容易，因为基线表示清晰的“时间线”（最类似于“修订”），您可以使用它来导入其他 (D)VCS .
如果不是（Base ClearCase），您需要考虑您真正需要导入的历史记录部分。

于 2009-08-06T16:36:59.967 回答
2

一般来说，我总是使用分布式版本控制系统 (DVCS)。我没有尝试过 mercurial 但 git；但这里的前提是一样的。

如果您使用集中式系统，则您必须使用该结构。如果您使用分布式系统，则不是。但仅仅因为您可以分发它，您不必这样做。如果在您的团队中拥有一个单一的中央存储库更有意义，那么就这样做。

你不应该低估的是当地分支机构的力量。集中式系统中的分支相当麻烦，开发人员或功能分支很少进行。开发人员宁愿拥有多个工作副本或在其工作副本中保留不安全的更改，以免破坏构建。使用分散式系统，开发人员可以在其上创建本地分支。被一个显示停止错误中断，他切换回主分支修复问题，将更改推送到中央存储库并将更改返回到他的功能分支。工作流程非常流畅。

此外，系统的分布式特性使其成为一个健壮的系统。如果服务器宕机，开发人员照常营业，他们甚至可以在彼此之间交换他们的更改。

最后，开发人员可以将工作带回家、在飞机上、在火车上或任何他们喜欢的地方。他们永远不会失去 VCS 功能并且可以做出正确的提交。

结果是开发人员在 VCS 方面的行为是由公司政策而非技术定义的，您可以随时更改您的政策。

于 2009-09-24T08:18:14.507 回答
1

如果您要从优秀的 Clearcase 迁移出去；-) 快速浏览一下 Plastic SCM。大多数基本概念仍然存在，但所有痛苦的部分都消失了。它是分布式的。检查以下链接： http ://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

于 2010-03-19T23:56:26.407 回答
1

这是一个旧线程，但我想贡献一点。IMO，SVN已经运行它的过程。现在公平地说，如果你有大约 50 个左右的用户并且不做很多分支，那么可以肯定，它不会比 CC 更糟糕。然而，尽管 CC 很古老，也很复杂，但它仍然有很多成熟的功能。所以如果你是成熟的CC店，SVN就满足不了你的需求。事实上，最好的做法是减少分支并在主干上工作。所以更好的选择（鉴于上述选择）将是 Hg。另外，我偏向于dvcs。真正的 dvcs 是……而且只有 2 个 OSS 选择：Hg 和 git。目前有一个商业系统，塑料单片机。如果您习惯于文件历史的可视化表示（vtree 浏览器，或 CC UCM 中的组件树浏览器，认为这就是它的名称），塑料可能是更可行的选择。正如我所看到的，它具有图形 vtree 和其他东西，例如分支树浏览器。我记得支持 CC，我们很多人会轮流在白板上画出“流程”模型。塑料是内置的。无论如何，我再次偏向于 dvcs...我受够了 svn 和 cc 并试图使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！正如我所看到的，它具有图形 vtree 和其他东西，例如分支树浏览器。我记得支持 CC，我们很多人会轮流在白板上画出“流程”模型。塑料是内置的。无论如何，我再次偏向于 dvcs...我受够了 svn 和 cc 并试图使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！正如我所看到的，它具有图形 vtree 和其他东西，例如分支树浏览器。我记得支持 CC，我们很多人会轮流在白板上画出“流程”模型。塑料是内置的。无论如何，我再次偏向于 dvcs...我受够了 svn 和 cc 并试图使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！我记得支持 CC，我们很多人会轮流在白板上画出“流程”模型。塑料是内置的。无论如何，我再次偏向于 dvcs...我受够了 svn 和 cc 并试图使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！我记得支持 CC，我们很多人会轮流在白板上画出“流程”模型。塑料是内置的。无论如何，我再次偏向于 dvcs...我受够了 svn 和 cc 并试图使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！我受够了 svn 和 cc 并尝试使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！我受够了 svn 和 cc 并尝试使用昂贵的复制工具和主控脚本。dvcs就是这么简单！如果你是一个顽固的 linux/unix 开发者，git 可能是一个更好的选择。如果更多的窗户或混合，汞和塑料看起来是更好的选择。更多的图形和视觉效果与塑料。我认为 Hg 错过了很多你习惯使用 CC 的许可和访问控制……所以塑料在这里可能有优势。希望这会有所帮助，祝你好运！

于 2010-10-28T04:47:04.520 回答
1

第三方支持。系统是否有针对 Visual Studio 的成熟 SCC 提供程序？（SVN 是的，Hg 不成熟）。

蚀？两者都有很好的支持。

您的开发人员是否习惯于成为命令行突击队？那么第三方支持/插件可能不是问题。

于 2009-09-05T23:57:27.880 回答