Document Versioning

One of the single most useful things that I’ve learned since studying a Computer Science degree, is about versioning software. I’ve used a number of different flavours of versioning software and I am still amazed that this is not part of the general consciousness given its usefulness.

One of the first versioning software packages that I came across was MediaWiki – the software developed and used by Wikipedia. While not trivial to set up, and not particularly full-featured (my biggest gripes are no wysiwyg editing and no (native) approved version tagging), it certainly does allow for very powerful historical tracking and, with the help of some additional plugins, can be made to fulfil most requirements. One remaining problem is that there are no currently supported wysiwyg editors for the most recent release of the software.

I have used MediaWiki (successfully) for managing policy documentation within my work environment and have used that to also make those policies available to the general public. Editing can go on without worrying too much about the front-facing result since visitors are shown the last approved version and not the current draft version. Less successfully, I have attempted to use it as a network documentation system, but there are a few too many security issues for my liking.

To solve the security issue, I’ve moved a lot of the technical documentation regarding our school network setup to Google Drive, from our Google Apps for Education system where the Google Docs function does allow for revision tracking. There is not, as far as I can tell, a way to tag the approved version of a document while the most current one undergoes revision. Thus while this provides perfect editing capabilities for something like the school policy documents, it is not a great mechanism with which to publish them and so introduces an entire other step to publish approved versions of the document. Also, reverting changes to the draft can be difficult since there is no easy means to find which the last “official” revision was in a frequently changing document.

The sharing and security aspects of Google Drive allows for significantly tighter control of who can see what.

There are, of course, document management systems whose job it is to manage documents and their versions. Documents are checked in and out (which reduces collaborative editing) and other versions which facilitate this, such as Microsoft’s SharePoint, require a significant outlay of expertise and licenses to set up a system to get it to work. What these systems do allow, however, is a far more fine-grained and standards-compliant control over documents and their revision process, but in my experience, the process becomes too complicated to manage and requires an in-house document management department. Given that we can’t afford, nor require, a department to manage documents, this becomes a significant overhead in terms of cost and effort.

Finally, versioning software reaches an entirely new level in the form of code versioning software, such as Mercurial, Git or Subversion (the latter falling out of favour given its limitations in team deployments). Certainly, these packages can be used for versioning any type of document, but the amount of expertise that is needed to understand branches, tags and navigate the interface software (I prefer TortoiseHG – although I do use some automated batch commands for certain procedures – like getting a list of all the files that have changes since the last “release” version) puts this out of reach for a casual computer user. This is despite it being potentially the answer to any range of versioning requirements – including web publishing of official policy documents (that requires an “update to” the latest official release – and all documents that have been changed will reflect the updated version.

There are some that have suggested using the likes of Mercurial or Git as a more general versioning strategy and will run automated “commits” (version saving) in the background. These can also be “pushed” to online repositories and downloaded to other PCs if necessary. Each commit is typically very small given that it only saves the differences, and so downloading a day or even a week’s worth of file changes and versions does not take particularly long. Using this kind of setup, all the associated computers have a complete “time machine” of all the file changes that have been made. This obviously comes at a cost of disk space, but probably less than you think.

I strongly recommend that anyone who is involved in coding or managing documents of some form, investigate versioning software carefully. With the likes of Mercurial, Git and Subversion, be prepared to think and get your head around it.

It’s worth it when you do.

Spreadsheets and Google Drive – IRL

I had occasion to make use of Google Drive in a real way recently when I was asked to check a wedding budget. I had the Excel spreadsheet e-mailed to me, and attempted to open it in Google Drive. The iPad app has potential, but I think still currently falls short.

I should also disclaim, before I get too into this, that I’ve not used Numbers or any other purpose-built iPad-based spreadsheet. I’m sure that the experience would be quite a bit more streamlined. However, those then lose the ability to share and edit concurrently.

From the Mail app, I successfully loaded into the Google Drive app – and, it seems, it was immediately synchronised with my Google Drive devices. Although I could preview it in the GD app, there was no way that I could see to convert the Excel Spreadsheet to a Google Drive spreadsheet and hence no way to edit it.

Instead, I had to use the web interface set to “Desktop” mode, ignore all the warnings about the “browser that I’m using is not compatible”, and then open the spreadsheet for editing. At this point, I had a Google Spreadsheet Document that I could edit back in the Google Drive app – which seems a little-long winded, I thought.

Navigating around the app is a little different and took some getting used to. If the keyboard is visible, tapping on a cell puts you in “edit” mode. Excel-like shortcuts of tapping on another cell while mid-formula does not insert the cell address as I’d expect, but rather deselects the cell and selects the new one. Fair enough, but since this behaviour is exhibited by every (almost every?) other spreadsheet application, I had assumed it would work. Having said that, I’ve no idea whether this behaviour works on other iPad/touch-based spreadsheets.

The app could also do with a better forumla editor, and perhaps even a customised keyboard with useful things like “multiply” not being kept three keyboards deep. This just makes the app quite difficult to use for spreadsheet novices. It doesn’t seem too intuitive.

At any rate, the Google Drive app is becoming more and more useful with each revision. I look forward to seeing the improvements in the next release of the app.