Perforce开发分支 - 稀疏分支与私有分支

Question

我正在寻找一些有关在Perforce仓库中创建各个开发分支的方法的优缺点的反馈。如果我理解正确，有两种处理方法。首先是创建一个专用分支，它是您正在开发的分支的完整副本。该分支将完全独立并完全隔离目标分支上的更改。

我听说过的另一种方法是推荐使用稀疏分支。它在Practical Perforce（第9章，第242页）中有描述。这会创建一个分支，但仅限于需要编辑的文件。然后，您将目标分支客户端视图与此稀疏开发分支客户端视图重叠。

这两种方法都需要程序员执行一些集成工作，以便在目标分支中获得更改。 Private Branch方法似乎需要更多的额外内存才能创建整个分支的副本。但是，Perforce文档声明它在这种情况下执行“懒惰拷贝”。

集成还使Perforce能够执行文件的“延迟复制”。当您分支 文件时，服务器实际上并不拥有文件的两个副本 - 它仅保存源文件，数据库中的指针记录了发生到目标文件的分支的事实。延迟副本使分支成为低开销操作;服务器不必跟踪文件的重复副本。

这使得它看起来像稀疏分支方法只是增加了人为错误的可能性，例如，开发人员可能会开始工作的文件，他们没有添加到稀疏分支和那么意外更新了对打破构建的目标分支的更改。但是，Sparse分支功能存在是有原因的。任何反馈意见，为什么它存在，为什么我应该使用它在一个完整的私人分支（反之亦然）将不胜感激。

Answer 1

正如您从文档中注意到的那样，并不是一个真正的问题。速度虽然。同步整个开发树可能需要很长时间。整合回来也需要一段时间。如果你只需要树的一个分支，那么这两个操作都要快得多。

正如您所说，人为错误可能会发生，但是如果您制作branchspec，它可以帮助减轻一些潜在的错误。

Answer 2

同步速度和客户端磁盘空间是创建完整分支（懒惰复制帮助服务器，但不是网络或客户端）的问题。然而，我发现设置和理解比创建稀疏分支更容易，所以完整分支就是我们最终使用的。

Answer 3

稀疏分支适合的一个很好的情况是当您有一个复杂的产品可能由大量模块组成。假设整个系统的构建需要很长时间，并且也许同步需要一段时间 - 很多数据文件。但是你的开发只需要修改整个源代码库的一小部分 - 可能是一个或两个模块，可能有一些链接代码“更高”。

在这种情况下，做一个稀疏的分支可以有很大的意义。这意味着你已经同步了大部分内容，并且可能已经建立了。但是你必须小心，你修改的任何文件都是先分支的 - 否则你冒险破坏主线。当然，它需要程序员更多的关心。

另一种情况下稀疏分支可能是做支发展的唯一可行的方法是，如果它是很难有你的应用程序的多个版本在开发机器上。在这种情况下，建立一个主线和一个开发版本并且并行运行是非常棘手的。显然不理想，但有些产品就像是必然或历史。