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

  • 4
    Since they're empty, why not just save them all? Sep 2, 2011 at 17:28

3 Answers 3


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.


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.


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.

  • I've looked at the API, and there is some really good stuff in there. However, for this particular scenario I'm really interested in the files being under revision control. An alternative would be plain text script files that could be run much like .sql scripts in a standard RDBMS.
    – Keith G
    Sep 2, 2011 at 17:31
  • I have a variety of template fGBD that I have in TFS, these are tracked in Source Control; and it can tell when a file/series of files changes; even if its the date-time stamp.
    – D.E.Wright
    Sep 2, 2011 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.