Workflow for teamwork with Dropbox? "Revert Changes" causing lost updates

It might be a good idea to move files out of the Dropbox directory while actively working on them, so they can’t be opened by the other party while being edited.

Dropbox likely isn’t as aware as it could be of files being open, since it’s not really a shared filesystem, but a sync conduit that merely looks like a shared filesystem.

Or into an unshared folder. I keep all my work in Dropbox, but mostly I am the only one to see that folder.

Thanks @rhinorudi, but on my Mac, “Revert Changes” writes a new fresh copy to disc (as far as I can tell), so I’m not sure I agree with you.

To complement the scenario, here’s what we do:

  1. I create the drawing and e-mail my colleague
  2. He makes some changes to the files and calls me on Skype or phone
  3. With him on the phone, we discuss the changes, and to understand them, I obviously have to open the file up.
  4. While on the phone, he makes some more changes in his copy of the file
  5. When we are done, I can’t close Rhino unless I save the file to either a new name or do “Revert Changes”. If I do “Revert Changes”, which has happened in the past, I overwrite his changes

It doesn’t seem like “Rhino for Mac” respects the “Rhino for PC” created .rhl file that is being synchronized by Dropbox. If my version of Rhino would realize the the model is locked by another user by the presence of an .rhl file, the problem would be solved. Other software packages work this way - for example Enterprise Architect, which I have used in my previous life. It also relies on a database file format (.eap) which is much like .3dm.

It doesn’t. I remarked about this a long time ago during the Beta process… --Mitch

In theory it is the same, I never look at the timestamp, so that is not important to me. It should still be the same file as your original one before you opened it.

I am not sure what you mean by respect, if you mean your rhino won’t open because of the hi file, you have to understand how Rhino actually works. There is another thread here somewhere explaining the process. Basically when you open Rhino, Rhino creates another file, so there are actually 2 files open of the same model on the computer that opens the file.

If only one person is making changes, then all you both do is “Save the file”.

If he makes changes on his PC, then doesn’t save all his changes are lost. If you make changes and “Revert Changes” all your changes are lost.

Make sense?

This can be done, it has no relation to the hi file though. One of you just make the model read-only, before you open it.

It seems we are discussing different scenarios and I’m not expressing myself clearly enough. Here is how the problem could be tackled:

  1. computer 1 opens the file, an .rhl file is created
  2. the .rhl file is propagated through Dropbox to all computers
  3. when user on computer 2 tries to open the model, the .rhl file is spotted and the model is opened up in read-only

Obviously, there are intricacies with how to deal with delays, asynchronous operations, and unreliable internet connections, but still - the above is what I would expect. If the model was sitting on a shared file server, one would expect this, no? If not, what is the purpose of the .rhl file?

What would also solve this issue is that I could simply quit Rhino/close the file and the original file that was opened is just left in the exact state it was when it was opened.

I’m telling you again - when I close my file and say “Revert Changes”, it does not simply close the file and leave the original there. It puts back a fresh copy of it that looks like the original.

Of course! As expected. He does save the changes.

Of course!! As expected. But with the added bonus of my colleagues changes also being overwritten by my copy (that Rhino writes back on disc) with the original version.

Sounds like something on the wishlist for V6.

Of course, because Revert means you are undoing any changes. Try save instead, I may have to do a test on this when I get together at the office tomorrow.

Of course, see above. So you both have to save the file (not revert), one at a time to keep the changes if you are both working on a the same open file.

This already works on Windows. The second “opener” of the file is given the choice to either open the file read-only or not open it at all.

–Mitch

So I guess we have to ask to make this cross-platform, if it is possible?

Already on the “issues” list - http://mcneel.myjetbrains.com/youtrack/issue/MR-2008
Unfortunately, not slated to make it into MacRhino until V 5.4

–Mitch

So then it is up to the person not editing the file to make it Read-Only like stated above.

I will do a little test tomorrow, maybe today if one of my colleagues comes online.

As A test here, I created a file, closed it and made it read-only to me.

I then open the file and tried to make a change. This is what I got …

So I guess for now that would be a work-around.

At this point it is getting to be my 5¢, not 2¢. FWIW

Thank for the input, @Helvetosaur. I’m from the PC world, where most software behaves like this and it’s taken for granted. I haven’t worked in a team environment before on Mac.

Not sure how I feel about having to create a temporary copy in order to be able to view a file without modifying it on disk…

Is there a feature request logged for correcting the behavior of “Revert Changes” as well? If not, I’ll have to log one.

Thanks all for outlining the workflow and problems with the current setup. I think I understand the issue you are having @ola_strandberg. I’m sorry the work-arounds for this are awkward.

