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:
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
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.
I noticed devin.fm at AutoEnter 2022. It's in beta but I am going to keep an eye on it. https://www.devin.fm
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 
@steve_ssh kindly provided a link:
https://help.claris.com/en/pro-db-design-report-xml-grammar/
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.
We launched Devin 1.0 last week and it's full of new features! (1.0.1 Release Notes)
Welcome to The Soup @davidwollesen!
I just looked at Devin 1.0. Too many missing pieces for me right now but road map looks promising. I am curious to know the target audience. I ask because I don't see a useful pricing tier for consultants supporting many customers and many projects.
Thank you @bdbd!
What specific pieces are you missing and what are you most excited about in the roadmap?
Devin is built to support all from solo consultants to large consultancy firms supporting many customers. Currently, our largest tier supports up to 20 customers/projects/servers. We will soon launch add-on packages for additional projects/servers. We're also offering custom deals with unlimited projects/servers.
But we're always looking for feedback, so I'm happy to hear your thoughts on a potentially missing tier 
Missing…
A complete branching feature that includes the ability to diff and merge.
Complete and robust documentation… as in one that doesn't say things like "Coming soon" or "As you become more familiar with this workflow".
What I like most in the roadmap…
Advanced version control (diffs and insights).
Thoughts on tiers
Let me be critical here. The pricing section on the Devin website assumes the reader understands the lingo being used to describe the features. I don't understand it all. I tried looking up this lingo in the documentation… and didn't find all of it so still don't understand it all.
As best I can figure this out, I need / want a tier for an unknown number of users (I am a one-man shop that collaborates with other devs from time to time), a large amount of projects (I service many customers) and many servers (these customers do not share servers). I would only be able to serve a portion of my customers with the limitations presented.
Would my needs require me to obtain an enterprise tier? The Team Plus tier already costs US$6000 per year, a cost I would need to pass on to my customers. I would need to charge one of my customers alone half that cost to cover his needs. I can tell you I would get a flat "No" from this one for we already automate much of what Devin seeks to automate.
Hope this helps!
Thank you very much for the feedback. Your points are duly noted.
As for the roadmap, we’re looking forward to deliver more advanced version control features such as merging capabilities. We are however currently limited by some of Claris’ underlying technologies for this to be developed.
I acknowledge that docs have been limited in our first week after release. There’s now no more “coming soon” sections, and you will see more elaborate updates with video tutorials coming in the near future.
We also acknowledge that the pricing tiers does not properly reflect the needs of all customers. We are learning from feedback like this, so thank you