什么是更有效的版本控制方法：结账还是合并？
https://stackoverflow.com/questions/29144
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我一直使用 Subversion 或 CVS 进行版本控制，它们使用“合并”方法。我的一位朋友对 Perforce 赞不绝口，认为它的变更列表和检查方法非常出色。
虽然我确信这很大程度上取决于经验和个人喜好，但我想知道是否已经对哪种版本控制方法更有效地进行了研究？
编辑： 澄清一下，我知道 Perforce 和 SVN 都允许锁定和合并，但 SVN “鼓励”自由编辑和合并方法，而据我了解，Perforce 鼓励签出-签入方法。
解决方案
老实说，我认为这取决于开发人员的纪律。
我在个人工作中使用 Subversion，并且在一些工作中使用过它。我喜欢 Subversion 的一点是我不必追捕某人并询问他们为什么正在做某件事以及我是否可以做一些工作。当某人决定开始做某件事并且有一段时间没有签入时，问题就出现了；这可能会使合并变得困难，因为他们的退房和入住之间会发生一些变化。
我现在使用 Perforce，出于某种原因我更喜欢 SVN。Perforce 确实给了我一个更好的指示，表明将会出现合并冲突，甚至有内置工具来帮助我解决合并问题。它也有同样的问题，如果有人在很长一段时间内进行大量更改，合并将会更加困难。
基本上，这两种模型都要求您经常检查更改。如果您进行多次签入，则可以降低需要合并的可能性。我对东西检查时间太长、太频繁而感到内疚。就我个人而言，我觉得 SVN 的价格弥补了它与 Perforce 相比的不足；我还没发现他们之间有什么区别。
其他提示
合并效率更高。原因很简单，同时对同一文件进行更改往往很常见，而合并可以让您从中恢复。相比之下，单一结账可以避免一点点额外的工作，但这样做的代价是调度效率低下。通常，将两个更改合并到同一文件需要很短的时间（例如分钟），而对文件进行更改则需要大量时间（例如许多小时或几天），因此阻止访问编辑文件的效率非常低。
请注意，Perforce 并不强制采用签出方法，它允许并发签出（相当于合并）。
在我们上次的评估中，Perforce 在支持分支和集成分支之间的更改方面击败了 subversion。Subversion 正在努力弥补这一缺陷，但我们还没有回来检查。
在 Perforce 中，当您对文件进行分支时，Perforce 会“记住”它来自何处以及哪些修订已“集成”到两个版本中。它还在存储库中进行了一些存储优化，以便在有人在分支中进行更改之前分支副本不会真正实现，然后（如果我理解正确的话），它使用与基本副本的差异，就像在一个版本中进行修订一样。分支。
Perforce 对分支之间关系的跟踪是一项巨大的资产。如果 Subversion 现在已经实现了这一点，请通知我。
也许您指的是 Source Safe 而不是 Perforce？Perforce 支持合并，事实上，在 SVN 1.5 之前，它比 SVN 具有更好的合并支持，其中添加了命名合并（以及 Perforce 一直拥有的更改列表，我非常讨厌转向使用 SVN 的商店，但我们不会'直到 1.5 经过更多时间测试后才升级。）
值得注意的是，SVN 和 Perforce 都允许您进行锁定签出，因此您可以根据需要执行“未合并”模型，但除了使用版本控制管理二进制文件之外，我认为这没有多大用处。
不管怎样，你的问题的简单答案是“只要有不止一名开发人员参与，合并模型就会好得多。”
如果我理解正确的话，Perforce 会将所有未检出的文件设为只读。这与 Microsoft TFS 和 VSS 下的行为类似。另一方面，Subversion 不设置只读属性。IMO，Subversion 方法更容易，因为您不必费心使用源代码管理客户端来修改文件 - 您可以不顾一切地进行修改，然后在准备好时将磁盘上的更改与服务器上的更改进行比较办理入住手续。
当所有文件都是只读的时，我发现自己不断地更改文件，尝试保存，发现它是只读的，然后必须跳到源代码管理客户端来检查它。如果源代码控制客户端集成到您的编辑器中，这还不错，但如果您要存储的内容不是版本控制下的源代码，那么这通常不是一个选择。
如果我理解正确的话，Perforce 会将所有未检出的文件设为只读。
这只是默认行为。如果需要，可以将经常更改的文件设置为读写。查看文件修饰符的完整列表 这里.
另外，对于我的环境，我将 Eclipse 与 Perforce 插件. 。使用此插件，编辑文件会立即打开文件进行编辑。
不确定这项研究，但这里有一个数据点供您参考：
我的团队选择 PVCS（结帐）主要是因为舒适。对合并的怀疑以及对 Subversion 等工具缺乏认识肯定是造成这种情况的原因之一。
我不确定我是否理解这里的问题 - 我不知道有任何现代源代码控制系统（Visual SourceSafe 除外）不完全支持合并。
我绝对更喜欢合并方法。
我使用过 Visual Sourcesafe（希望再也不会）、CVS、subversion 和 bzr。Visual Sourcesafe 强制执行“编辑前检查”方法，这可能会很痛苦。从历史上看，CVS 和 subversion 在接受合并方面表现不佳，尽管我听说 subversion 1.5 对此有所改进。
我建议使用从一开始就考虑到频繁合并的 VCS。我使用过的 bzr 可以做到这一点，但其他主要的分布式 vcs 系统（git 和 Mercurial）也可以做到这一点。
但最终我不知道关于这个特定领域的任何研究。一般来说，关于编程效率的研究很少， 人件 是值得注意的例外之一。
老实说，我真的不明白这个问题。但我可以保证 Perforce 的效率和处理多个人异步修改文件以及处理编辑合并的能力。
在 Perforce 中，如果有人签入您也在修改的文件，那么当您下次从服务器同步时（即获取最新文件）您会收到通知，有一些更改需要解决。何时执行此操作的选择取决于您。当您“解析”文件时，它会合并到您的本地版本中 - 这些工具对此很有用。
选择何时执行此操作很重要 - 您可能会进行同步，以便获得一些与您的任务不直接相关的更新（例如错误修复），并且您在那个阶段不想处理其他人的情况更改您正在处理的相同文件将会影响您。因此，您继续进行构建和测试，然后在您自己的时间内解决文件。
另一种情况是您提交编辑时没有先同步到更新的文件。在这种情况下，Perforce 会阻止提交并标记要解析的文件。此阶段任何明智的开发人员都会进行合并，然后重新编译和/或测试，然后将更改提交回 Perforce。
我喜欢这一点的是，它非常努力地阻止您将尚未明确处理的更改提交回中央服务器，从而最大限度地减少破坏构建的机会。解析过程很简单，开销也很低，因此根本不存在效率问题。
Perforce 非常明确地让您选择和控制更改的传播方式，并通过优秀的工具来支持这一点来管理编辑的合并。就我个人而言，我喜欢选择和轻松做出选择的能力。毫无疑问，Subversion 也有自己的替代方案。
我想这可能取决于您的习惯 - 我认为不存在重大或可衡量的效率问题。
