Version control: is Git any useful for solutions built on FileMaker?

I am trying to research a methodology that our team could implement in order to do some form of Version control and facilitating regular updating or deployment instead of our current Hot Fixing approach.

The last convo on Community about Git dates 8 years back. Has anything changed over time? Has anyone found or streamlined a method to this development challenge in FileMaker? How does your team manages versions? What tools do you use? What are the limits?
Thanks a lot for your inputs!

The basics haven't changed.

Versioning tools are amazing.
Versioning is based on uncompiled source code, that is, text files.
You can include binary files in your source code, typically assets such as images, icons, etc.
You don't get the benefits of versioning on the binary files.
FileMaker databases are a binary file format.

You can do versioning with the XML output via DDR or Save as XML. You can also do it with the HTML output from DDR.


What is the use/benefit of versioning the DDR? (its long to extract a DDR). At what frequency of development would you do this?

Do this at whatever frequency you want to set for your work. Whatever increments make sense.

At the outset before you begin you create a DDR. That is your base document. Generate a got repo from this.

Whenever you make a backup of the work. You generate a DDR from the backup. Now over write the report with the new. Commit the changes in your gut repo with some notes, such as the path to the backup.

The repo commits form a history of your work. If you need to go back to a backup you refer to the commit history to get the location of the backup to select.

Short answer: no, unfortunately not. There is zero integration of the FileMaker IDE with Git.

Long answer:

  1. some 3rd party software tries to work around this limitation, i.e.
  2. XML exports of FileMaker files can be stored in Git and compared, changes highlighted

The 3rd party software path risks to break at any change or bug introduced in FM's XML export routine or undocumented change in the XML format itself.

The XML exports stored in Git are ok for storage and checking of changes. As mentioned above, the FM IDE has no Git integration at all. This means that branching, push and pull is not part of the FM dev's workflow like it is possible in Xcode or Visual Studio - and current standard for sw development.

Claris has the opportunity to add full Git support to the IDE in 'Claris Pro' which seems to be developed from scratch. I haven't heard though that this is part of the roadmap.

If one would have a 'GIT' or SCCS as we called it earlier, one had to move a FM file back and forth to GIT. We got files that are quite big...

No for FileMaker as a complete system, (maybe) Yes for some components like custom functions, etc. (but no restriction.. an other developer can still alter a CF in a FM file)

Even DDR's can become big files

1 Like

I second Markus. XML file handling can become unwieldy. I recently received a > 50 MB xml file for processing (no FM DDR). Even BBEdit struggled with it.
The XML produced by FM is not the source file. Source file is the FM file itself. XML exports managed in Git do not fulfil the strict criteria of 'source control'.
FileMaker files are structural monoliths. Using separate files for UI, business logic and data doesn't change anything to that.
This is something that could be improved in 'Claris Pro' as well.

Anyone using git for FMP databases, that is, the .fmp12 database is only using it as a form of storage illuminated by commit notes.

The power of git is to store the deltas. These are text representations of the difference between the previous file and the new one. It becomes an efficient storage mechanism that, with some clever programming, is able to roll back/forward/merge different text files.

XML and HTML output from FMP are text. So they are suitable for “diff-ing”. And so they are good for git.

If you want an XML aware diff tool, I suggest xmldiff, which is on git, the author is Remi Peyronnet. There is a gui for winOS and Debian. The command line tool can be installed on macOS using homebrew.

The out put of xmldiff is valid xml, so it can be parsed with XSL, or any xml aware language you prefer.

  • edits to make corrections and add links
1 Like

I noticed at AutoEnter 2022. It's in beta but I am going to keep an eye on it.


Oh my! This looks promising.

Can someone point me to the official documentation of the xml format produced by the DDR export?

now that is a nice one :rofl:

@steve_ssh kindly provided a link:

1 Like

interesting, I never saw something like that, only reengeneered stuff, would be nice to get an XSLT for this

For most of the objects the xsl is simple. Tables, field, scripts, value lists, custom functions, etc, are nested lists. They are easy to parse. The xsl is not complex.

Layouts are messy. Even a simple layout has dozens of objects, with grouping and nesting it gets complicated. I haven’t found a really satisfying solution for this. At present I create a list of the different types of objects as a menu, then display the objects as a list.