Thank you for your question. Your idea of using version control/management for OpticStudio is one that’s gotten asked from time to time over the years, but it has not resulted yet in implementation. I cannot say when such an option will be included within the code or as a recommended external program. If you do decide to go on your own and have any experiences you would like to share with us and with the Zemax community, though, please don’t hesitate to share them here.

I started to use git to manage the different versions of the OpticStudio models.

Such a repository should be organized like this:

- check in the *.zmx files into the repository. The *.zmx files are saved as ASCI files and are suitable to document the changes like in programming languages. 

- do not check in the *.zda session files. This should be user depended temp files

- add Zemax Documents files to the repository which must be copied into the working documents files folder

- realease versions of OpticStudio models should be saved as a *.zar Archive file in some folder outside the repository 

Thank you for starting this discussion! Along the lines of keeping track of the changes during the design process, I'd just like to share the method used by one of my colleagues

Hi Berta, 

thanks for your answer. The major difference of his method ist. Wenn you use a log book 'TRIP2.txt' you may forget to write there your message. 

When using git you do not need to save several different file. You work on one file containing serveral revision each having a commit message. You can also compare the *.zmx ASCI--file and see line by line the difference of two files. 

@Photoniker ,

Thanks for this answer! Would love to try using Git for my Zemax projects. I was wondering if you’re still using it and how you’ve found it for more complicated files (eg non-sequential files with several sources, objects, etc.)?

Thank you!

Hi Amy, 

yes I’m still using Git for my Zemax project. Sources, objects, CAD-files are also copied into the repo. That is not a problem, because there are not changed by each commit in the repo. 

However, I have not idea how to handle the new *.zos format which is a binary format and cannot be managed by Git. 

I’d love to see the Zemax File Comparator tool as a standalone application, or maybe as a plugin of WinMerge (or similar software). With .zos format I guess any custom-developed comparator won’t work any more.
 

But before that, just sticking to the present File Comparator, I find it pretty dumb. It does not compare “lens-wise” but just “surface-wise”, so that, if you have an additional dummy surface somewhere, then everything looks different, when it’s actually not the case. 

I’d also really appreciate some sort of visual comparison between layouts, something much like what you get when overlapping multiple configurations.