How to set up a Revision Control for ESRI File Geodatabase?

Question

I'm interested in doing revision control (Mercurial) on some file geodatabases. Does anyone have an idea of which files are important (need to be saved) and which can be ignored? Note that I'm not interested in ESRI database versioning. These are essentially empty (no data), and I want to make sure they are in sync with code changes.

For example, if I add a new feature to the database, I add some things in code that uses that feature. If I want to go back to an old revision of the code, I want the database that matches. I don't even need to be able to compare versions, just get back to a particular one if needed.

Some of the files include: gdb, timestamp, *.freelist, *.gdbindexes, *.gdbtable, *.gdbtablx, *.spx, *.atx

Answer 1

Since you don't want to compare them, I suggest putting the whole geodatabase into a ZIP file and then keeping the archived version under revision control.

This will also help avoid stray .lock files from ending up in your code base.

Answer 2

A geodatabase with no data contains no info worth saving except the SCHEMA.

I pretty sure I've seen free tools (from ESRI or ArcScripts, etc.) for exporting a geodatabase schema to XML and back. (In fact, I think the same tool could export & import both schema and data, if you have data.)

Finally, the XML is stored as PLAIN TEXT, so the revision control you trust for source code will be just as reliable for the XML. That would be a nice backuop in case the revision control fouls up some of the funky binary files in the zipped geodatabase.

Answer 3

I would really look at the fGDB api, versus relying on the OS-FileSystem level to try and version it. Since so many of the files appear to be benign; doesn't mean they are.

The API is open and public and may allow you to see more low level information in a more appropriate way.