Mac users know that when they save their file often, there comes a little pop-up window warning them to not do that because it can pile up versions that macOS makes on a system level. The window comes with this link to an explanation: Link
The macOS file versioning is not transparent - no developer or user of its system knows how it saves the incremental changes. Nevertheless - i can imagine about 100 ways how to my 1 gigabyte file becomes not suitable for an incremental change: E.g. even a simple command like move internally does probably enough to make it unsuitable already - but the point is - we donāt know, and McNeel also does not know.
I just wonder if this was a bad idea to begin with, and the versioning system is just not the right tool for a software that creates easily 1+ gb files - so here a little poll:
Are you using Rhino File Versions in macOS?
Yes
No
0voters
Versioning itself is a good thing, but as you can see from the McNeel document:
..it might be time to ditch it, if it is something we canāt turn off anymore..
Because - even āView > Refresh Shadeā probably makes 80% of a file (the viewport meshes) already unique - imagine running that a few times on a 1 gig file..
PS: I donāt know of any other macOS software that such dynamic data as rhino (rotate the whole scene by 90. deg in one command and invalidate potentially everything) and uses versioning.. It is a good thing for slides, maybe excel or word, where data is persistent, but here in CAD it seems like the wrong place..
Iāve never had a single problem with Versions in Rhino. Iāve used it, not extensively, to recover files when I do something stupid. Just a data point, for what itās worth.
What we know is that the versioning does diffs in some way and that they are incremental. I can just guess from an information theory standpoint.
Rhino does not have a transformation matrix / object data separation in the classic sense (like blender, maya etc.)
That means - a transform operation, even if keeping the guids and references all alive, basically creates a whole new object so to speakā¦ So the whole data changed - it might only be shifted a bit, but i donāt see how macOS can do a diff from that without a lot of computation.
In the case of e.g. blender - any transform operation leaves the datablock alone and in the same place in memory.
I remember from when i wrote a collaborative modelling plugin a few years back (was internal only) that any command actually destroyed and recreated an object that the command ran onā¦
From what i understand of the underlying data-structures and processes in Rhino, it just seems very likely that small changes can create very different looking data
Unsuitable means that every version with sufficient small changes has the potential to render the incremental nature of versioning useless and saves a big portion of the file in every new versionā¦ - but i am just guessing
I wouldnāt necessarily call that unsuitable. In the case that you describe, each version will be a big file, yes, but macOS maintains the versions and deletes them as they get older. If you are working with huge (and I still consider a 1 GB file huge) files, I suppose you should make sure that you have a machine that can deal with your work, i.e. have plenty of disk space.
At any rate, thereās a test command that you could try - TestToggleMacAutosaveVersions - to turn off macOS versioning. Note that this is a TEST command and that you should save often and have good backup routines for files that you care about! You can read about known issues with this command here: RH-71881 Autosave: Setting to toggle macOS Autosave/Versions
Apart from those known issues, there might be unknown issues as well. I have been running Rhino with versioning turned off since March this year and havenāt encountered any issues but I only use the Mac for some simple testing.
-wim
thanks for that hidden command! I know 1 gb is not a good production file - as there are many ways to link thingsā¦ but its more about simulation stuff that gets baked from GH, Pointcloud managment - there can be big files etcā¦
Its just that often i work on the edge of what the machine can do, and then having something like that versioning in the background is not really comforting
If/when you disable Autosave and Versions with TestToggleMacAutosaveVersions, it would be extremely helpful to hear how things work (or donāt work). Often, when things do work we donāt hear back from people, which is understandable. In this case, it would be good to know if you think this solves your problem (which, I admit, I donāt fully understand).
Anyway, looking forward to hearing about your experience with it disabled. Please be cautious, as Wim already said
it is more of a concern than a real problem at this pointā¦ But i am still not using V8 in any production scenario - once i do and encounter problems i will get back to you!
Hi Dan, @wim,
today I got a call from a colleague with similar problems / concerns - and I thought it is a good time to get back to you - I was using Rhino8 on mac with autosave disabled since this thread was started, and had no problems till now..
So it would be nice if TestToggleMacAutosaveVersions can be considered to become official in V9.
I do think disabling it proves little, though it is very helpful to know they have it disabled and havenāt seen a problem since. I suppose āthe absence of evidence is not the evidence of absenceā here (with regard to implicating Autosave and Versions in potential File I/O misbehavior)ā¦but I do think there is a some evidence that it can cause problems. And anyone should have the option of opting out.
Agreed. Iāve got it on my 9.0 list here:
RH-71881 Autosave: Setting to toggle macOS Autosave/Versions
