Search code examples
gitgithubbitbucketfilemakeramazon-elastic-beanstalk

FileMaker Pro version control with Git in Beanstalk / Github / Bitbucket?


We currently use Subversion for version control of our FileMaker development, but we're starting to explore moving to Git instead. We've heard some rumors of people experiencing file corruption when using Git for FileMaker files, but I haven't been able to track down any real sources.

Is anyone using Git for version control of FileMaker Pro files? Other than needing to close the files completely before committing, have you had any issues?


Solution

  • I've used both Git and Subversion for version control with FileMaker files. Chris makes some good points about size restrictions, but there are ways of making the best when using git.

    Version control file corruption with FileMaker

    I suspect that the file corruption that the rumors come from are not coming from git usage specifically, but from how the user is interacting with the files while using git.

    When you have a FileMaker file open, the FileMaker client is interacting directly with the binary file itself. Data and structure are being read and written to while the file is active, so if you try to commit the file during that process you're going to risk corruption. This risk is the same for both Git and Subversion.

    Whenever you're working with FileMaker files and version control, you need to make sure you close the file out before you commit. You don't necessarily need to close FileMaker itself out, but the file needs to be closed.

    Also, make sure the file is truly closed. You could think the file is closed and have a hidden or offscreen window open. Go to the Window menu and make sure all of the windows are closed before committing.

    File Size

    You can definitely use git for FileMaker files, but you are going to run into those size restrictions if you're pushing to a public remote hosting provider. That said, if you have your own local git server then maybe size isn't an issue.

    The best bet when dealing with size in the repository is to commit clones to your repository. If you're working from a FileMaker Server you can use backup schedules with cloning enabled to spit them out easily. This also get's around the open file issue because you would be committing a cloned backup, not the active file.

    It can be a pain because now all of your data is out of the file and FileMaker doesn't have a good built in automation for bringing data back in, but you can build a transporter file that runs imports from your populated files (outside of version control) into your clones (in version control). We do that for almost every project in my company.

    When it comes down to it, the important thing to keep track of in your version control is the structure and not the data itself. Storing clones should cut down on the file size enough to make either version control system viable.