11

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

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

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

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

这使得 Sparse 分支方法看起来只是在流程中增加了人为错误的可能性，例如，开发人员可能开始处理他们没有添加到 Sparse 分支的文件，然后不小心将更改更新为破坏构建的目标分支。但是，稀疏分支功能的存在是有原因的。任何关于它存在的原因以及为什么我应该在完整的私有分支上使用它（反之亦然）的反馈将不胜感激。

4

3 回答 3

3

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

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

于 2009-04-07T22:00:46.903 回答
3

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

于 2009-04-08T08:23:03.663 回答
3

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

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

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

于 2009-04-09T10:43:19.013 回答