Perforce Dev 分支 - 稀疏分支与私有分支
我正在寻找一些关于可用于在 Perforce 仓库中创建单独开发分支的方法的优点和缺点的反馈。 如果我理解正确的话，有两种方法可以处理这个问题。 第一个是创建一个私有分支，它是您正在处理的分支的完整副本。 该分支将完全独立，并将您的更改与目标分支完全隔离。
我听说推荐的另一种方法是稀疏分支。 实用 Perforce（第 9 章，第 242 页）对此进行了描述。 这将创建一个分支，但仅包含您需要编辑的文件。 然后，您可以将目标分支客户端视图与此稀疏开发分支客户端视图重叠。
这两种方法都需要程序员执行一些集成工作，以便在目标分支中获得更改。 Private Branch 方法似乎需要更多的额外内存才能创建整个分支的副本。 然而，Perforce 文档指出，它在这种情况下执行“惰性复制”。
集成还使 Perforce 能够执行文件的“延迟复制”。 当你分支时 文件时，服务器实际上并不保存文件的两个副本 - 它仅保存源文件和数据库中的指针记录已发生到目标文件的分支的事实。 惰性复制使分支成为一种低开销的操作； 服务器不必跟踪文件的重复副本。
这使得稀疏分支方法看起来只是在流程中添加了人为错误的可能性，例如，开发人员可能开始处理他们没有添加到稀疏分支的文件，然后意外地将更改更新为破坏构建的目标分支。 但是，稀疏分支功能的存在是有原因的。 任何关于它为何存在以及为什么我应该在完整的私有分支上使用它（反之亦然）的反馈将不胜感激。
I'm looking for some feedback on the advantages and disadvantages of the methods available for creating individual development branches in a Perforce depot. If I understand correctly, there are two ways of handling this. The first is to create a Private branch, which is a complete copy of the branch that you are working on. The branch would completely stand on its own and completely isolate your changes from the target branch.
The other method that I've heard recommended is Sparse branching. It is described in Practical Perforce (Chapter 9, p.242). This creates a branch, but only with the files that you will need to edit. You then overlap the target branch client view with this sparse dev branch client view.
Both methods would require the programmer to perform some integration work in order to get their changes in the target branch. The Private Branch method seems like it would require a lot more additional memory in order to create a copy of the whole branch. However, the Perforce documentation states that it performs a "lazy copy" in this situation.
Integration also enables Perforce to perform a “lazy copy” of the files. When you branch
files, the server does not actually hold two copies of the files - it merely holds the source file and a pointer in the database records the fact that the branch to the target file has occurred. Lazy copies make branching a low-overhead operation; the server doesn’t have to keep track of duplicate copies of files.
This makes it seem like the Sparse branch method is just adding the possibility of human error to the process as, for instance, the developer may start working on a file that they didn't add to the Sparse branch and then accidentally update a change to the target branch that breaks the build. But, the Sparse branching functionality exists for a reason. Any feedback on why it exists and why I should be using it over a complete private branch (or vice versa) would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如您从文档空间中指出的那样，这并不是真正的问题。 速度虽然。 同步整个开发树可能需要很长时间。 整合回来也需要一段时间。 如果您只需要树的一个分支，那么这两个操作都会快得多。
正如您已经说过的，可能会发生人为错误，但如果您制定分支规范，它可以帮助减轻一些潜在的错误。
As you noted from the documentation space is not really an issue. Speed is though. Syncing down the entire development tree may take a long time. The integration back will also take a while. If you only need a branch of the tree then both of those operations are much faster.
Human error, as you already said, can occur, but if you make a branchspec, it can help alleviate some of the potential errors.
同步速度和客户端磁盘空间是创建完整分支的问题（延迟复制对服务器有帮助，但对网络或客户端没有帮助）。 然而，我发现它比尝试创建稀疏分支更容易设置和理解，因此我们最终使用的是完整分支。
Syncing speed and client disk space are the issues with creating full branches (lazy copying helps on the server, but not the network or client). However I found it's easier to setup and understand than trying to create a sparse branch, so full branches are what we end up using.
稀疏分支适合的一个好情况是当您有一个可能由大量模块组成的复杂产品时。 假设整个系统的构建需要很长时间，也许同步也需要一段时间——大量的数据文件。 但是您的开发只需要修改整个源库的一小部分 - 可能是一个或两个模块，可能还有一些“更高层”的链接代码。
在这种情况下，做一个稀疏分支就很有意义。 这意味着您已经同步到大部分内容，并且可能也已经构建了。 但您必须小心，您修改的任何文件都会首先分支 - 否则您将面临破坏主线的风险。 当然，这需要程序员更加细心。
稀疏分支可能是进行分支开发的唯一实用方法的另一种情况是，如果开发计算机上很难拥有多个版本的应用程序。 在这种情况下，并行构建和运行主线构建和开发构建会很棘手。 显然并不理想，但有些产品要么出于必然，要么出于历史原因。
A good situation that sparse branching is suitable for is when you have a complicated product potentially made up of lots of modules. Say the build takes a long time for the whole system, and perhaps the sync takes a while too - lots of data files. But your development only needs to modify a small subset of the whole source base - maybe a module or two, with possibly some linkage code "higher up".
In this case, doing a sparse branch can make a lot of sense. It means you have already synced to the bulk of the stuff, and probably already built too. But you do have to be careful that any files you modify are branched first - otherwise you risk breaking the mainline. Certainly it requires more care by the programmer.
Another case where sparse branching may be the only practical way of doing branched development is if it is hard to have more than one version of your app on a development machine. In this case it would be tricky to have both a mainline build and a development build building and running side by side. Obviously not ideal, but some products are like that either by necessity or history.