我一直使用 Subversion 或 CVS 进行版本控制，它们使用“合并”方法。我的一位朋友对 Perforce 赞不绝口，它的变更列表和签出方法非常棒。
虽然我确信这在很大程度上取决于经验和个人偏好，但我想知道是否已经对哪种版本控制方法更有效地进行了研究？
编辑：澄清一下，我知道 Perforce 和 SVN 都允许锁定和合并，但 SVN '鼓励'自由编辑和合并方法，而据我了解，Perforce 鼓励签出签入方法。
Glenn Slaven
问问题
1504 次
10 回答
6
合并效率更高。原因很简单，同时对同一文件的更改往往很常见，合并允许您从中恢复。相比之下，单次结账可以避免那一点点额外的工作，但这样做的代价是调度效率极低。通常，将两个更改合并到同一个文件需要很短的时间（例如几分钟），而对文件进行更改需要大量时间（例如几个小时或几天），从而阻止访问编辑文件是一个巨大的低效率。
请注意，Perforce 不强制使用结帐方法，它允许并发结帐（相当于合并）。
于 2008-08-26T23:23:54.580 回答
4
老实说，我认为这取决于开发人员的纪律。
我将 Subversion 用于我的个人工作，并且在一些工作中使用过它。我喜欢 Subversion 的一点是，我不必追捕某人并询问他们为什么要做某事以及我是否可以做一些工作。当有人决定开始做某事并且有一段时间没有检查它时，问题就出现了。这可能会使合并变得困难，因为在他们的退房和入住之间进行了一些更改。
我现在使用 Perforce，出于某种原因，我更喜欢 SVN。Perforce 确实给了我一个更好的迹象，表明会有合并冲突，甚至有内置的工具来帮助我解决合并。它有同样的问题，如果有人长时间进行大量更改，合并将更加困难。
基本上，这两种模型都要求您经常检查更改。如果您进行了多次签入，那么您需要合并的可能性就会降低。我经常把东西检查太久而感到内疚。就我个人而言，我觉得 SVN 的价格弥补了它与 Perforce 相比所缺乏的任何东西。我还没有发现它们之间的区别。
于 2008-08-27T19:48:57.443 回答
3
在我们上次的评估中，Perforce 在支持分支和集成分支之间的更改方面击败了颠覆。Subversion 正在努力弥补这个缺点，但我们还没有回来检查它。
在 Perforce 中，当您对文件进行分支时，Perforce 会“记住”它的来源以及哪些修订已“集成”到两个版本中。它还在存储库中进行了一些存储优化，因此在有人对分支进行更改之前，分支副本不会真正实现，然后（如果我理解正确的话），它对基本副本使用差异，就像在一个分支。
Perforce 对分支之间关系的跟踪是一项巨大的资产。如果 Subversion 现在已经实现了，请提醒我。
于 2008-09-05T23:06:08.143 回答
2
也许您的意思是 Source Safe 而不是 Perforce？Perforce 支持合并，事实上，在 SVN 1.5 添加命名合并之前，Perforce 比 SVN 具有更好的合并支持（以及 Perforce 一直拥有的更改列表，我非常想搬到使用 SVN 的商店，但我们赢了' t 升级到 1.5 已经经过了更多时间的测试。）
值得注意的是，SVN 和 Perforce 都允许您进行锁定结帐，因此您可以根据需要执行“未合并”模型，但除了使用版本控制管理二进制文件之外，我认为这没有多大用处。
无论如何，对您的问题的简单回答是“只要涉及一个以上的开发人员，合并模型就会好得多。”
于 2008-08-27T00:13:49.780 回答
1
如果我理解正确，Perforce 会将所有未签出的文件设为只读。这类似于 Microsoft TFS 和 VSS 下的行为。另一方面，Subversion 不设置只读属性。IMO，Subversion 方法更容易，因为您不必为了修改文件而使用源代码控制客户端——您继续进行修改，不计后果地放弃，然后在您准备好时将磁盘上的更改与服务器进行比较办理入住手续。
当所有文件都是只读的时，我发现自己不断地更改文件，尝试保存，发现它是只读的，然后不得不跳到源代码控制客户端检查它。如果源代码控制客户端集成到您的编辑器中，这还不错，但是如果您在版本控制下存储不是源代码的东西，这通常不是一个选择。
于 2008-08-27T00:46:26.473 回答
1
如果我理解正确，Perforce 会将所有未签出的文件设为只读。
这只是默认行为。如果需要，可以将频繁更改的文件设置为读写。在此处查看文件修饰符的完整列表。
此外，对于我的环境，我使用 Eclipse 和Perforce Plugin。使用此插件，编辑文件会立即打开文件进行编辑。
于 2008-08-27T19:38:02.913 回答
0
不确定这项研究，但这里有一个数据点供您参考：
我的团队选择 PVCS（结账）主要是因为舒适。对合并的怀疑和对 Subversion 等工具缺乏认识肯定促成了这一点。
于 2008-08-26T23:40:13.323 回答
0
我不确定我是否理解这里的问题 - 我不知道任何不完全支持合并的现代源代码控制系统（Visual SourceSafe 除外）。
于 2008-08-27T00:04:07.823 回答
0
我绝对更喜欢合并方法。
我用过 Visual Sourcesafe（希望再也不会）、CVS、subversion 和 bzr。Visual sourcesafe 强制执行“编辑前检查”方法，可能会很痛苦。从历史上看，CVS 和 subversion 在接受合并方面并不出色，尽管我听说 subversion 1.5 对此进行了改进。
我建议使用从一开始就考虑到频繁合并的 VCS。bzr 是我用过的那个，但是其他主要的分布式 vcs 系统（git 和 mercurial）也可以。
但最终我不知道有任何关于这个特定领域的研究。一般来说，对编程效率的研究很少，Peopleware是显着的例外之一。
于 2008-08-29T16:14:39.410 回答
0
老实说，我真的不明白这个问题。但我可以保证 Perforce 的效率和处理多人异步修改文件的能力和处理编辑合并的能力。
在 Perforce 中，如果有人签入您也在修改的文件，那么当您下次从服务器同步（即获取最新文件）时，您会收到通知，有一些更改需要解决。何时执行此操作由您决定。当您“解析”一个文件时，它会合并到您的本地版本中 - 这些工具对此很有用。
选择何时执行它很重要 - 您可能正在同步，因此您可以获得一些与您的任务不直接相关的更新（例如错误修复），并且您在那个阶段不想处理如果其他人的工作更改为您正在处理的相同文件会影响您。因此，您继续进行构建和测试，然后在您自己的时间解决文件。
另一种情况是您在未先同步到更新文件的情况下提交编辑。在这种情况下，Perforce 会阻止提交并标记要解析的文件。在这个阶段任何明智的开发人员都会进行合并，然后在将更改提交回 Perforce 之前重新编译和/或测试。
我喜欢这一点的是，它非常努力地阻止您将尚未明确处理的更改提交回中央服务器，从而最大限度地减少破坏构建的机会。解析过程很容易并且开销非常低，因此根本不存在效率问题。
Perforce 非常明确地让您选择和控制更改的传播方式，并使用出色的工具来管理编辑合并。就我个人而言，我喜欢选择和轻松行使选择的权力。毫无疑问，Subversion 也有自己的替代方案。
我想这可能归结为您所习惯的 - 我认为没有显着或可衡量的效率问题。
于 2008-09-26T11:57:09.443 回答