Multiple users using one file

Replies to This Discussion

Permalink Reply by taz on August 11, 2011 at 11:10am

Have a look at the Rhino Worksession Manager...

*********

Manages a list of models that can be used as reference geometry.

The Worksession command lets many users work on a large project by breaking the project down into many files. Each user can edit a different part of the project and see the related portions of the project simultaneously. By refreshing as needed, each user can see the current version of the related portions of the projects. Only one user can have a file open for editing, but many users can see it.

The attached file can be in any format that Rhino can import, not just Rhino models. Attached geometry cannot be edited (Move, Scale), but it can be used for input to creation commands (Copy, Extrude).

The attached file geometry appears on a unique set of layers under a parent layer with the name of the attached file, and the attached file layers as sub-layers of the parent.

You can change the layer state of reference layers (Color, On/Off, Locked, Print Color, Print Width, Linetype), but you cannot add new layers to or delete layers from the attached file. The list of attached files are not saved in the current model file, but are saved in the worksession file (.rws).

 

Permalink Reply by Luis Fraguada on August 11, 2011 at 11:36am

Taz, are there any benefits of using worksessions over inserted blocks?  Blocks can be linked from a file through the block manager.  Just wondering what the trade offs are...

Permalink Reply by taz on August 11, 2011 at 12:20pm

My sad confession is I haven't actually needed to use WM.  Someone else will have to weigh in on functionality/performance vs BM...

Permalink Reply by Arie-Willem de Jongh on August 11, 2011 at 11:32am

thanks taz!

i feel kinda stupid for not figuring this out by myself :)

cheers!

Permalink Reply by David Rutten on August 11, 2011 at 11:59am

Grasshopper behaves somewhat different than most programs when it comes to files. When you open a file a program typically locks that file, so nobody else can change it. Grasshopper doesn't. I don't really have a good reason for not doing this, maybe I should be locking.

 

The biggest danger here is that's now quite easy for multiple instances of Grasshopper to open the same file, and whenever one of them saves, it will undo the changes saved by the other and vice versa.

 

Locking will stop this from happening, but it won't solve anything. Any ideas about how to make it so that multiple people can work on the same *.gh file are welcome.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Michael Pryor on August 11, 2011 at 12:50pm

Maybe like the save state manager there's a user state manager, and so there's one "master file" but you can flip between multiple users states of that file. maybe there is also the possibility of trading pieces of definitions between user states. So basically, person A makes a master file. Person B and C are working on the file separately. So you have master A with user states B and C. User C can open user B's state and take from there definition or they can modify user B's definiton but when they save it now becomes the state of User C, still keeping user B's stopping point as it was. That make sense?

Permalink Reply by David Rutten on August 11, 2011 at 2:42pm

But wouldn't you ultimately want the changes from user A and B apply to the same file? Putting multiple files into a single *.gh blob doesn't accomplish much more than just having multiple files to begin with.

 

The biggest problem is always merging changes from multiple users. We (McNeel) use Tortoise SVN to manage source code. Every developer has complete source on their machine, and when they change their local copy, they need to 'check in' the changes to the central repository. You're not allowed to check in files if someone else has updated the file since last you 'synched' with the server. You have to first get the changes from the server and then the source code is merged on your local machine. The source merging algorithm in Tortoise is pretty good, it rarely chokes.

 

Unfortunately I cannot use a similar approach to Grasshopper files. The gh and ghx files are too fragile (if that's the correct word for it). Just combining two files in all likelihood will not give you a valid result.

 

This is how I imagine it should work, when two or more people work on the same file. Everything is the same as it is now, except maybe I'll lock the file, to avoid people overwriting it in turn. Then there's an option to 'lock' part of the file. Say you want to work on only the facade, you don't care about foundation. So you select all components that are important, and you request ownership. Anyone else who now opens this file, will see those components locked and won't be able to change them. When User B saves her part of the file, everyone else who has that file open will see that there's something to update. Ideally I'd even like to see a way to talk to User B using some form of in-program chat, so you can ask relevant questions.

 

 

All this stuff is pretty complicated, especially when Users A and B are on a network.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Michael Pryor on August 11, 2011 at 3:01pm

So basically what your saying is similar to when user A is working on a live autocad drawing (user A's claimed piece of the GH definition) that has another drawing xrefed in(user B's claimed piece of the GH definition), when the xref(user B's claimed piece) is changed user A gets a notification to update/reload the xrefed piece. Also, similar to the way Indesign works. I think this is what I meant to describe but I failed. I like it.

Permalink Reply by Michael Pryor on August 11, 2011 at 3:17pm

Now I'm thinking what if 1=foundation , 2=floor 1, 3=roof. So consider each of the 3 built as a cluster. There is a master file that when opened simply shows 3 clusters connected. User B opens the master file and notices that there is a lock on cluster 2, when hovering over it it says User A has it opened and maybe has a back log of recent saves. so user B goes to work on cluster 3, he clicks cluster 3 and it's contents explode outward revieling the definition of the roof. Now in User A's file cluster 3 has a lock on it. User B finishes and saves and closes an the definition folds back up into cluster 3 and now cluster 3 in user A's file has an update symbol. User A clicks it and now the roof is updated in user A's file.

 

Permalink Reply by Kadim Alasady on January 11, 2019 at 8:55am

David,

Did you ever figure out a way for multiple users to use one GH file?

Kadim

Permalink Reply by dvdrbls on August 11, 2011 at 12:43pm

ithink this is a really good idea, i will like to have an open file betwen two or more users and be able to changue it in turn, save mode must be validated and save as can make a copy appart, this can be great for teaching-learning process

is there a way where i can see what the other user are doing in the file, i mean putting components and wire them in the definition?