Jump to content

Preventing conflicts in scene files


Ron

Recommended Posts

Hi,

Recently we have started using PlasticSCM with Unity and we are running into a usability issue with our Scene files. I am wondering whether we are doing something wrong is whether this is the way it is supposed to work.

We are using the Cloud edition and everybody is using the gluon approach (i.e. submitting directly to the main repository in the cloud). I have set up the server to lock .unity files to prevent people from working on the same scene files. This is technically working but in practice it isn't particularly great. Let me describe a scenario to illustrate that:

Let's say developer A has started making changes in our Scene. As a result the scene file is automatically checked out and everything is looking good. Now developer B also starts editing the same Scene on his/her machine. At this point, when they try to save the changes, the changes are actually stored in the .unity file but it won't be checked out (as it was already checked out by developer A) and Unity will only show the .meta file in the version control window (I didn't set these to locked yet). Now, only when developer B is ready to submit their changes will they notice that their file doesn't show up (or if they are not paying attention they might even mistake the .meta file for the .unity file and think they have submitted). If they go to the Gluon interface they can now see that the file is in he list of changes (as it has been changed) but they can't submit as it isn't checked out. But finding out then is too late as they will lose all the work they have done (as we can't merge they files which is why we set them to locked in the first place).

So the system that checks out the scene files automatically when you edit them but still silently allows you to edit them without checking them out if they are already checked out causes a lot of confusion and frustration. I would expect that it would be impossible to edit a file that is not checked out (like it works for settings files). 

My question now is: Is this expected behaviour? Are we doing something wrong? 

Link to comment
Share on other sites

Hi @Ron,

this is indeed a problem. It works in this way and it's in Unity hands to be resolved.

Right now the checkout operation is requested to the SCM plugin when the file is saved, not when the file gets modified. It would be great if Unity could request us to checkout the file when the user starts modifying it, it would save all the problems you are getting.

Not sure if you can write about this at the Unity forums, it would be a great improvement for the users.

Link to comment
Share on other sites

Hi @manu,

I understand the problem with only getting the request from Unity when the users tries to save the file, but even then it would help if it would just not allow the changes, or at least give a big warning. At the moment the disparity between the view in Unity and Gluon is the cause of half of the confusion.

As for the Unity forums: I already did earlier today :)

 

Link to comment
Share on other sites

Hi @Ron,

yes, I can several weird things going on:

1) The meta file gets checked-out without the scene file -> They should always go together.

2) You don't get a proper error when the checkout can't be performed, you just get this at the bottom of the screen:

image.png

I will try to know if it's something that can be improved.

On the other hand you are able to know if a file is already locked by the blue lock icon:

image.png

 

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...