@Helvetosaur is correct, cross-platform file-locking is something we will be working “soon-ish.” Fixing this will be important for the Worksession feature. Whatever fix we institute, we will keep the workflow you have described in mind… I doubt it is uncommon. That said, the fix might not be as straightforward as we’d like and - until we dive in further - it’s difficult to say what will (and won’t) be possible in the 5.x release cycle for Rhino for Mac. The reason for this is that it is highly unlikely that Rhino 5 for Windows will change to accommodate. (The V6 release cycle is another issue, entirely).

If I’m understanding the behavior you would like to see, I’m not sure that there is much we can do. As @rhinorudi says, this is OS X provided behavior. So if you wish to log an issue, it’ll probably have to be with Apple. That said, if we can manage to get the file-locking working properly cross-platform, we should be able to give you very clear warnings so that you don’t lose work.

the way i understand it to work is more like–
open a previously saved file from dropbox and draw a line (or something to put it in an edited state)… after a few minutes, it will autosave and the save is going to the .3dm you have opened… dropbox notices the change and syncs… the file itself is continuously changing on mac… likewise, dropbox is continuously syncing… then when you do a Revert, it does a final save/sync with all of this sessions actions undone.

there are a few problematic things that can be brought up about this but from a consumer pov, i suppose one major thing to realize is if you’re using tethered data on one or more of the computers… if you’re modeling while tethered, you may be unknowingly using cellular data… disconnect after getting latest version and reconnect upon saving so it only syncs that one time.

i think dropbox (and others) are aware of problems in cloud type collaborations or multi machine workflows… here’s a thread from a couple of weeks ago which relates to this thread

http://discourse.mcneel.com/t/dropbox-badge/24570


also.
something that will sometimes happen to me which i haven’t really looked into is i’ll end up with new files in dropbox named such as:
HCouture_GamingTable_Shop (Jeff’s MacBook Pro’s conflicted copy 2015-08-19).3dm

instead of looking into the exact cause of that or even figuring out what state the files are in when it happens… i just try to prevent having the same file opened on two computers at once… as well as try to be a bit more clean with the workflow (not leaving files open when i leave the desktop etc (which is how this has typically happened for me… model on the desktop… go somewhere… open the file on the laptop… the file is now open on two computers…) so i just try to prevent that.

something new i just noticed is if you right-click a file in that’s inside your dropbox folder, you’ll now have an option “View previous versions”… (dropbox 3.10.7 / el capitan… not sure when this first began though.)

choose that and you’ll go to a web page:

click on one of those versions and the file downloads (as in- to your downloads folder)… you’ll have your current version untouched in the dropbox folder and a new file in downloads at whichever state it was in at the time of sync you choose.

that’s pretty neat though i’m not sure if i can make use of it other than file recovery if needed.


but, you can look at my versions log and see how often a file may change and/or sync to dropbox throughout a session…
you can also see i did some stuff prior to lunch which brought the file up to 13MB (probably copying a portion of the model then manipulating it on the side…) …after lunch, the file was still open… did a Revert and the final sync of the day went back to the 9MB size… or- this is (possibly) a clearer example showing that even though a Revert was done during a dropbox session, it doesn’t mean the file was never being modified and/or causing conflicts like ola is saying.

Thanks, @dan and @jeff_hammond wow, workaround or not, it seems like it might make sense to keep working copies out of dropbox anyway. It’s neat to be able to revert to all these snapshots, but probably not necessary.

I have a career in building enterprise software systems, so completely understand that my scenarios are on a very high level. I hope there is a workable solution in the future - in a combination of Rhino + Dropbox + Mac.

I totally didn’t think of AutoSave being the culprit, and you’re totally right, Jeff. Mac OS X is continually saving versions back to the file’s original location, and Dropbox is probably seeing those updates as new versions to be synced, so it uploads and pushes those auto-saved files out to everyone connected to that directory. I can see how that would become a mess very quickly.

It would be great if AutoSave could be disabled on a file or a directory, specifically for situations like these.

I’d probably rather see a solution for this happening on the Dropbox side as opposed to the rhino side.
like some sort of setting in Dropbox that will prevent a file from syncing while it’s being used (unless explicitly told to sync). then when the file is finally closed, the sync happens. or maybe this pref already exists?

that way, we still get the OS X versions/autosaving (which personally, I wouldn’t want to turn off just because I’m working with a Dropbox file… I’ve been saved too many times by autosave in the event of a crash to want to turn it off.)

ditto,and what Jeff said in the first paragraph.

I did see that “View Previous Versions” for Dropbox is also an option on Windows.