Perforce Dev Branches - Sparse Branching vs. Private Branching

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.