Version Management Revisited
Using traditional version management with merge and post
Traditional version management, using only merge and post operations between parent and
child alternatives, has some limitations in meeting the requirements laid out in the previous
section. The requirement for the as-built view is that it should be cleanly separated from any
work in progress. If the data for a design is stored in an alternative until the work is
completed in the field (i.e., until it becomes as-built), and it is posted at this point, then the
requirement for having an as-built view is satisfied. In this scenario, the top alternative
always represents the as-built view. However, this approach does not handle the future as-
built view well, since all designs are in their own alternatives and they cannot be combined
easily. It is possible to implement a multiple work order view using this approach if the
drawing routines are flexible enough to change alternatives dynamically to draw relevant
information from each design of interest. However, this merely provides a graphical view,
not one that can be queried.
A fairly common alternative approach is to post jobs to top once they are approved, but
before they are built. This enables better handling of both the multiple work order view and
the future as-built view, but introduces some compromises into the as-built view.
When using this approach, a necessary addition is to have some sort of explicit relationship
between a work order object and the objects that belong to that work order, in order to
identify the elements of the work order in the top version of the database.
Since data is posted to top before it is "as-built" in this approach, the "as-built" view needs to
be created by adding application functionality on top of the database. Visually, an "as-built"
view can be achieved by making objects with a status of "Proposed" or "Replacing" invisible,
while displaying objects with a status of "Existing", "To be replaced", or "To be removed".
All the visible objects are displayed with the same "as-built" style. For query and analysis
operations, some more care is required to provide the as-built view. For (topology based)
network tracing, this can be done reasonably well by setting up connectivity rules so that
Proposed or Replacing geometry does not connect to geometry with any other status. For
queries and reports (such as listing all transformers in a tax district), it is necessary to make
sure that an additional predicate is added to only include objects with appropriate status
values.
While this approach is acceptable for certain applications with a well known set of
operations, it does not work as well in certain situations - especially if the data model has
many relationships. If, for example, you want to query from a rack to the shelves inside it to
the cards on the shelves, it is very inconvenient and error-prone to have to validate the status
of every record as you do these joins.
While this approach introduces these compromises into the as-built view, the advantage is
that it supports the multiple work order view and the future as-built view better than the other
options considered so far. The multiple work order view is generated by making all objects
visible and using the same styles (dependent on status) which are used in the individual work
order view. A future as-built view can be generated by creating an alternative, selecting the
work orders which we want to complete in this view, and going through the completion
process in that alternative (converting "Proposed" to "Existing", deleting "To be removed",
etc.).
In addition, this approach can support the idea of "partial completion" (a.k.a., "partial
posting") reasonably well. A user can select a subset of a work order and apply the necessary
status changes to convert the subset to "Existing". There are still potential
consistency/integrity issues, especially with complex data models, but in general it is a
workable approach for reasonably simple models.
The sideways merge approach
Both approaches described in the previous section have some drawbacks. The one in which
jobs are not posted to top until they are completed does a good job of modeling the "as-built"
network cleanly with no interference from proposed work, but it is poor at handling the
multiple work order and future as-built views. The second approach addresses the latter two
problems much better, but introduces potentially serious compromises for the as-built view,
especially for complex data models. This makes it unsuitable as a generic solution.
The “sideways merge” approach introduces some new ideas, which are a significant step
forward in tackling this problem. It uses the top alternative strictly for storing as-built data,
as in the first option above. This gives the advantage of providing a very clean and generic
way of separating proposed work from the current network, as noted before.
The sideways merge is an operation that allows changes from one alternative to be applied to
another alternative elsewhere in the hierarchy, instead of restricting changes to being
propagated only to immediate parent or child alternatives, which is what traditional merge
and post operations do. This technique can be used to create either future as-built views or
multiple work order views, by copying data from all the relevant design alternatives into a
new alternative. Another way to implement the multiple work order view, which is
appropriate when a small number of jobs need to be displayed graphically in addition to the
current job, is to implement the ability for the drawing routines to render graphics from more
than one alternative on the fly.
While the sideways merge is a fairly complex operation to implement robustly, it is a very
clean approach, and is by far the best solution of those discussed here.
Phased completion of jobs
Jobs built on jobs
An additional requirement is that it may be necessary to create a design that is dependent on
another design that has not yet been built. In general, this is more common in
communications than in utilities. In communications in particular, there is a requirement to
record which jobs are dependent on other jobs, and to easily distinguish which subsequent
jobs are affected if a given job is cancelled or rescheduled. There are at least two concepts
that are important when implementing a full solution to this problem. One is to be able to
create a "future as-built" view on which the new job can be based (by selecting the other jobs
on which this job is dependent, and by making those jobs look as if they have been
completed). The second concept is that when the job is completed, some sort of validation is
required to determine that the necessary work in jobs that it was dependent on has also been
completed. In some cases, there may also be a requirement that if a job is cancelled, any
dependent jobs need to be checked to see if they are still valid. In general, this sort of
validation is very application-specific.
Partial Completion (partial posting)
Sometimes a job may be completed in several pieces, each of which needs to be converted to
become "as-built" independently. If this phasing is known in advance, the problem is the
same as the previous one (jobs built on jobs). If not, the issue is a little different. This is an
interesting problem, in the sense that it may seem straightforward to the casual observer who
hasn’t studied the problem in detail, but in fact it is extremely complex to implement a
generic solution. The difficulty is making sure that the subset of data that is "posted" (in a
general sense, not necessarily in a strict version management sense) is completely consistent.
This is very similar to the task of ensuring consistency in a spatial replica or an extract of a
database, and it is possible for most applications to set up a framework to ensure that the
chosen subset of data is consistent (in conjunction with appropriate application specific
rules).
Identifying potential conflicts early
The optimistic concurrency control and conflict resolution used by version management has
been proven to work very well in production systems. However, it is desirable to highlight
and avoid potential conflicts wherever possible. One common approach is for a user to
sketch a rough outline of the area that they expect their design to cover before they start it.
This is either stored in a short transaction partition, or posted to top immediately, so that it is
visible to all users. A test is then run to see if this area overlaps with any other currently
active jobs. If so, both the current user and the owners of the overlapping jobs are notified so
that they can investigate further what the other jobs involve, and whether they are likely to
conflict with each other. This is independent of the other issues covered here, but it is worth
mentioning as a useful technique to use in conjunction with version management.
Mobile design
There is a very strong requirement to be able to carry out design operations in the field and
synchronize these with the central database. This could include both the initial creation of
the design and the process of making as-built changes. Therefore, it is important that the
version management approach can support the appropriate use of detached databases. This
will not be discussed in detail in this paper due to lack of space, but it is a complex topic in
its own right.
Archiving and historical information
Another common requirement is the ability to look back in time. Requirements vary
extensively in this area. At a simple level, many companies require work orders to be
archived for a number of years (usually the requirement is to archive the equivalent of the
paper work order document). At the other extreme, some companies would like to be able to
completely reconstruct their entire network as it was at any point in the past. This is another
problem that is largely independent of the core "work order problem", and for space reasons
we will not discuss it further here.
Conclusions
While most vendors have now moved beyond check-out to provide some basic version
management, there are some significant differences between the implementations in the
marketplace. In evaluating implementations, it is especially important to look at existing
operational systems, in particular examining performance, scalability and reliability. Also
consider functionality differences, such as whether version management of the data model is
supported, and how sophisticated the conflict resolution is.
This paper has also explained how there are significant additional requirements for a design
application in addition to basic version management. The ability to do a sideways merge
operation is a very important aspect of providing a comprehensive solution. Other areas to
evaluate in a design application include support for jobs built on jobs; partial
completion/posting; mobile design capabilities; and archiving capability.
References
- Newell, R.G., and Easterfield, M.E., 1990: Version Management - the problem of the long
transaction. Proceedings of the Mapping Awareness conference.
- Newell, R.G., and Batty, P.M., 1994, GIS databases are different: Proceedings of AM/FM
Conference XVII, Denver, pp. 279-288. (Smallworld technical paper 19).
- Oracle Technical Network, Workspace Management information:
http://otn.oracle.com/products/workspace_mgr/content.html
