什么是更有效的版本控制方法：结帐或合并？

Question

我一直使用Subversion或CVS进行版本控制，它使用“合并”方法。我的一个朋友对Perforce赞不绝口，它的变更清单和签出方法有多棒。

虽然我确信很多都归结为经验和个人偏好，我想知道是否有任何研究已经完成哪种版本控制方法更有效？

编辑：为了澄清，我知道Perforce＆amp; SVN允许锁定＆amp;合并，但SVN'鼓励'自由编辑＆amp;合并方法，而据我了解，Perforce鼓励结帐 - 签入方法。

Answer 1

合并更有效率。原因很简单，同时对同一文件的更改很常见，而merge允许您从中恢复。相比之下，单一结账可以防止一点点额外的工作，但这样做会导致调度效率低下。通常，将两个更改合并到同一文件（例如几分钟）需要很短的时间，而对文件进行更改需要花费大量时间（例如，数小时或数天），以防止访问编辑文件是一个巨大的低效率。

请注意，Perforce不强制结帐方法，它允许并发签出（相当于合并）。

Answer 2

老实说，我认为这取决于开发人员的纪律。

我将Subversion用于个人工作，并且我在一些工作中使用它。我喜欢Subversion的是，我没有必要找一个人，问他们为什么要做某事，如果我能做一些工作。当有人决定开始处理某些事情并且暂时没有检查时，就会出现问题;这可能会使合并变得困难，因为在退房和办理登机手续之间会有一些变化。

我现在使用Perforce，出于某种原因，我更喜欢SVN。 Perforce肯定能让我更好地表明存在合并冲突，甚至还有内置工具来帮助我解决合并问题。它有同样的问题，如果有人在很长一段时间内进行了大量的更改，合并将会更加困难。

基本上两种型号都要求您经常检查更改。如果您进行大量签到，则可以降低您需要合并的可能性。我太过于经常检查太久的东西了。就个人而言，我觉得SVN的价格标签弥补了Perforce所缺少的任何东西;我还没有找到它们之间的区别。

Answer 3

在我们的上一次评估中，Perforce在支持分支和集成分支之间的变化方面击败了颠覆。 Subversion正在努力弥补这一不足之处，但我们还没有回来查看它。

在Perforce中，当您分支文件时，Perforce会“记住”它来自何处以及哪些修订已“集成”到两个版本中。它还在存储库中进行了一些存储优化，这样分支副本就不会真正实现，直到有人在分支中进行更改，然后（如果我理解正确），它会对基本副本使用差异，就像在分支。

Perforce对分支机构之间关系的跟踪是一项巨大的资产。如果Subversion现在已经实现了这一点，请给我一个提醒。

Answer 4

也许你的意思是Source Safe而不是Perforce？ Perforce支持合并，实际上比SVN有更好的合并支持，直到添加了命名合并的SVN 1.5（以及更改列表，Perforce一直有，我非常想搬到使用SVN的商店，但我们赢了' t升级直到1.5经过一段时间的测试。）

值得注意的是SVN和Perforce都允许你进行锁定结账，所以如果你愿意，你可以做“未合并”的模型，但除了管理带有版本控制的二进制文件之外，我看不出太多用处这个。

无论如何，对你的问题的简单回答是“合并模型在涉及多个开发人员的任何时候都要好得多。”

Answer 5

如果我理解正确，Perforce会将所有未检出的文件设为只读。这类似于Microsoft TFS和VSS下的行为。另一方面，Subversion不设置只读属性。 IMO，Subversion方法更容易，因为您不必为了修改文件而烦恼源控制客户端 - 您继续进行修改并放弃鲁莽，然后在准备好时将磁盘上已更改的内容与服务器进行比较办理登机手续。

当所有文件都是只读文件时，我发现自己经常更改文件，尝试保存，发现它是只读的，然后必须跳到源控制客户端检查它。如果将源代码控制客户端集成到您的编辑器中，它就不那么糟糕了，但是如果您在版本控制下存储的不是源代码，那么这通常不是一种选择。

Answer 6

  

如果我理解正确，Perforce会将所有未检出的文件设为只读。

这只是默认行为。如果需要，可以将频繁更改的文件设置为读写。查看文件修饰符here的完整列表。

另外，对于我的环境，我使用的是Eclipse Perforce Plugin。使用此插件，编辑文件会立即打开文件进行编辑。

Answer 7

不确定研究，但这里有一个数据点：
我的团队选择PVCS（结账）主要是因为舒适。关于合并和对Subversion这样的工具缺乏认识的疑问肯定有助于此。

Answer 8

我不确定我在这里理解这个问题 - 我不知道任何现代的源代码控制系统（Visual SourceSafe除外）并不完全支持合并。

Answer 9

我绝对更喜欢合并方法。

我使用了Visual Sourcesafe（希望再也没有），CVS，颠覆和bzr。 Visual sourcesafe强制执行“编辑前检出”方法，可能很痛苦。 CVS和颠覆在历史上接受合并并不是很好，尽管我听说颠覆1.5已经改善了。

我建议使用从一开始就考虑频繁合并的VCS。 bzr是我用过的那个，但是其他主要的分布式vcs系统（git和mercurial）也可以。

但最终我不知道有关这个特定领域的任何研究。一般来说，对编程效率的研究很少，Peopleware是一个值得注意的例外。

Answer 10

说实话，我真的不明白这个问题。但我可以保证Perforce的效率和处理不止一个人异步修改文件的能力，以及处理编辑合并的能力。

在Perforce中，如果有人签入您正在修改的文件，那么当您下次从服务器同步（即获取最新文件）时，您会收到一些需要解决的更改。选择何时执行此操作取决于您。当您“解析”某个文件时，它会合并到您的本地版本中 - 而且这些工具对此很有用。

选择何时进行操作非常重要 - 您可能正在同步，因此您可以获得一些与您的任务没有直接关系的更新（比如说错误修复），并且您在那个阶段没有想要处理工作如果其他人改变你正在处理的相同文件会影响你。所以你继续，做你的构建＆amp;测试，然后在你自己的时间解析文件。

另一种情况是您在未首先同步到更新文件的情况下提交编辑。在这种情况下，Perforce会阻止提交并标记要解析的文件。在此阶段，任何合理的开发人员都会进行合并，然后重新编译和/或测试，然后再将更改提交回Perforce。

我最喜欢的是，它非常难以阻止您将更改提交回未经显式处理的中央服务器，从而最大限度地减少了破坏构建的可能性。解决过程很简单且开销很低，因此根本没有效率问题。

Perforce非常明确地让您选择和控制如何传播更改，并使用优秀的工具来管理合并编辑。我个人喜欢选择和轻松做出选择的能力。毫无疑问的Subversion也有自己的替代品。

我想这可能归结为你习惯的东西 - 我不认为存在重大或可衡量的效率问题。