If you have more than a moderate sized project or more than one of you working on the same project then this is worth a look. It allows anyone working on the project to access all previous versions of all files, highlight the differences and identify exactly who changed them and when - all in a reasonably straight forward way. Multiple versions of the dataset can be maintained in parallel and they can be merged at some future time if required.

A survey of the therion list subscribers a while back brought up;

• Subversion (SVN) http://subversion.apache.org/ (centralised only)
• Mercurial http://mercurial.selenic.com/ (centralised or distributed)
• Git http://git-scm.com/ (centralised or distributed) and
• bazaar http://bazaar.canonical.com/en/ (centralised or distributed)

If you think you might have to take your project to a 'desert cave island' or up a mountain away from internet access, and you want to use two or more laptops to double the drawing rate and act as mutual backups, then you need software that supports a distributed model.

A few years ago I self mis-taught myself on the ways of version control, and these are the misunderstandings I have come to so far.

Bazaar seemed like the most understandable at the time, and until May 2013 was all I had been game to try. I've dabbled just now with Mercurial, even getting it to work, and while the instructions are now better than Bazaars' I've decided, in my half informed way, the graphic user interface (GUI) for Mercurial exposes the uneducated user to way too much choice and provides too many options for getting into trouble.

2.5.1 as at June 2013 Like, I think, all of the applications listed above, bazaar can be used (starting from most geeky and progressing to novice friendly)

• in a dos like command line mode,
• sort of half-way between (tortoise bazaar) where it piggy backs on the file explorer/manager,
• or in a graphic user interface (GUI) mode.

I have experimented with all three and tend to use the later two most. Also common to most applications listed, (I think) the file manager icons can be overlaid with coloured ticks and crosses to indicate the state of each file in your repository. Exceptionally useful.

Also it was gratifying to find that with bazaar and mercurial installed on the same machine, they used the exact same icon overlays and played nicely in the sand pit together.

So, as above, the bazaar GUI presents a simplified step by step approach, and puts in front of the user the next most likely thing(s) they should do, based on the state of the repository data. Most of the complexity is hidden away, but readily available if you so much as look in the menu bar.

The bazaar GUI and tortoise mode was almost unusable for this novice user at first, and is still frustrating, because many of the default file paths proposed to the user by the software are just plain wrong, foiling any attempt to get a working repository. So long as you treat every path presented by the software with scepticism, you will be able to progress.

Once this novice got past this, the only criticism I would have is that bazaar does not automatically track file renames or moves. The user must remember they have done this, and manually run the cryptic 'mv' command. To make matters worse, if you rename a folder and rename or edit the files within that folder, bazaar cannot usually track the renames properly - you will need to manually type out each one, or carefully commit first the file renames and then commit the folder renames. If you get this wrong, bazaar tracks the changes as a 'file deleted, and file added' and so you lose the ability to trace the history of file edits preceding the date of the rename. In about 5 years i have not managed to lose or corrupt data in a bazaar repository. This shortcoming is perhaps the most likely cause of user induced corruption.

Ignore Files

Assuming you figure out how to use bazaar then one of the first things you'll need is a .ignore file to prevent insignificant files from being versioned. Here is my one tailored to my usage of therion bzrignoretherion.zip, annotated below as follows. I have not annotated the attached file, as any trailing or leading characters on lines will render the .ignore file ineffective. Also the attached file does not have as many entries as the annotation below.

.*.dat	#filters out all files that start with '.' and end with '.dat' at all directory
 levels.  This prevents the .xtherion.dat files that are created each runtime from being
 versioned.
*.esri  #these next several lines prevent common therion output files from being versioned.
*.db
*.html
*.k??	#filters out kml and kmz files etc
*.log
*.lox
*.pdf
*.sql
*.bbox
*.3d
/**/thTMPDIR/**/ #filters out all temporary directories sometimes created by Therion
 (in debug mode).
