Version management for more structured data is hard. In a previous job we did extensive work on it in the GIS domain, and even having everything backed by a lon

Version management for more structured data is hard. In a previous job we did extensive work on it in the GIS domain, and even having everything backed by a long transaction version controlled data store, resolving conflicts was not always easy. We did a lot of work on ways to automatically resolve conflicts, and it was only worthwhile for large customers who could set up good rules for their workflows (e.g. if you moved a pole in as part of a resurveying workflow then that position should take preference even if other changes happened to the pole). We can handle this sort of thing in software because we can try compiling something, see it has errors, and fix the obvious syntax problems that have been introduced by a merge or rebase. We have tools that make it easy view and copy data from a previous version, and all of this makes things easier. For more structured data those low level conflicts need to be handled much better so that the user can concentrate on the higher level aspects. If they need to restore sub structures deleted in a merge then they need to be able to see those, so our version control starts to bleed right through the tool chain.