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!
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.
Short answer: no, unfortunately not. There is zero integration of the FileMaker IDE with Git.
some 3rd party software tries to work around this limitation, i.e. www.fmversion.com.
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.
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.
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.