Perforce Dev分支-稀疏分支与私有分支

Question

我正在寻找一些关于在Perforce仓库中创建单个开发分支的方法的优缺点的反馈。如果我理解正确，有两种方法来处理这个问题。第一种方法是创建一个私有分支，它是您正在处理的分支的完整副本。分支将完全独立，并且完全将您的更改与目标分支隔离开来。

我听说过的另一个方法是稀疏分支。它在实用Perforce中作了描述(第9章，第242页)。这将创建一个分支，但只使用您需要编辑的文件。然后，将目标分支客户端视图与这个稀疏的dev分支客户端视图重叠。

这两种方法都需要程序员执行一些集成工作，以便在目标分支中得到它们的更改。私有分支方法似乎需要更多的额外内存才能创建整个分支的副本。然而，Perforce文档指出，它在这种情况下执行“延迟复制”。

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

这使得稀疏分支方法似乎只是向流程中添加了人为错误的可能性，例如，开发人员可能会开始处理他们没有添加到稀疏分支的文件，然后意外地更新对破坏构建的目标分支的更改。但是，稀疏分支功能的存在是有原因的。任何反馈，为什么它存在，为什么我应该使用它在一个完整的私人分支(反之亦然)，将不胜感激。

Answer 1

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

正如您已经说过的那样，可能会发生人为错误，但是如果您制定了分支规范，它可以帮助减轻一些潜在的错误。

Answer 2

同步速度和客户端磁盘空间是创建完整分支的问题(延迟复制有助于服务器，而不是网络或客户端)。然而，我发现它比尝试创建一个稀疏的分支更容易设置和理解，所以我们最终使用的是完整的分支。

Answer 3

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

在这种情况下，做一个稀疏的分支很有意义。这意味着你已经同步到大部分的东西，并且可能已经建立了。但是，您确实必须小心，您修改的任何文件都必须首先进行分支，否则就有可能破坏主线。当然，它需要程序员更多的关注。

另一种情况是，稀疏分支可能是进行分支开发的唯一实用方法，如果开发机器上很难有多个版本的应用程序。在这种情况下，将主线构建和开发构建并行运行是很棘手的。显然不理想，但有些产品是这样的，无论是出于必要性还是历史。