Second, how are you meant to keep any sort of version control system with Script Editor? In my current work flow I would create a new version of the GH ‘source file’ everyday I work on it and rename with a YYMMDD_ prefix - with all previous versions being frozen in time if I need to refer back to them.
With the Script Editor, if I create a new copy of the source GH file, ALL the useful changes in the Editor, like component Sub-category and Icons are lost and the work needs to be done again.
Similar, when I compile the components the /build folder gets deleted and rebuilt - meaning any extra files like icons are deleted at the same time and you lose the history/previous versions.
Is there a best practice to have version control in the Script Editor or was it built with the idea of only moving forward/overwriting the past?
Additionally, how to see (after compilation) which of your daily .gh files are used in your rhp? They appear in the Script Editor tree, but if you give them a more concise name, there’s no way to know what .gh file is referenced.
@eirannejad would love to hear your input on this.
The script editor to compiled workflow is great, a real step up from the rhino script compiler CLI interface. Would be great to work out good source control workflow with it.
If you double click on the component name in the Script Editor tree the GH file will auto zoom into the matching script component on the canvas. Found this by accident and went “cool” - very handy as your source gets bigger.
What I do internally is that I use git as my source control and save my grasshopper definitions in .ghx file format so they are text-based and easily handled by git. Then all my script editor project file (*.rhproj), scripts, and grasshopper definitions can live in the same git repository.
I can add an option to “Replace” a definition in the script editor project with another definition, OR, you can also manually edit the .rhproj file (it is JSON) and change the Grasshopper definition path to the new one. In this case I would suggest duplicating the .rhproj file for each release.
The +0000 number after the version is the build number and is computed automatically based on current date time. For example if you build 25.5.19 multiple times during development to test, the build number differentiates each specific build.
