You didn’t read/understand the “Workspaces” paper: there are no branches in it at all.
You are misunderstanding the usage of the word ‘merge’ — I am using it in the sense of how compilation is a set of sources “merged” together. The Workspaces paper’s nodes are not “branches” but “working sets” the eponymous workspaces. Consider the dependency graph for the following:
With pkg_Alpha.pkg_Beta, pkg_Alpha.pkg_Gamma.pkg_Delta, pkg_Epsilon;
Function pkg_Xi.fn_Omega return pkg_Xi.Some_Type;
The graph could be represented as the dependency-set/-tree:
Module_B
\ \
\ pkg_Alpha
Module_C
\ \ \
\ \ pkg_Alpha.pkg_Beta
\ pkg_Alpha.pkg_Gamma
pkg_Alpha.pkg_Gamma.pkg_Delta
Module_A
\ \
\ pkg_Epsilon
Module_B
Module_D
\ \ \
\ \ Module_A
\ pkg_Xi
pkg_Xi.pkg_Omega
In the above, Module_B
is consistent only when pkg_Alpha
+Module_C
(children of pkg_Alpha
) are consistent, thus when Module_B
represents the set of pkg_Alpha
and its children being consistent/compliable.
Module_B
can then be merged into the set of Module_B
+pkg_Epsilon
to yield Module_A
; thus “Module_A
” represents the dependencies of pkg_Xi.fn_Omega
and can be merged together with the explicit dependencies (Module_A
) and the implicit dependencies (pkg_Xi
) to yield the project’s dependencies.
Now consider “merge” and “compile together” as roughly synonymous, and you get the compiler’s method for handling a compilation-unit… consider the nodes as sets of program-sources (which may or may not be tied to child-packages, but are probably tied to subsystems), and those are the “workspaces”. Consider the “Merging Upward” as compiling/consistency-checking/proving/etc, or as committing into the repository —that these levels in the tree are hierarchical database entries, and the merge upward is committing into the next higher level— and now you can see that the root node’s history IS the history of the states wherein the project is compliable.
Which is the advantage of the system in the Workspaces paper: there are no branches, only working-sets, and they are only “merged in” when things “at that ‘level’” are consistent. – You can never have an instance where you have a “non-compliable” root-node because by design the root node is only updated when “everything below” is consistent: there’s no more “Dave broke the build”.
I disagree: as a rule, there should be no “files” or “source-texts” — rather the sources should be DB-amiable structures: let the system handle the interface with your local computer, whether that’s FS files, or IDE-elements using the same DB-amiable structures.
(Yes, there are other resources, like music, or fonts, or 3D-textures, or images that may be needed; these are, however, arguably beyond the scope of CI/CD and the “normal case” of source is what we’re discussing.)