Working with Yosemite and I was just curious about saving and revert changes. I work in a team of 4 people, 2 OS X Rhino & 2 Windows Rhino. We are building a cloud library of common files. For example, round gem sizes we all use.
I believe I have the Auto-Save & Versions down, but to help with the windows users, I have to let them know that if I “Revert Changes” when I close a common file, it will not affect them. And as long as they don’t save, we should all be fine working with common files? … Correct?
I can tell you of one experience - I have demo files for my class, demos which I do on both Mac and PC side by side - accessing the same file. If I first access the file on the Mac side and start making changes, these changes are saved back to the original file without my asking. If I then open that file from the PC side - while the file is still open on Mac - I see the changes made with the Mac (without having explicitly saved them). So my demo isn’t at “square one” anymore. The file locking thing that normally happens with 2 PC’s accessing the same file doesn’t happen with a Mac +PC either.
This is annoying to me, but admittedly it’s an extreme case. On the Mac I have inadvertently overwritten my demo files - with which I normally never save the changes - probably because I forgot to click “revert changes” when closing. The two systems - automatically saving everything vs. not saving anything unless the user asks - are just fundamentally incompatible…
My initial reaction to Autosave and Versions was quite negative after years of my tried and true methodologies. In time I’ve made peace with both and have since see the benefit under certain circumstance, as well as negative aspects under less simplistic scenarios as described by Helvetosaur and rhinorudi.
Still, if technically possible, my opinion remains that Autosave and Versions should be features that one may choose to disable. Personally, I have no gripe with both being a default feature in Rhino OS X.
I don’t foresee many issues, just Future proofing, if that is possible. Usually it is just with layers, Turning on different ones to access the required object.
@ec2638 I always liked the AutoSave Versions right from the start, But changing 20 years of save as is hard. As myself working, I had to use versions about 20 minutes ago. Trimmed a wrong complicated surface, and it was a lot easier to Revert to a version from this morning, copy command+C the surface, revert back to current model and paste, A lot easier than rebuilding the surface.
My issue is different people working on the same file. I think Mitch explains some circumstances perfectly.
Saving is fundamental of course. My vote/preference is for Mcneel to engineer enable/disable in properly via Preferences, when released. If Autosave is a value-add, which I think it is, then the ability to not utilize such, if deemed appropriate by the user/circumstance, adds value too.
If that happens then I"ll need to remember to save the old school way again…
Well, one thing that might help is read-only and file locking. Can you easily make a file read-only on Mac? If so, your ticket to not having important files altered is to make them read-only. I haven’t tried this, but if I have a Rhino file from my PC that’s read-only in my Dropbox, and I open it in MacRhino and start making changes - what happens?
You also shouldn’t be able to have more than one user actively working on the same file at the same time. This is the way Windows works with the auxiliary .rhl file, one person (the first) can open the file to work, others can only open it read-only.
One thing is for sure - there will be offices where a number of people working on both Mac and PC Rhino will be collaborating on the same project. So this sort of thing does need to be handled smoothly.
This can be done, but I think i have to explain the situation better.
We do’t “work” on the file, per say. It is more the opening a file, selecting an object on a layer and the pasting it into another file before closing it. Another person may have to do the same thing but with an object on a different layer. So the file cannot be READ-only. Most days we are all in the same office, so not as much of an issue. It is for the times we are working away or from home etc…
Since we are setting this up, we were wondering what the problems may be.
@jeff_hammond, thanks for the Terminal tip, though I prefer to have it on when working on my own. I do like the way versions & autosave work.
@rhinorudi Read-only only means that you can’t save changes in the file. Otherwise you can open it, copy anything you like, work just as normally - just that if you want to save the changes you made, you have to use SaveAs and save under another name.
you can make a file on mac read-only by right-clicking on it then ‘get info’… at the bottom of the panel, there are sharing and permissions options.
the (possible) problem with that is it locks the files so when you open it in rhino, you can only navigate the file (or do other things which don’t affect it like select and copy to clipboard)… if you try anything else, you’re prompted to either duplicate or unlock (or cancel)… once you unlock it, it’s read/write again or if you duplicate, you’re now in a new file… so the concept of read-only on mac seems different than readonly on windows.
a quicker way to lock a file in (supported) mac apps is via the window title… click on the file name at the top of the window and from there, you can tag/rename/move/lock… when locking this way, the icon will have a little lock graphic attached to it.
yep… although for clarity, i think it’s osx autosave which starts writing first as opposed to versions… versions will save every hour unless manually triggered (⌘S)… Autosave is every 5 minutes…
on windows (and some mac apps that don’t use OSX autosave), a new file is created in an autosave folder or user assigned location and that’s where the autosave info is being stored… on mac, the autosave info is going to file itself… (unless it’s a new/unsaved file… then a temp file is created for autosaving to)
(with autosave info being used to restore the session in event of a crash… and Versions being used as more of a workflow type of thing)