Users frequently want multi-versioned forms. This means that they not only want to keep prior versions of a form's instance data but they also want to:
- be able to view prior versions
- compare the current version with a prior version
- see who changed what fields on a form an when
- revert to a prior version
This problem frequently occurs in complex computer systems that have configuration files. Something stops working but people don't notice it till later. There is no information about what the prior versions of configuration file looked like so the entire systems must be restored from backups. Many of these problems could be avoided by automatically reverting to the prior version of a configuration file.
With the XForms standard we are given the <submission> element and a small list of HTTP operators (GET, PUT, POST) to use and an action that can be any URL. If we want to allow users to save form data to a version-control system or to see prior versions of a form we have to translate these operations into something that a web server will recognize as operations on a version-control database.
Subversion is an open-source version control system with a client/server architecture (as opposed to a file-based architecture typical of other version controls systems).
Unlike older file-based version control systems, Subversion uses a transaction server model similar those used for reliable banking transactions. This makes subversion very reliable and allows you to check-in (or commit) groups of files that should be checked in together. They will either all succeed or all fail but the version controls system is guaranteed to always be in a consistent state.
Subversion also conforms (where it can) to the WebDAV WebDAV stands for Web Distributed Authoring and Versioning specification. The standard web HTTP protocol supports just a few operations such as get, put and post. WebDAV extends these simple operations to include operations we might expect on a file system such as delete, move and copy. Since WebDAV is more about file operations and Subversion is more centered on transactions, sometimes there is not an exact fit between the two.
Subversion has two principal concepts:
- update - gets the latest version of your code from the server.
- commit - take all the files you have changed from your local file system and save the changes through a transaction on the server.
To allow forms data to save to subversion we need to make a submission element do a commit. This is not necessarily hard but we want to be clear how the systems are different.
Subversion is a version control database. At it's core, it does not include an independent access control system. Because it is usually installed as part of a web server it usually uses the access control system of the web server it runs on. Apache also supports the WebDAV HTTP extensions which allow complex operations beyond the basic HTTP get, put and post. One of the best ways to get your XForms to be persistent is to configure Apache to use WebDAV with
Autoversioning and ApacheEdit
To configure autoversioning with Apache2 server you must modify the configuration file. This file should be configured to support your XForms work.
WARNING!: Any time you allow public access to write to your server you are dealing with security issues. You should always consider ALL of the security implications before you make ANY changes to a web servers configuration file. Make sure that security professional in your organization review any systems that have public web access.
You will want to have an Apache configuration similar to the following somewhat half-XMLish format:
<Location /repos> DAV svn SVNPath /var/svnrepos SVNAutoversioning on <LimitExcept GET PUT POST PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> </Location>
Converting HTTP PUT into Subversion SubmitEdit
The last step is to convert HTTP PUT into a subversion COMMIT. This can be accomplished using a program such as Jetty.
(We will post a sample program soon).
ViewCV and ReSTEdit
You can also start to add tools to Apache and Subversion to get colorful output that shows the differences between prior files. One option is to add the ViewVC (View Version Control) system to your Apache server. ViewVC allows you to see version history can compare prior versions just by addeing parameters to the URL. This method of using the URL to pass parameters to a server program is frequently called a REST interface. Almost all REST interfaces are easy to interface with XForms <submission> since XForms can encode the submission instances directly onto the URL.
Subversion REST URL interfaceEdit
Subversion allows you to access a resource's version history by adding an additional path to the URL. See 
For example if your file name was
If you wanted to get version 47 of a file it might be:
The Subversion FAQ suggests you run the Wireshark packet sniffer and look at the data in the HTTP messages. You can also use the Charles Web debugging proxy which also has a nice FireFox plug-in. Just make sure you know how to disable the proxy by going to the Firefox Tools/Options/General/Connection Settings and click the Direction Connection to the Internet. If you do not your web browser will no longer function when Charles shuts down.