/**/Output*/**/	#filters out all files and directories below the 'Output' or 'Outputs'
 folder but not the Output directory itself.  ie The Output folder WILL be versioned,
 but not it's contents.  This ensures that Therion will run smoothly if an 'export' of
 the cave dataset is made.
/**/backup  #filters out backup folders sometimes automatically created by Pockettopo
~back*.top  #filters out Pockettopo backup files

2.6.2 as at June 2013 Like, I think, all of the applications listed above, mercurial can be used (starting from most geeky and progressing to novice friendly)

• in a dos like command line mode,
• sort of half-way between (tortoise mercurial) where it piggy backs on the file explorer/manager,
• or in a graphic user interface (GUI) mode.

Also common to most applications listed, (I think) the file manager icons can be overlaid with coloured ticks and crosses to indicate the state of each file in your repository. Exceptionally useful.

Also it was gratifying to find that with bazaar and mercurial installed on the same machine, they used the exact same icon overlays and played nicely in the sand pit together.

Mercurial managed to convert my bazaar repository and history flawlessly and very quickly, after several hours of false starts (need to complete a non-standard install to enable the convert feature, and then resolving misunderstandings over how to set parameters). So full marks Mercurial, limited pass Bruce. Here are some notes I made to myself to get it to work…<TO DO attach file>

To be honest I have not used Mercurial much, but I think I have played enough to be sure that I am not completely blinded by beginners bias. Mercurials GUI, and some of the Tortoise Mercurial dialogues, present a bewildering array of options to the novice user. Despite the very good instructions on the web page, I could not figure out which was the next most likely command I should use (I often leave my project for a week, and then come back to it, so I like my software to prompt me as to where I am at and what the next most logical thing I should do is). If I was proficient in the ways of version control I expect I would prefer (by a large margin) the Mercurial GUI over bazaar, as there is a rich array of information and many options are at your fingertips.

However I cannot imagine myself, or the average caver understanding it it or navigating their way through it mistake free unless some serious training was undertaken.

One aspect where Mercurials GUI and Tortoise dialog is far better than bazaar. Mercurial automatically detects and alerts the user of file renames and moves, and proactively suggests likely contenders for matched pairs, and a simple point and click management of these. This is almost enough to make me want to persist a little more with Mercurial.

One really good GUI for Mercurial is Easy Mercurial from http://easyhg.org It is far simpler than Tortoise Hg and was designed for beginners. It's interface was designed for non coders.

Ignore Files

Just for comparison, I tried to make a .hgignore file to perform the same role as the .bzrignore file above. Actually it is necessary to prevent bloating of the repository with all of the rather large binary type outputs.

A nice thing about mercurial is that it allows comments within the .hgignore file. A frustrating thing is that I could not get it to track folders but ignore their contents. I'm sure there is a way, and I am just foiled by my regit incompetence.

syntax: glob
.*.dat #filters out all files that start with '.' and end with '.dat' at all directory
 levels.  This prevents the .xtherion.dat files that are created each runtime from being
 versioned.
*.esri #these next several lines prevent common therion output files from being versioned.
*.db
*.html
*.k?? #filters out kml and kmz files etc
*.log
*.lox
*.pdf
*.sql
*.bbox
thTMPDIR  #All the following don't work in Hg. See the .bzrignore file above for intent.  Need to figure out a regit pattern
/**/Output*/**/
/**/backup
~back*.top

GUI

MacOSX

MacHg is a free open source OSX GUI for the distributed revision control system Mercurial.

GIT can be used for managing small to big cave projects.

A good german tutorial is: https://www.atlassian.com/de/git

A nice english tutorial can be found at https://git-scm.com/book/en (short at https://git-scm.com/docs/gittutorial)

Subversion is also good to manage a cave system. The drawback here is, that ineraction with the repository requires online access, so this restricts usage directly on site. Its features also only a centralized workflow model. Branching and merging is not so easy as with git. A advantage is its ease of use (compared to git the workflow is somewhat easier).

Today if i would start frehs, i probably would deploy git now.