我一直使用Subversion或者CVS进行版本控制，它们使用"合并"方法。我的一位朋友对Perforce以及它的变更列表和结帐方法有多好赞不绝口。

虽然我确定很多都取决于经验和个人喜好，但我想知道是否已针对哪种版本控制方法更有效地进行了研究？

编辑：为澄清起见，我知道Perforce和SVN都允许锁定和合并，但是SVN鼓励使用自由的编辑和合并方法，而据我所知，Perforce鼓励使用check-checkin方法。

解决方案

回答

合并更有效。出于简单原因，同时更改同一文件通常很常见，而合并使我们可以从中恢复。相比之下，单次签出可以避免一点点额外的工作，但是这样做却以调度效率低下为代价。通常，将两个更改合并到同一文件中需要花费很短的时间(例如，几分钟)，而对文件进行更改则需要花费大量的时间(例如，数小时或者数天)，以防止访问编辑文件效率低下。

请注意，Perforce不会强制执行签出方法，它允许并发签出(等同于合并)。

回答

不确定这项研究，但是这里有一个数据点适合我们：
我的团队选择PVCS(结帐)主要是因为舒适。对合并的怀疑和对Subversion等工具的缺乏意识肯定是造成这种情况的原因。

回答

我不确定我是否理解这里的问题，我不知道任何不完全支持合并的现代源代码控制系统(Visual SourceSafe除外)。

回答

也许我们是说Source Safe而不是Perforce？ Perforce支持合并，实际上比SVN具有更好的合并支持，直到添加了命名合并的SVN 1.5(以及变更列表，Perforce一直拥有，并且我很想搬到使用SVN的商店，但我们不会这样做)。请升级到1.5，直到经过更多时间测试为止。)

值得注意的是，SVN和Perforce都允许我们执行锁定的签出，因此我们可以根据需要执行"未合并"模型，但是除了使用版本控制来管理二进制文件外，我看不出有什么用。

无论如何，对问题的简单答案是："只要涉及一个以上的开发人员，合并模型就会变得更好。"

回答

如果我理解正确，Perforce会将未检出的所有文件设为只读。这类似于Microsoft TFS和VSS下的行为。另一方面，Subversion不会设置只读属性。 IMO，Subversion方法更容易，因为我们不必费心去修改文件的源代码控制客户端-我们可以继续进行鲁modify的修改，然后在准备好将磁盘上的更改与服务器进行比较时报到。

当所有文件都是只读的时，我发现自己不断地更改文件，尝试保存，发现它是只读的，然后不得不跳到源代码控制客户端以将其检出。如果将源代码控制客户端集成到编辑器中，还不错，但是如果要在版本控制下存储不是源代码的内容，则通常不是一个选择。

回答

If I understand correctly, Perforce makes all files that are not checked out read-only.

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

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

回答

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

我将Subversion用于个人工作，并且在一些工作中使用它。我喜欢Subversion的地方是，我不必追捕某个人，也不必问他们为什么要从事某项工作，并且我可以做一些工作是否可以。问题出在某人决定开始处理某件东西而暂时不检入时。这可能会使合并变得困难，因为在签出和签入之间进行了几处更改。

我现在使用Perforce，由于某种原因，我更喜欢SVN。 Perforce无疑给了我一个更好的指示，即将发生合并冲突，甚至还有内置工具可以帮助我解决合并问题。同样的问题是，如果有人长时间进行大量更改，合并将更加困难。

基本上，这两种模式都要求我们经常签入更改。如果我们进行了大量签入，则可以减少需要合并的可能性。我有罪，因为经常把东西拖延太长时间。我个人认为，与Perforce相比，SVN的价格可以弥补它所缺少的一切。我还没有发现它们之间的区别。

回答

我绝对更喜欢合并方法。

我使用了Visual Sourcesafe(希望不再使用)，CVS，subversion和bzr。 Visual Sourcesafe强制执行"编辑前检出"方法，可能会很痛苦。从历史上看，CVS和Subversion并不是很擅长接受合并，尽管我听说Subversion 1.5对此进行了改进。

我建议从一开始就使用已考虑频繁合并的VCS。我曾经使用bzr来做到这一点，但是其他主要的分布式vcs系统(git和mercurial)也可以做到。

但是最终我对这个特定领域一无所知。通常，很少有关于编程效率的研究，Peopleware是值得注意的例外之一。

回答

在我们的上一次评估中，Perforce在支持分支和集成分支之间的更改方面击败了Subversion。 Subversion的工作正在进行中，以弥补这一缺点，但我们还没有回来进行检查。

在Perforce中，当我们分支文件时，Perforce会"记住"文件的来源以及将哪些修订"集成"到两个版本中。它还在存储库中进行了一些存储优化，因此直到有人对分支进行更改后，分支副本才真正实现，然后(如果我理解正确)，它对基本副本使用diff，就像分支。

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

回答

老实说，我真的没有这个问题。但是我可以保证Perforce的效率和能力，可以处理多个人非同步地修改文件以及合并编辑内容。

在Perforce中，如果有人签入我们也在修改的文件，则当我们下次从服务器进行同步(即获取最新文件)时，我们会得知需要解决一些更改。何时执行此操作的选择取决于我们。当我们"解析"文件时，它会合并到本地版本中，这些工具非常有用。

选择何时进行是很重要的，因为我们可能正在同步，以便可以获取与任务不直接相关的某些更新(例如错误修正)，并且在那个阶段，我们不希望解决其他人的更改到我们正在处理的相同文件会影响我们。因此，我们继续进行，进行构建和测试，然后在自己的时间内解析文件。

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

我喜欢它的原因是，它非常努力地阻止我们将尚未明确处理的更改提交回中央服务器，从而最大程度地减少了破坏构建的机会。解决过程很容易且开销很低，因此根本没有效率问题。

Perforce非常明确地为我们提供选择和控制更改传播方式的方法，并通过出色的工具来管理编辑合并来支持这一点。我个人喜欢选择，并且喜欢轻松地行使选择的能力。毫无疑问，Subversion也有自己的替代方案。

我想这可能归结为我们所习惯的，我认为没有重大或者可衡量的效率问题。