GH file revisions property

Hi everyone,

In you experience, what is the best way of keeping track of major changes of a gh definition? Instead of saving several files v1,2,3… is there a way to actually embed this info within the document (maybe relating that to an excel spreadsheet to share with your team, add descriptions to each revision, issue notes etc).

I try to take a look at the GrasshopperDocument.Properties.Revisions, but, for my knowledge, no documentation is provided , nor examples to follow.

Thank you,

1 Like

Its a actually a good question and I for myself haven’t found a good solution either.
In my opinion it highly depends on the problem you are solving. Is it complex, does it depend on Rhino objects, does it involve manual tweaking etc…
I also distinguish between a “creational” and a “defensive” mindset. On “creational mode” I play with a lot of approaches to find out which approach solves it best. In there I won’t care much about structure and documentation, since this would disturb the creational phase. In “defensive mode” I do everything to make a script error proven, clearly structured and modular.

However I for myself prefer versioning by coping different versions/approaches into one single file.

That indeed doesn’t work with all, and usually I end up mixing it up, having multiple files with several versions inside. Not a perfect solution as well…

That is why I prefer code over graphical components. Direct coding is more difficult and slower, but it pays of in the end, especially regarding structuring,documentation and versioning. In the end its a mix of both worlds which suits best. At least in my opinion.

If you don’t know what this property does, you can always use ilspy.
Although this is semi-legal process, I believe its okay, if it servers a good purpose and does not include pure copy and pasting of intellectual property.

I have earlier tried to convince the developers of GH to make a special ghx file format (.ghxvc) with all the logically irrelevant info stripped out (like layout positions, date/time and thumbnails etc) and all remaining info, strictly sorted so as to be suitable for version control. (the vc part of the .ghxvc file extension)

One of these days someone is going to make a script that strips out the messy info that makes version control meaningless (yeah, this was meant as a threat :slight_smile: )

Layout-info etc should be kept separately, either in a separate file (hm…) or padded on to an end section in the .ghxvc file so it would be easy to strip out, and to merge again on file open, without messing the whole thing up.

NIHS (Not Invented Here Syndrome) seems to be an obstacle though. :wink:

// Rolf


More than anything else, what I miss most about conventional coding vs. Grasshopper is the ability to easily search and compare source files. The ability to “diff” one version with another and quickly see only the changes is very highly developed for source code files and entirely missing from GH.


Totally agree,

If its just about looking out for a change of script, I believe this would be quite easy to achieve. You can receive components and its position in the script with ease. Storing this information in a file and comparing it would be quite easy. This would even work by looking into the file directly outside of Grasshopper. At least in theory…

Replying to myself here, but one solution which I suggested once was to at least add hooks for pre- and post processing when saving ghx-files. See attached:

// Rolf


Wow, it does look a hot topic.

This would be quite helpful. So you’d suggest to create a component - say a C# one - to retrieve those info (something like Metahopper does already). So, let me see if I understand here… you would use this component to compare two different grasshopper files saved at two time frames (t1 < t2).

The information saved externally is the list of the components instances’ GUIDs (I am not sure that the location is a trouble-proof idea, as you might move some components without making any changes). Now, would you compare by reading such external file in, say definition @t2 and highlight those components which doesn’t result in the precedent? (maybe by adding them to a huge group through Metahopper)

I’d assume that there’s a way to avoid external saving. Like importing a reference of a GH def inside the current definition maybe?

here an example of how I compare a recent change (a DIFF) I made to a script component in GH definition, saved as .ghx

The only only (but bog) problem is that this DIFF also contains all the xml-differencies caused by zoom factor and layout on the GH canvas, which is irrelevant to the logic of the GH definition)

Fig. Compare using Araxis Merge :

// Rolf

My old (very, very old!) standby is ExamDiff: ExamDiff - The freeware visual file compare tool (free version)

Even better, of course, are version control systems like Subversion that archive all past versions of a file and allow easy comparison between them, with merging and conflict resolution to handle changes by different team members.

My Araxis is old as well (2012), but notice the char by char diff in Araxis… :wink:


Added as a plugin to Git or Mercurial (say, at BitBucket), diffs can be performed against all of history.

// Rolf

Showing “differences down to the level of words or characters” is an ExamDiff Pro feature, which I owned at one time. ($35 U.S.)

2012 isn’t old! ExamDiff Version 1.0 was October 15, 1997.

@nathanletwory is a strong proponent of SVN: