Version Management Revisited
Version Management Approaches
Deep Version Management
The most established way to implement version management, which has been available for
about ten years and is in production use at hundreds of sites, is termed deep version
management in this paper. This approach is described in detail by Newell and Batty (1994),
and this paper will just briefly summarize the approach and its characteristics.
Deep version management is implemented as part of the fundamental design of the database
management system: it cannot be added in later as an afterthought. Briefly, it works by
allowing B-trees, the low-level data structures that make up database tables, to share disk
blocks between versions. This means that there is no processing overhead at all associated
with versioning. When in a version, the database only sees data in that version and does not
require any additional processing to filter out other data. An important feature is that the
contents of a data disk block never change; whenever something changes, a copy of the disk
block is made and the changes are applied to that copy. This means that it is possible to
implement a client-oriented DBMS, in which most data is cached in memory on the client,
and the great majority of processing is done on the client rather than the server. This makes
the DBMS enormously more scalable than a traditional server-oriented DBMS for certain
types of queries, most notably indexed queries where the same data is typically retrieved
multiple times, which is the case for GIS display operations. This idea can be extended to a
“persistent cache”, which is in essence a demand-driven distributed database, which works
very well for applications where geographic subsets of the database are generally accessed in
regional offices, as is typically the case with many spatial applications. It is the author’s
experience that a client-oriented DBMS requires one to two orders of magnitude less
processing on the server than a traditional server-oriented DBMS, which leads to significant
scalability and cost advantages. There are sites with thousands of concurrent update users
working against a single database using deep version management. Another feature of this
approach is that it is possible to version manage the data model in addition to the data, which
is very useful for development and testing purposes.
Shallow Version Management
Recent implementations of version management have all used what is termed shallow version
management in this paper. In this approach, versioning is not an intrinsic part of the DBMS
design. Instead it is done by storing records belonging to all versions in the same relational
table, together with additional key information relating to the version(s) that a given record
applies to. Queries perform additional processing to determine which records apply to the
current version. To make this transparent to the application, queries are usually done against
table views, rather than physical tables. The attraction of this approach is that it can be done
on top of a mainstream DBMS (using the DBMS in a conventional way – it is also possible
to implement deep version management on top of a mainstream DBMS, but only by using the
DBMS as a rather unintelligent storage mechanism for blocks of binary data, and having a
whole additional query engine on the front end). The main drawback is that it requires
significantly more server processing than the deep version management approach. The other
potential drawback is the relative immaturity of most of these implementations, which is
discussed in the next section.
Considerations in evaluating version management systems
This section briefly outlines some considerations in evaluating version management systems.
The key recommendation can be summarized in two words: check references. It is relatively
easy to produce a demo showing basic version management functionality. It is much harder
to produce a system that provides good performance and scalability. In addition, it is difficult
to produce a system that is robust enough for production use in a utility. In particular, there
are some complex issues relating to system administration, such as garbage collection or
database compression. Some people apparently do not realize that data that is stored in
versions other than top is essential data that needs to be maintained at all times. It is
unacceptable for any database operation to require that all versions be removed or posted to
the top level. A typical medium to large utility needs thousands of alternatives to be managed
at any given point in time, all of which contain essential data. Another operation that must
be supported on versioned data is changing the data model, which obviously needs to be done
on all production systems from time to time. The ability to version manage the data model
makes this operation much easier.
In summary, when evaluating a version management system, look for several reference sites
with a similar number of users and database size to your own system. At each site, look at
the performance, and what sort of server is necessary to achieve this. And check on any
operational issues; in particular, find out whether versions have ever had to be removed for
administrative reasons.
Additional Requirements For Design Applications
As mentioned earlier, while version management is a key piece of functionality in
implementing a good design application, it does not solve all the issues that need to be
addressed. This section looks at a number of additional requirements and discusses potential
solutions in each area.
First a quick note on terminology: this paper uses the terms “design”, “work order” and “job”
fairly interchangeably, and loosely, to refer to a group of proposed changes that is intended to
be carried out by a worker in the field. Different organizations may use these terms in more
specific ways, and may have hierarchical relationships; for example, a work order may
consist of multiple work requests, each of which can have one or more designs. Handling
these relationships is straightforward and will not be discussed here – apart from phased
completion, which is not simple and will be discussed below.
Views of the data - requirements
An important generic concept is that multiple views of data are required. A single
application will usually need most or all of these. Basic views required include:
The "as-built" view
In this view, the user only sees the state of the network that is currently built, with no
interference from designs that have not yet been built. A simple example is shown here:
Figure 1: Simple example of an as-built view
The "individual work order" view
In this view, there is a clear graphical indication of the changes that are being made as a part
of a work order. This view is used to create the work order document, which a crew will use
to carry out work in the field. Objects to be added, replaced and removed will all need to be
marked with distinctive styles. For example, cross-hatching is often used to indicate objects
to be removed.
Figure 2: Individual work order view for a simple network extension
An issue that is somewhat independent of the main one being discussed is that the work order
view may need to contain temporary graphical changes to make it easier for the crew to
interpret the printed work order. One common requirement is to make selected existing
objects invisible (if they are not relevant to the current work order). Another is to
temporarily offset objects or to add temporary notes, to make it easier for the crew to
interpret the work order document. These temporary changes are likely to be specific to the
individual work order view and not applicable to a multiple work order view.
The "future as-built" view
In this view, a selected set of pending designs is added onto the current as-built view to
create a new view that represents the anticipated state of the network in the future after these
changes have been made. No distinction is apparent between objects which currently exist in
the field and those which are part of the selected pending designs. This allows analysis
routines (for example, load flow analysis) to look at the impact of these future changes
without needing any special logic. Multiple future as-built views can be created, with
different sets of designs incorporated into each one. They can either be created on demand,
or can be maintained permanently – for example, some organizations permanently maintain a
view that includes all approved jobs.
Figure 3: Future as-built view, showing the completed design
The "multiple work order" view
Another common requirement is the ability to get a graphical indication of all the proposed
work in an area (which may consist of data in many work orders). Temporary graphical
changes, which have been made in an individual work order view, may not be applicable in a
multiple work order view (particularly if specific objects were made invisible in an
individual work order). The multiple work order view is often used when a user is working
on a new job, to display other pending jobs that may overlap or impact the current job.
Views of the data – solutions
This section discusses various areas that need to be considered in addressing the problem of
providing the various views described in the previous section. There is a graphical aspect of
this, which relates to providing alternative graphical representations for work order and as-built
views. There are many variations in the details of how this can be implemented which
will not be discussed in detail here. However, in general, most of these solutions rely on
storing a status field on each object (containing a value such as Proposed, Existing, or To be
Removed), and having the ability to define the style (symbology) of that object depending on
the value in that status field and the type of view that is currently being displayed (work
order versus as-built).
A more interesting question is how to handle trade-offs between isolating the as-built data
from work that is in progress, and the requirement to view data from multiple work orders at
the same time, which is required for both the future as-built view and the multiple work order
view.
