How do you do the version control in FM?

Hi, there are many version control tools in other languages. I am curious how do you do version control in FM?

Welcome to any comments. Thank you.


Do you mean while developing a solution or building a version control tool with FM?

1 Like

Yes, Exactly.


Version control of the file you are developing


Building a version control tool with FileMaker?

1 Like

version control of the file I am developing.

The DDR and the XML copy both offer you the means to do this. Standard Diff tools don’t handle XML nicely so that’s a big drawback. I’m working on a tool that can produce sensible Diff form XML that would be suitable for locating unique differences in the XML output but its not ready for primetime.


we do the most with FMPerception (DDR analyzer) via DDR.

There is a tool available called FMDiff that compares 2 versions of a fm file and displays differences


Version control depends on how the development is carried out and by how many, or at least if by more than one person.

We always use the separation model, hence we have a UI file where the majority of development is carried out, we develop as a team and usually all development work is carried out files hosted on a development server.

Our requirement for versioning is not for the detail of the work, but to establish which is the live version, which is the development version along with a summary or what work has been carried out for each version. Other needs include whether a version has been uploaded to the development server for testing only, rather than development, or whether a development version has been removed from the server for offline work (say development during a journey on a laptop).

All scripts are fully commented and versioned from the date created and by who under a ‘changelog’ comments section located just after the script description comments, which are the first entries. After this, all changes are accompanied with descriptive comments, again dated and by who, along with a ‘changelog’ summary entry in descending date order so the last changes are displayed first.

We use a very simple solution. We use a versioning layout within the UI file. Layout text is used to add version numbers, date, person and a summary list describing what has been changed.

The version number is displayed on the home page of each solution and, displayed for full access only, large bright text such as ‘LIVE VERSION on xyz server’ or ‘DEVELOPMENT VERSION on zyx server’, etc.

This information is updated when a UI file is copied from a development server to a live server or visa versa.

We’ve tried more sophisticated solutions; one of our team wrote a complete record based system with automatic versioning, which was OK until we started using the FMDataMigration tool, which renders this useless (they are still getting stick from the rest of us, LOL) or to be more accurate it creates more work.

The above has stood us well for over 15-years. Our go to tool for any technical information is Perception.


I use a system very similar to Andy’s for years. This works quite well without generating extra work.


In a simple in-house repository you could store clones of the files (or even files with content) with version information. This can be created in FM, fully customised to your needs (single-file or multi-file solutions etc.)

1 Like

we got ‘release notes’ tables where we note every change, release numbers as well

Problem is the ‘principle of the biggest malevolence’ - the version-changes You are looking for, is exactly the only one forgotten to note (no matter if there are millions of records)…

1 Like

My technique was to save a copy of the dev file with the date of the day, work on the dev file locally while making some other requested changes on the live file, and then pull my hair out.
(That was tongue-in-cheek, in case some didn’t figure out. Even though I did do all the above, I am certainly not recommending it!)

1 Like

I do kind of similarly.
I have a Log-Book where I write protocol for all development. A simple text document.

v4.0.0 - [190922]

  • auto Validate:
    ßParse_Invcoice: #19 / #22 - Scriptparameter ßload_SchemaValid_Invoice

2 fields in the primary file:
Version = 395 => v3.9.5
built = 20191016 => released 16. Oct. 2019

For “about”, the user sees
MedicalBizz v3.9.5 [20191016]

1 Like

The developer of FMPerception ( Dave Ramsey ) is also working on a comparison tool to intelligently diff the XML 2.0. It will be provided as a free add-on to current FMPerception subscribers.

I've been listening to him talk about the project on the podcast him and Joe Simpson do together.


A simple text document.

How unprofessional! And you call yourself a database developer? :grinning: (Just kidding. I’m sure you get my sense of humour)

I use a FM database where I enter all Bugs and upcoming Features. It holds several fields like
Module (Invoices, Addresses, …), Task (or Feature), Description, Category (Feature, Bug, Note), Date, Program-Version, Priority and Done. And I also have a separate table for screenshots for each task.

Thus I can sort by different criteria depending from what I want to see. And of course I can find things easily.
In the description field I usually define the problem, the reason and how I solved the problem (sometimes step by step to redo it on my final solution, after I tested it in a copy).

In my scripts I have a comment for the date of the last change.

My Versioning of the file is being made by TimeMachine.

1 Like

For those who would like to use it, here’s the file.

Dev History.fmp12 (472 KB)


I take the blame as soon as Claris works the FDS-Forum Software with FileMaker Server technology :sweat_smile:

1 Like

Please check FM.RunDatabaseDesignReport and FM.RunSaveAsXML functions in MBS FileMaker Plugin, which allow you to write scripts to automatically do the DDR/XML and save them to a folder. Then you can post process them with script to split into separate files for each script and track changes there easily.


This is a really good post that tries to define ‘version control’.

It appears to be at least 2 things:

  • The difference between one file and another

  • Where does a file stand within the evolution of development

Going back to my Mac support days in publishing, the most common mistake was to have 2 (or more) versions of a QuarkXPress template being worked on by 2 designers at the same time. This always resulted in panic and a lot of work trying to create a third consolidated version.

This is similar to our particular needs, we need an overview of what is happening, but we absolutely need to know which is the latest version, sometimes it can be the one on site, that has had some small amendments since being upgraded, sometimes the one on the development server, or perhaps a local version.

For others it appears to be the specific changes within 2 files, perhaps these changes are going to be added to a live system having been added and tested to another version, or maybe versions.

The fmDataMigration tool perhaps also adds a new dimension to version control.

Interesting discussion and thanks to @samfmp for starting it.


Thank you all for the input on this topic. :wink:
I am just curious how do other developers do version control on their solution.:sweat_smile: