FileMaker Version Control Explained

One of the issues that always comes up, while developing FileMaker solutions, is the lack of Version control options. In this article, you’ll learn what is Version control and how you can use it with the FileMaker.

Understanding Version Control System

A Version Control System (VCS) is a method used to save a file’s versions for future reference. Many people already version control their files and data by renaming different versions of the same file in various ways like MorningMessage.js, MorningMessage_v2.js, MorningMessage_v3.js, MorningMessage_final.js, MorningMessage_definite_final.js, and so on. Also, tracking the changes is a tedious task with this traditional approach. During software development, Version control works by equating changes in files over time. It allows the user to implement a change or feature, and then review those changes to see what has changed. It also allows you to move back to the situation in the development cycle history.

How does the Version Control System work? 

Let’s say, you are writing a sentence, “Good Morning World!”. You will save it in a file that stores the content as text. You then commit that to a Version control system calling the commit something like “My First message”. Then you change the sentence to “Good Morning Beautiful world!”, save and obligate that to the Version control system and call it something like “I added the word beautiful”. The Version control system would now have a recorded history of the changes you made, and you would be able to see the changes that you made. In this instance, you added the word “beautiful” to the sentence. This works because the file is stored as text and any changes to the file can be equated and you can see differences between changes. It also makes keeping in references to those changes small because it only records the recent changes and doesn’t store the entire file over and over again with each change.

FileMaker Version Control

This doesn’t happen with a FileMaker file. While you can save the changes that you make to a FileMaker file, you won’t be able to recognize what those changes are. The reason behind this is the FileMaker file is a binary file and is not stored in a text format that can be easily compared. When changes are made, the entire binary file changes into a new file. This means you don’t have access to the change made, you can only see that the file has changed. It means that you are saving a complete copy of the file each time you commit it to your version control system.

How to Use Filemaker Version Control

Here’s how you can leverage Version control to see the development changes that you make to a FileMaker file. One option includes utilizing the Database Design Report (called DDR) for the file as you work on it. Although it adds a little bit of overhead, it provides you with detailed files about design changes that can be later compared. Once you have created a DDR for your FileMaker file, you can then use the Version control system on the DDR files. When you submit design changes to the FileMaker file and are ready to commit them to the Version control system, re-create the DDR. Using Version control on the DDR will give you access to those changes between commits of the DDR. Although the DDR is extremely difficult to navigate, it can still prove to be useful when tracking changes.

Finding and configuring Version control system can be a little intimidating. You can use tools like Github or GitLab to store the repositories and to compare differences and make your commits. Using these tools makes it easy for you to find and configure the system. Here’s how you can do that:

  1. Create a git account with a provider or host your own.
  2. Configure the tool to connect to that account.
  3. If you are using GitKracken, initialize a new repository to a folder on your machine. Then open the repo. This is where you will save the files you will be monitoring with Version control.
  4. Put the FileMaker files into the repository folder you created, and generate a DDR into that same folder. You may or may not choose to save the FileMaker file itself in the repository. For smaller FileMaker files, it’s recommended to store it in the repository. This will allow you to roll back to a design state while you are developing the solution. The only downside of this method is that the FileMaker file is stored in its entirety and the repo will rapidly increase in size depending on the size of the FileMaker file.
  5. Commit the changes that you have made to that repository, as this will push all the files in the repo folder to the git host.
  6. After making some changes in the FileMaker file, generate the DDR again, overwriting the existing DDR.
  7. Commit the changes that you have made to that repository.
  8. Repeat steps 6 and 7 as needed.

Another option to Finding and configuring Version control is to develop on a hosted FileMaker solution. Scheduling regular backups can help you recover the FileMaker file at different stages without increasing the repository. Then you can forgo adding the FileMaker file itself, and don’t forget to use the DDR. If you need to recover the file at a specific situation you would pull that copy from the server backup.

Reliable FileMaker Solutions

Invest in Reliable FileMaker Solutions

Neocode is a team of certified FileMaker professional consultants who are ready to help your company with a custom-made workflow system for all your business needs which will greatly help you organize your projects, people, and assets. Connect with us today.

Leave a Reply

Your email address will not be published. Required fields are marked *