Presentation abstract

Staging one's deliverables means storing them as elements.
There are many reasons to stage, not all fully recommendable:

• Ensuring the permanence of the storage, but isn't it a lack of confidence in the reproducibility, and a mere side-effect?
• Offer visibility through replication.
• Enhance the build performance.
• Allow to hide the actual sources.

On the other hand, certain situations, identified during the development, make us reopen the boundaries of elements. If these had instead been derived objects, the management of the information would have been more natural. A few patterns are:

• Merging information from two elements or more.
• Splitting a file in two.
• Maintain both an element and a derived object copies of a file.

Elements have no generic structure of their own: they are flat. Focusing management on elements leads to rely upon the specific structure of directory trees and other representations for projects, i.e. upon intentions more than observable reality. This impairs sharing and reuse.
Derived objects on the contrary have a native and generic structure: this of dependency trees. Optimizing the promotion and sharing of derived objects is a laudable motivation, for designing both build systems and branching strategies.

Unstaging can be interpreted as making derived objects the real first-class citizens of SCM, thus reversing the historical perspective embodied in the staging practice.