我正在寻找有关在Perforce仓库中创建单个开发分支的可用方法的优缺点的一些反馈。如果我理解正确，有两种方法可以解决这个问题。第一种是创建一个Private分支，它是您正在处理的分支的完整副本。分支将完全独立，并完全隔离您的更改与目标分支。
我听过的另一种方法是Sparse分支。它在Practical Perforce中描述（第9章，第242页）。这将创建一个分支，但仅限于您需要编辑的文件。然后，您将目标分支客户端视图与此稀疏开发分支客户端视图重叠。
这两种方法都需要程序员执行一些集成工作才能在目标分支中进行更改。 Private Branch方法似乎需要更多额外的内存才能创建整个分支的副本。但是，Perforce文档声明它在这种情况下执行“惰性副本”。
集成还使Perforce能够执行文件的“惰性复制”。当你分支 文件，服务器实际上并不包含两个文件副本 - 它只保存源文件，数据库中的指针记录了目标文件的分支发生的事实。懒惰副本使分支成为低开销操作;服务器不必跟踪文件的重复副本。
这使得看起来稀疏分支方法只是向进程添加了人为错误的可能性，例如，开发人员可能开始处理他们没有添加到Sparse分支然后意外更新的文件对打破构建的目标分支的更改。但是，稀疏分支功能存在是有原因的。任何关于它为什么存在的反馈以及为什么我应该在一个完整的私人分支上使用它（反之亦然）将不胜感激。
答案 0 :(得分：3)
正如您在文档空间中所指出的那样，并不是真正的问题。速度虽然如此。同步整个开发树可能需要很长时间。整合回来也需要一段时间。如果您只需要树的一个分支，那么这两个操作都要快得多。
正如您所说，人为错误可能会发生，但如果您制作了branchspec，它可以帮助减轻一些潜在的错误。
答案 1 :(得分：3)
同步速度和客户端磁盘空间是创建完整分支的问题（延迟复制有助于服务器，但不是网络或客户端）。然而，我发现设置和理解比尝试创建稀疏分支更容易，因此完整的分支是我们最终使用的。
答案 2 :(得分：3)
稀疏分支适用的一个好例子是当你有一个可能由很多模块组成的复杂产品时。假设整个系统的构建需要很长时间，也许同步需要一段时间 - 许多数据文件。但是你的开发只需要修改整个源代码库的一小部分 - 可能是一个或两个模块，可能有一些链接代码“更高”。
在这种情况下，做一个稀疏分支可以很有意义。这意味着你已经同步了大部分东西，而且可能已经建成了。但是你必须要小心，你修改的任何文件都是先分支 - 否则你可能会破坏主线。当然，程序员需要更多的关注。
稀疏分支可能是进行分支开发的唯一实用方法的另一种情况是，如果在开发机器上很难有多个版本的应用程序。在这种情况下，同时拥有主线构建和开发构建并且并行运行将是棘手的。显然不理想，但有些产品无论是必要还是历史都是如此。