FAQ: Path Space Branching — a critique

Summary

Path space branching is more some sort of forking than real branching.
It has some clear drawbacks with respect to (typed) branching:

It makes auditing based management virtually impossible, and thus limits the tool support to the realm of crude source control
It discourages parallel development in different branches, by hiding actual changes among pessimistic systematic change of (path based) identity of all the files.

It results from the decision of committing (atomarily) whole directory trees. Together, the two...

...couple concerns which should be kept distinct on the directory structure (design, locality of changes, build performance), which artificially raises the pressure to tweak it continuously.

Detail

Perforce, and subversion implement branches in a way which departs from the concept of typed branches as e.g. in ClearCase. Let's call this path space branching, and try to make it clear what the consequences of this departure are.
Note: I cannot claim making a neutral analysis—I am seriously biased toward SCM based on auditing, in a tradition borne with (base) ClearCase. Also, I have no practical experience of Perforce, so my critique is based on subversion.

The creation of a branch in subversion is exactly similar as this of a tag: you do it with svn copy and the result is similar to a NetApp snapshot, i.e. roughly a duplicate of a directory tree, with hard links pointing to the current versions of file objects [I must admit that this is my understanding: I'm happy to get corrected if wrong]. A better name should be found than either tags or branches which would be common to both; I'd suggest forks.
There is no specific support for branching related functionality, which would differ from tags (including svn merge): the difference is purely conventional, all in the name of root directories.
The creation of a branch affects the a whole directory tree, at creation time, whether or not there are any differences in the contents of the branched files—at svn copy time, there are none.
This would be catastrophic if subversion wasn't exclusively a revision control system: all absolute references to the files are coupled to the branch choice.
Of course, the decoupling between file and version selection (essential for configuration item support) occurs at checkout to the working copy: there the paths are only relative, and lose any binding to the branch selection. Even svn update commands (possibly run in crontabs) are agnostic to the selection criteria.
But working copies are fully outside the scope of the management.
- The output of svn info anywhere in the working copy is bound to the full paths, so path space branching makes a hypothetic workspace management difficult (need to identify configuration items mapped to different paths in a plain file system).
Whereas there is no real duplication of information at branch creation, any file object added under a branch (whether in a working copy as in the most usual scenario, or even directly to the repository with svn mkdir) will run the risk of becoming an evil twin if the user is not particularly careful, or work is not exclusively done in one and one single branch.
- The last clause above shows the most common scenario used in practice: work is performed in the branch, thus protecting the trunk (main line), and regularly merged there in a controlled way.
- This process shows a good practice, and presents a clear advantage over working directly in the trunk, but doesn't really depart from the /main/LATEST syndrome.
- It may seem that this doesn't relate to path space branching. Here is how it does, indirectly:
  - Real parallel development is not supported.
  - With it, you inevitably get into evil twins, because you add file objects not knowing what others do.
  - Avoiding evil twins with ClearCase is possible on the basis of public and concise information (only modified objects are branched).
In any case, what is totally jeopardized by path space branching, is workspace management based on auditing in-place in a multi-version file system.