# A Spatio-Temporal Building Exposure Database and Information Life-Cycle Management Solution
## 5 Distributed Version Control and Release  
The database model provides rich functionality to log database transactions, archive records, and query object histories in space and time. It provides a framework for information integration, management, and versioning in a non-distributed manner, as it only offers collaboration of multiple users around a single centralized database. In order to maintain its intrinsic benefits (e.g., quick and comprehensive queries across different states of the database and its records), while making it accessible and manageable in a distributed multi-user environment, the database model can be coupled with Git and GeoGig version control systems.  
The schema of a typical versioning workflow is provided as part of Figure 4. The principal workflows and commands are similar between Git and GeoGig. The content is stored in a repository, which has three areas: the working tree, the staging area, and the local repository.  
* The working tree is the area of the repository where the work is actually done on the data. Data in the working tree is not part of a defined version but instead can be edited and altered before turning it into a new version that will be safely stored.
* The staging area is an intermediate area where data is stored before moving it to the database.
* The local repository is where the history of the repository is stored, as well as all the versions that have been defined.
* The remote repository is a remote copy of a repository that allows for collaborative work between different people. In a collaborative environment, the remote repository holds the reference history. Users can clone it, work on the cloned repository locally, and push their changes back to the remote repository. The process of versioning geospatial data consists of the following steps:  
1. Importing data into the working tree so it can be managed by GeoGig (note that this step is additional with respect to a typical Git workflow).
2. Adding data from the working tree to the staging area.
3. Committing to the local repository.
4. Pushing local changes to the remote repository and/or fetching changes from the remote repository to the local repository in order to synchronize them. As new data are added to the repository database, new versions are created that define the history of the repository. While some versioning systems store the differences between consecutive versions, GeoGig stores the full set of objects that comprise each version. For instance, if the geometry of a feature has been modified, GeoGig will store the definition of that feature, which will be kept in the database along with the previous version of the same feature. For features not modified from one version to another, the corresponding objects are not stored again, and the new version points to the same previous object. So while each version is a new set of objects, the data for these objects are only stored once.  
Where the database archiving functionality is designed to ease storage and querying of object histories and to provide a framework for information integration and updating in a non-distributed manner, Git and GeoGig are designed to ease collaboration among people working on the same data. The repository can accept changes from different people working on the same data, and the changes done by different users can be shared. Instead of a single repository, there can be a number of connected remote repositories, each of them working independently but communicating and interacting when needed.