Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
Since they're empty, why not just save them all? – Kirk Kuykendall Sep 2 '11 at 17:28
up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
Good suggestion. Just go to ArcCatalog, right-click on the gdb and choose "Export->XML Workspace Document". Unfortunately it is not yet available as a GP tool:… – RyanDalton Dec 1 '11 at 22:45
@RyanDalton, great suggestion! If I could script the export & import, that would work really well. Do you know of a way to do that? – Keith G Dec 2 '11 at 2:09
As noted in the link to the "ideas" page, there isn't a geoprocessing tool for that yet. However, a quick google search showed 2 plausible candidates:… OR… – RyanDalton Dec 2 '11 at 15:17

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.

share|improve this answer
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 '11 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 '11 at 17:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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