Our team is starting to standardize some version control of our methods, which involves pressing “Save As” and renaming our .med files. However, we noticed when we do this, submethod calls do not update to the current version; they instead reference submethods from previous versions. Is there a fix for this without manually updating each individual submethod call? When we “Save As,” is there a setting we can change so that this occurs automatically? Should we be rethinking how we are implementing version control? Please advise.
If you have been using Git for Hamilton binaries, I am sure we would all love to hear more about it! I know it has been discussed before on this forum, but still I think lots of people would benefit from those who use it discussing their successful Git implementations with Hamilton VENUS methods.
If you double click on submethod call in your Main, the submethod reference name will update. Then you could save the .med again and the names save as updated. I know its not the best solution but it is what I do when this tickles the OCD portion of my brain.
I’m not sure why there is apprehension around git with Hamilton method (.med) and sub method libraries (.smt). I am NOT a git superuser by any means. I do not apply clever git-hooks or any other git actions that I do not know about. I simply create a repo for each .med and .smt that I create then keep them isolated so I don’t have to mess with git sub-modules. That allows me to easily track and revert changes as necessary.
Two key pieces of advice I can share is to: 1. always ensure is that the file itself is saved and CLOSED before you commit changes; and 2. you can never fix a merge conflict. Only keep incoming or the other option (this should not be an deal breaker because you cannot do a similar merge conflict fix type action in Hamilton method editor). I have been burned in these two areas before so we created rules around them when working on files (Basically abort all attempts of a merge, save your method as a new file, then merge in Hamilton software if you really need to). And even then merge issues barely ever happen. If they do, git revert to fix the corrupt method from the merge and continue with your life.
I would recommend to try it for yourself to see if it works. Keep your commit messages detailed as you would for “SaveAs” methods so you know exactly what you are looking at.
If you want to get really fancy you could create a git-hook to use the Hamilton bin convertor to convert all methods to ascii text. But I feel that would enable clever programmers to attempt to consolidate merge conflicts, which is something that will NEVER work.
Now as far as branching goes we will NEVER deviate from the master branch. Instead, once a new feature is implemented and tested as working we will create a release branch that we can easily update to via a checkout. Simple!
After playing around with git and hamilton for some weeks I’ve reached the same conclusions.
We work with gmp and tracking of the changes in the .hsl file and the libraries actually provide some value on top of version control.
Does people just normally initialize the repo in the base Hamilton folder? I have exported my method and then imported it in a custom directory so everything is together and used that as a repo. I like the idea that each repo is a Hamilton method + all its dependencies as it is important for us to be able to implement a new method on a instrument without affecting already live methods. Isolating all the dependencies under each method helps with this, even though you end up with lots of duplicate dependencies.
The big thing that messes up using git pull to deploy the method on the production system is the liquid class database. I don’t see any good way to handle this with git unless you want a lot of identical system.
If anybody has public repo with their git Hamilton implementation I would be very interested in taking a look.
We make an installation to install the method file and all its dependencies on new computer, including venus software, method, library, labware and liquid class.
With Inno Setup, only a script is enough to generate the installation file. To import liquid class, you can use following command HxCoreLiquidEditor.exe -instrumentclass ML_STAR -import liquids.mdb
I use git quite extensively with my methods, basically because for our workflow it is required. Luckily there are people that develop that for us.
Use semantic versioning on our methods
Use correct commit messages
Automate the versioning for release branches
From git, we have a pipeline running that produces a file, this file will be generated after a push. So I just pull after a push and I get this file. Then read the file and I will have all SHA, file names and versions in a txt file. This I trace
We have a heavily git-backed workflow too. The problem with tracing out the file is how do you know whether the local repo, i.e. the files you are actually using, is clean or dirty? We have libraries that run git on the command line to get this information during run-time.
