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!