Many projects evolve through a prescribed or regulated group of stages that
require engineering, administrative, or legal approval before proceeding to the
next stage. For example, within the utility domain, common project stages include
working, proposed, accepted, construction, and as built. This particular process
is essentially cyclical; a work order is initially assigned to an engineer and
modified over time as the project evolves through the various stages before full
integration with the production database.
In this approach, a version is created to represent each stage of this
process: initial design or proposal, an approved version, and a version
for the construction phase. As the project advances through the project
milestones, each stage is reviewed and approved then superseded by the next
version until the last stage is reached and completed. The older versions may be
maintained for historical reference or deleted as required.
Once the project is complete, the constructed version can be reconciled with and
posted directly to the DEFAULT version, without having to reconcile and post
with the previous versions in the lineage.
Pros
- Suitable for projects that evolve through a series of stages, where each stage
must be isolated as a distinct unit of work.
- As with all other multiple-tier configurations, this workflow allows editors to
develop proposals and design alternatives without affecting the production
database.
- Changes can be posted directly to DEFAULT, which eliminates the overhead of
progressively posting changes up the version tree to the DEFAULT version.
Cons
- Not suitable for batch reconcile and post processes, because any implementation would
require a great deal of application logic to determine which versions to
reconcile and post.
|