One of the key enabling technologies introduced in the early days of AM/FM/GIS systems was long transactions, also known as data versioning.  Long transactions make it possible to store spatial design data in the same database as as-built data, enabling design engineers to work on new designs at the same time as operations staff are relying on as-built information to operate and maintain active utility networks. 

The first commercial systems implementing this technology in the early 1990’s were IBM’s GFIS which ran on DB2, Intergraph FRAMME, and VISION* which managed versioned spatial data in an Oracle RDBMS (this was long before Oracle Spatial and Workspace Manager).  As I remember, San Diego Gas & Electric and BC Hydro were GFIS sites.  The largest FRAMME site was Ameritech, now part of AT&T.  The largest VISION^ sites, which are still running and supporting about a thousand concurrent designers,  are US West, now CenturyLink, and Telesp, now Telefonica Sao Paulo.

Smallworld implemented long transactions in 1996.  Since then both Oracle (Workspace Manager) and ArcSDE (now ArcGIS) have implemented support for long transactions. 

Each of these early implementations implemented long transactions in a quite different way.  For example, in some the number of versions at any given time is assumed to be small, but the number of objects in each version is large.  In others the number of versions can be large, and the the number of objects per version is small.

Recently there has been a renewed interest in spatial long transactions with a focus on managing them in a distributed data environment.  It is being proposed that the underlying version management platform be based on the same principles as Git which has become the de facto standard in the open source community.  Git was originally developed by Linus Torvalds for source code management for Linux.  Google, Facebook, Microsoft, twitter, Linked In, Qt, Gnome, and Android are some of the folks using Git. Millions of open source projects are hosted on GitHub.  The GeoGit project is an attempt to apply a Git inspired version management system to spatial data in a distributed environment. Currently, users can import raw geospatial data as Shapefiles, PostGIS or SpatiaLite into a repository where any changes to the data are tracked. These changes can be viewed in a history, reverted to older versions, branched in to sand boxed areas, merged back in, and pushed to remote repositories. GeoGit, still in early development or alpha mode, is written in Java, and is available under the BSD License.

One of the use cases GeoGit is intended to support is a hybrid data management process involving an authoritative database that can be updated by crowdsourced data.  It is being proposed that with distributed versioning, it is possible to have the  best of the crowdsourced (e,g,, OpenStreetMap) and authoritative (e,g,, TIGER) worlds.  “Data stewards could maintain their own data repositories for their particular areas of interest. They could also apply the same quality assurance checks as the central authority, which would enable their data to be easily pulled in to the central database. However, the central authority need not be involved in order for partnering stewards to exchange updates with one another. These inter-steward exchanges would also facilitate quicker updating to the central authority, because there would be fewer conflicts during the merging of the updates the various stewards submit.“