Jump to content

Any way to prevent Unity saving/dirtying files locked by another user?


Colin - Stacking Chairs

Recommended Posts

It seems that the default workflow with Plastic Cloud in Unity is to allow saving of local changes to a file that is locked by another user. There is a warning that checkout was not possible, due to the lock, but this can be easily missed by someone in the midst of making lost of changes (as an aside, I see this warning for files I have checked out in the same workspace, when I re-save the scene, for example, which makes it tempting to write off the warning as not relevant). Otherwise, it can be difficult to spot that it didn't succeed in checking out the modified file; Unity itself seems happy enough, and the file is shown as changed in the Pending Changes list with the Plastic plugin.

Only at the point of attempting to commit the file is the user actually hard blocked from progressing due to someone else holding the lock. While this is sufficient to ensure that the lock is respected and another user can't jump ahead and commit other changes, this process can cause a lot of wasted effort on the part of the user(s) without the lock. It is possible for such a user to work for a considerable amount of time on changes to an asset that they subsequently find is locked when they come to commit. It is then non-trivial to know how to proceed; whether to revert the changes to that asset and apply them differently or await the lock being released, or in the case of prefab changes, whether to unpack them so that they can be applied separately in the short-term.

Is there any way for us to block the user at the initial point of failing to check out the asset, please? A modal error pop-up or similar would be impossible to ignore.

With the current workflow, I'm concerned that we'll keep finding that we've been working on assets we can't do anything with, due to a lock contention that we'd missed.

 

I'm aware that we could try a branch per task workflow instead, which might alleviate some of these issues with locking. However, I have a few of concerns with this:

1) My colleagues are not as familiar with version control and branching as I am. Your tools and UI seem to make this quite accessible, but I still worry that they would be intimidated by it and may make mistakes.

2) Branch per task will inevitably add time to each task, and this overhead might be quite significant for members of my team that make a lot of small changes.

3) It's been several years since I used UnityYAMLMerge, but I'm not convinced that it will always work without the need for manual intervention or (even worse) loss of data. So I'd be reluctant to lean on it multiple times per day throughout our production.

 

Any insight on the above would be greatly appreciated. I'm very happy with our initial experience using Plastic Cloud overall, and I'm really just wanted to head-off any pain points as early as possible in our project.

 

Thanks in advance,

Colin

Link to comment
Share on other sites

Hi Colin, thank you for your feedback!

I understand your worry about the time wasted working on an asset that you had no way of knowing it was locked until you tried to check it in. The Version Control package team has plans to continue adding feature parity with Unity Collaborate, which Plastic SCM is replacing. One of the features that we don't have parity with yet are Softlocks (or In-Progress Notifications). I think Softlocks would help address the issues you are concerned most about by letting you know which assets (at least for scenes and prefabs) that a teammate has made changes to so that you can know which assets to avoid making changes to until they've checked in their changes. I can't make any commitment on when this feature will be added, but it is on our roadmap.

As for what you and your team can do in the meantime, like you mentioned already, a branch-per-task workflow would help to mitigate the chances for unintended asset conflicts. Also, even with smaller teams, it can be helpful to sync before you all start working for the day/week so that you can decide on which code/scenes/etc everyone plans to work on or make changes to. While it can add more time to the overall checkin process for changes, the benefit is that you're more in control of when or if merge conflicts happen.

I hope that these tips help and don't hesitate to reach out with more feedback like this. I'll be sure to pass this feedback along to the dev team.

Link to comment
Share on other sites

  • 3 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...