关于svn：什么是更有效的版本控制方法：签出或合并？

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

虽然我敢肯定很多东西都归结为经验

---

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

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

---

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

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

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

基本上，两个模型都要求您经常签入更改。如果您进行大量签入，则可以减少需要合并的可能性。我对把东西拖延太长时间感到内。我个人认为，与Perforce相比，SVN的价格可以弥补其所缺乏的任何东西。我还没有发现它们之间的区别。

---

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

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

Perforce对分支之间关系的跟踪是一项巨大的财富。如果Subversion现在已经实现了此功能，请引起我的注意。

---

也许您是说Source Safe而不是Perforce？ Perforce支持合并，实际上比SVN具有更好的合并支持，直到添加了命名合并的SVN 1.5(以及变更列表，Perforce一直拥有该列表，我很想搬到使用SVN的商店，但我们会\\直到对1.5进行更多时间测试后才能升级。)

值得注意的是，SVN和Perforce都允许您执行锁定的签出，因此，如果需要，您可以执行"未合并"模型，但是除了使用版本控制来管理二进制文件外，我不\\对此没有多大用处。

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

---

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

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

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

---

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

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

---

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

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

选择何时执行是很重要的-您可能正在同步，因此可以获得与任务没有直接关系的更新(例如bugfix)，并且您在那个阶段不想处理工作如果别人对您正在处理的相同文件进行更改会影响您。所以你继续做下去

---

我绝对更喜欢合并方法。

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

我建议一开始使用VCS，该VCS的设计考虑了频繁合并的问题。 bzr是我使用过的一种，但是其他主要的分布式vcs系统(git和mercurial)也可以做到。

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

---

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

---

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

---