Home → Extension Development →

Checking Moneydance in to Version Control

• Edit

Max Pixel

11 Jun, 2020 06:07 AM

I just wanted to share that I've been checking in snapshots of my Moneydance data folder to version control software. Moneydance does have its automatic backup feature, but a real version control system offers very nice benefits.

Primarily, I am able to attach messages to each commit (instead of just a timestamp), and it's much less effort to undo changes and roll back to a previous snapshot. It's easy to imagine how indispensible this is while developing an extension that modifies (and occasional mutilates) my precious books. It also provides a means of synchronization between my computers that I trust a bit better than Dropbox.

Moneydance's data format is interesting. It appears to save a new file for every action taken, and then compact those dozens or hundreds of small files into a bigger one on a monthly basis. This behavior, in addition to the fact that these files utilize binary serialization instead of text serialization, means that Moneydance data really isn't conducive to version control. Reverting anything other than the most recent change, or merging parallel branches of work probably aren't possible in the current data format. That said, I've still found it to be worthwhile, both for the sake of rolling back, and to keep a good dated record of the changes that I've made.

Specifically, I'm using Plastic SCM, which, among the various version control software available, has the absolute fastest operation and best handling of binary files.

1. Max Pixel closed this discussion on 11 Jun, 2020 06:10 AM.

2. Sean Reilly re-opened this discussion on 11 Jun, 2020 10:23 AM

3. Support Staff 1 Posted by Sean Reilly on 11 Jun, 2020 10:23 AM

   

   It's great to hear your positive experience with using version control with the moneydance file. I'd note that the files are only binary because they are encrypted and that behind the encryption they are line-based text files. As you noted, a new file is created for each change (or set of changes if they are grouped). The tiksync/safe/trunk file represents the current state of the data on the current computer. That current state is composed from the combination of all of the incremental change files, and the processed.dct file contains a record of which incremental txn files have been incorporated into the trunk.

   So in theory if you did have a conflict between changes on two computers you could revert the trunk and processed.dct files which would cause both clients to re-apply the incremental changes from the individual txn files.

   Of course I always need to add the disclaimer that having syncing enabled would roll back any of these manual changes :)

   Thanks,
   Sean

   --
   Sean Reilly
   Developer, The Infinite Kind
   https://infinitekind.com

   • Edit

4. Sean Reilly closed this discussion on 11 Jun, 2020 10:23 AM.