Meet Smart Locks, a new way to reduce merge conflicts with Unity Version Control

At Unity, we’re passionate about enabling creators to do their best work. That’s why the Unity DevOps team is excited to introduce Smart Locks, a new feature of Unity Version Control.

Smart Locks vastly reduces the painful merge conflicts commonly associated with file locks and branching. Developers have long been branching for faster and safer iteration. Now everyone, including artists, can use branching to scale projects with confidence.

Worry-free branching for all disciplines
Smart Locks automatically checks to confirm you are working from the latest version before allowing you to lock a file, so it greatly minimizes the risk of merge conflicts and empowers teams to branch without worry.

If you’re an artist creating a feature branch, a task branch, or a personal branch, Smart Locks provides the flexibility to branch and work in parallel with teammates without worrying about conflicts. You can experiment and iterate faster while your main project history remains safe.

Smart Locks helps you explore diverse workflows. Instead of changing your team to follow your version control system (VCS), you can adapt Unity Version Control to what works best for your team.

How Smart Locks works
Many users believe that simply locking or checking out a file will automatically prevent merge conflicts. Unfortunately, that isn’t the reality.

Traditional file locking mechanisms do provide protection against some conflicts, however, these file locks failed to travel branch by branch, allowing another artist to check out the same file from a different branch. This inability to travel leaves teams vulnerable to merge conflicts by not addressing the underlying workflow incompatibility with branching.

To understand how Smart Locks works, let’s first examine how a merge conflict occurs, even when teams are using file locks properly.


Caption: Before, using file locks with branching left you vulnerable to merge conflicts.

This scenario illustrates how teams using branching frequently encounter merge conflicts, despite their best efforts to use file locking. The result? Wasted time and lowered team morale. Smart Locks solves this problem by allowing users to define a branch as the source of truth.

Whether you are branching or working out of a single thread, the lock will “travel” across branches, following a unique development line, until it reaches the destination branch where the change is checked or merged back in. Smart Locks enforces this single line of development whether you continue working in one branch or move onto creating child branches.


Caption: With Smart Locks, you can branch without worrying about merge conflicts.

All locking requests associated with a given file will now be aware of any new versions existing in different branches. This means you don’t have to wonder if your changes conflict with a teammate’s or if you’re working on an outdated version.

This simple and effective process prevents multiple team members from working simultaneously on conflicting versions, so no changes slip through the cracks. This helps ensure everyone’s artistic vision is considered and makes simultaneous collaboration practically painless.


Caption: You can set custom lock rules, including branch exclusion rules.

Why should artists use branching?
Most programmers, likely familiar with Git-based systems, already understand and appreciate the value of branching. The main benefits of branching for artists is the same as those for coders.

1. Iterate faster
When you work within branches, you are effectively separated from the main history of your project. This isolation enables you to prototype and experiment safely, without having to worry about potentially breaking your project.

Safe experimentation enables you to iterate continuously and build multiple versions, so you can choose your favorite by navigating the repository history. Let the best idea win.

2. Create space for fresh ideas
Branching inherently reduces the noise of simultaneous collaboration. It makes space for the creation of fresh ideas while maintaining a relationship with the original concept. In simple terms, think of the difference between iterating in a Google Doc by yourself versus working in a single document with two hundred other collaborators.

You can generate new concepts without fear of merge conflicts, storing them within your version control system rather than working independently in your local drive or an external source not integrated with your main project.

3. Manage complex workflows
Branching enables teams to break complex workflows into digestible pieces. You can create branches to match how you have organized your project. In game development, it’s natural to partition work for easier project management. For example, you might divide work within a team by features, characters, or even whole levels. Your team can focus on their assigned work within their specific branch.

4. Scale with less friction
Partitioning work within branches enables different teams and team members to work at their own pace, in their own style, and with their own processes – all while simultaneously contributing to the greater project. This removal of friction not only makes collaboration smoother, but your team is also more likely to update your project history with greater frequency. You can ship faster and keep up with gamer expectations.

5. Understand your project’s full history
Branching makes it easier to see the full picture of your project history, while checking changes into main makes it harder to see the full breadth of changes. Branching helps you identify those changes faster.

Branch exclusion for easier experimentation
We designed Smart Locks to give all members of your team flexibility in terms of how they like to work. We also recognize that dealing with complex file locks can be a hindrance in certain situations, like the ideation and experimentation phases of the project.

That’s why, in addition to traveling locks, we’ve also built a new branch exclusion capability. This enables you to exclude branches from the locking mechanism by setting custom lock rules. When you know you will never need to merge back into the source branch, you can prototype or experiment within your branch, unencumbered by file locking restraints.

Enhanced GUI for better branch awareness
To ensure you can keep track of complex projects and enable you to clearly visualize your existing lock list, we’ve also improved the graphical user interface (GUI) on both the desktop client and within uDash. By viewing your lock history, you can easily see who created a lock, and when.


Caption: Intuitively understand your lock history with visualization enhancements.

Additionally, we’ve placed more prominent affordances to indicate how to lock and unlock files, accompanied by helpful messages that will notify you of any existing locks on a specific file.


Caption: Helpful messages notify you of existing locks on specific files.

How to try Smart Locks
To take advantage of this game-changing feature, simply update your Unity Version Control installation to the latest release. For on-prem customers or former Plastic SCM Enterprise customers, you’ll need to update your servers and clients to fully experience the benefits of Smart Locks.

Be sure to read the documentation before you get started.

New to Unity Version Control?
Unity Version Control is an engine-agnostic version control tool with the agility to handle large files and binaries at speed. With optimized workflows for both artists and programmers in game studios of all sizes, you can improve team collaboration and increase productivity to deliver high-quality games faster and more efficiently. To get started for free, enroll in Unity DevOps.

3 Likes

We’re Plastic Cloud users deep in production and don’t want to update Plastic SCM versions, and nobody on our team is able to check-in prefabs after returning from the holiday break. The prefabs aren’t checked out by anyone as far as we can tell. Is this supposed to be opt-in or do we have to get everyone to upgrade?

Edit: I’m catching up on some of these changes and the behavior we see is - the person trying to make a change is the person who the lock is assigned to on the Smart Locks dashboard, but they get an error saying the file was locked when trying to check it in.

Edit 2: Verified that upgrading the local Plastic client allows the user to complete the check-in. The new features for Smart Lock sound cool, but this is a pretty frustrating curveball to break exclusive file checkouts without a client update, would appreciate a heads-up in the future if there are going to be changes that require everyone to upgrade so we can plan for them without disrupting our team.

9129919--1267441--image (5).png

2 Likes

Can we disable smart locks on Cloud and revert to the previous functionality? My team are getting new errors that don’t seem to make sense.

When trying to checkout a “retained” file my teammates are getting this error:

They are already on the branch with the latest changes, and the workspace is updated and there are no pending changes.

As much as I am very excited to have these Smart locks, this is highly frustrating as we’ve been suddenly opted in without a choice and it’s now preventing work.

Edit: We can manually remove the locks as a workaround for now. But I think that probably shouldn’t be required - is that a bug maybe?

1 Like

We’re also running into this now, and think we found a bug with it. If you check in partial changes to a different branch, the locks get stuck in the “on” state in the branch you started from, and the only way to get rid of them from there is to manually release the locks from the dashboard. Plastic SCM is usually reliable and predictable but this is creating a ton of problems for us. We had to completely delete all of our lock rules until we can make this less disruptive. Would really like for this change to be reverted on the server side, or at least for the old behavior to be exposed as an option we can enable on the dashboard.

We are sorry for your frustration and we acknowledge that there’s an adaptation period that can affect your current workflow, in general, we expect that it should be quick once you grasp the new mechanism. Please refer to the official documentation to get more detailed information on how it works.

In summary, when you check in a change in a branch different than /main (destination branch), let’s say /new, the lock gets a Retained status which means that the file is not being modified at that time but that this new version is now considered the latest one. From that point, you can continue working on that file, whenever you are editing the Retained revision, in this case when you load the last version of /new. However, you are not able to edit the file from any revision other than Retained, this way we prevent the creation of parallel changes that cannot be merged later. This lock will be completely released once you integrate the /new into /main.

In the particular case of a partial check-in as you describe, let’s dissect that:

  • You Lock and Check out 2 files, A.prefab and B.prefab in the /main branch, both are locked due to the existing lock rules
  • You Check in A.prefab into a new branch /main/new
  • Now you get A.prefab in a Retained status in the branch /main/new
  • And B.prefab in a Locked status in the branch /main

It might feel strange but the state described above means that A.prefab in the branch /main/new is now considered the latest version, therefore you or any teammate can Check out, and continue working, or merge it to /main and completely remove the lock.

However B.prefab continue locked by you, so can continue working as usual, you can Check-in (or Undo) the change, and the new version will be created in the branch /main/new, as expected. What might sound strange is that the GUI will inform you where this lock was last updated, in this case, /main, but it doesn’t mean that you must Check-in into main. In this particular scenario, using “Check in changes to different branch”, the branch info of the Locked item can be out-of-date for a while (it will be updated after running Check in or Undo), but you can continue working normally.

I hope this helps you get over this and start enjoying Smart Locks. If you ever need extra help please reach out to our technical support which will be able to provide you with further assistance.

This has also been quite frustrating for us the last day. I feel like a change like this should have had the ability for the customers to opt out of it. Or even to opt IN to it. Not something that’s just applied to production one day and everyone has to like it or lump it.

This is especially true since a lot of these locks and merges that are giving the problem were done before any of this Smart Locks stuff was introduced. So retroactively, the thing we did is considered “wrong” and not allowed, even though at the time it was perfectly fine and allowed.

1 Like

This assumes we regularly check-in to the “main” branch. We do not, and reserve “main” for major releases. All of our work happens on child branches and this system is incompatible with that.

Respectfully, the problem isn’t about eventually learning or adapting to a new system. We switched to Plastic from P4; we understand that it can be worth the time investment to learn to do things a new way. The problem is that it is disruptive and expensive for us that Unity released an update with zero notice that brought our team’s ability to collaborate to a halt, and is asking us to retrain our team and rework our internal build pipelines to accommodate a new workflow when we’re trying to ship things.

Teams need to be able to evaluate new technology and workflows when it is convenient for them. This is the first bad experience I’ve had with Plastic - it’s been an outstanding piece of software with consistently great support - and I really hope you can find a way to unravel this for the teams who need to keep the old functionality for now.

3 Likes

I filed a support ticket and thankfully unity was kind enough to help us figure out how the branch prefixes work, but also informed us that we can’t turn off smart locks for plastic cloud which is very frustrating and ignoring smart locks per branch is a huge pain.

Here is what I wrote directly in the off chance this feedback isn’t properly reflected to the right people.

This is a bit frustrating since the old method at least doesn’t restrict certain merges like we’ve shown below. In our case, we will add ignores per branch until there is a better way. -.- (As GMG-Sam Noted above)

Feedback for rolling out features like this.
Can we get a heads up that this is coming next time?? Some sort of week or 2 warning in the plastic client so we can at least plan for it in the schedule?

Feedback for Smartlocks++ or alternative smartlock behavior options.
We simply just don’t use branches in a way where multiple artists are in their own separate branches. Typically they are in platform or feature branches collectively and anything that is changed in those stays changed in those. Very rarely do we expect to merge from a platform branch back to main without conflict since typically those branches require specific changes to make it work on that platform. This means that we would at times have multiple people in Branch A and multiple people in Branch B making changes to the same assets not expecting those changes to merge back to main.

For the smart lock system to be beneficial for us, it would lock the file only for people in the same branch. There wouldn’t be a need for the retain or release lock workflow with this case which is much simpler.

The way we could see something similar to smart locks being beneficial for us.
Example
BranchA - Platform Release A
BranchB - Platform Release B

User and intention
UserA - Plans to work on file in BranchA and submit its change in BranchA
UserB - Plans to work on file in BranchA and submit its change in BranchA (Same as User A)
UserC - Wants to change file in BranchB and submit its change in BranchB

  • User A Locks the file in BranchA by checking it out
  • User B goes to change the file in BranchA and cannot because it is locked.
  • User C goes to change the same file in BranchB and is able to do so and check it in after being warned that it is checked out in BranchA. (This way they at least know this file has been changed or is currently being changed in other branches, but its perfectly fine for them to edit and submit the changes in branch B)

We really do like using plastic, but honestly it seems like it’s heading down a slippery slope each update which is a bit disappointing. I hope I am wrong because it’s been great for the last 4 years for us!. -.-

2 Likes

Hello all, on the rollout communication you are all absolutely correct, we should have warned before and kept you all informed previously. We apologize you are having to deal with this surprise release that generated friction for you all, we’ve learned our lesson and’ll improve our process for upcoming releases. I’ll try to address some of the doubts here, but again, if you ever face any issues and need help, please contact our technical support to better help you.

Not necessarily, you can configure a different destination branch for locks, other than /main. Imagine you have an /art branch and all locks start there and merge back there, it would be no problem. Additionally, the new workflow doesn’t assume you need to check in to the /main branch, on the contrary, whenever you check in a change, that originated in your destination branch (/main is the default), you can lock and check-in in child branches without worries, because the new status ‘Retained’ will track the latest version and any user can check-out and modify a ‘Retained’ file in a child branch. This guarantees a single line of development until you merge back to your destination branch.

We are taking care of your support ticket, we hopefully will have it sorted out shortly.

Anyway I hope it helps give you clarity as to how it works, and we’ve noted the feedback, it’s very appreciated.

1 Like

Ok,

so after this change, I can no longer checkout a file in the branch I’m using even though I have the most recent version of it based on history. Any ETA on when this will be resolved? If I switch into our main branch and try to checkout the file it works (but is outdated).

Hi @niki_unity224 , if you are stuck, can you open a ticket at devops-vcs-support@unity.com?

Ok, If anyone runs into the same issue. Since our branch got created before smart locks got introduced and had changes the system got confused. We were able to resolve it by manually creating a smart log and giving the system the information it would need.

cm lock create br:<your branch> item:<path to item to lock>

3 Likes

Now I wonder just how many of the horrible issues we ran into with Smart Locks was simply because they didn’t provide proper handling for work done before the feature was added. We got into some real snarls that were only solved by doing some very bizarre shuffling of files around.

I’m getting the same error.

To me, it’s a baffling rollout decision to push a feature that:

  • Affects all users regardless of their Plastic/Unity version
  • Is not an opt-in, does not even result from a user-decided upgrade
  • Cannot be turned off
  • Blocks commits to production projects

I’m on a deadline today and, without any change on my usual workflow, I can’t check-in my changes anymore. Fantastic. Now I have to update my whole version control client – who knows what other issues this might bring?

Please reconsider not being allowed to turn off smart locks from the Cloud Web GUI, and please do a post-mortem about how a feature that can affect version control can push breaking changes to live users without them opting-in. It’s terrible practice.

1 Like

Hi, if you are stuck, can you open a ticket at devops-vcs-support@unity.com? We are open to reviewing in detail your workflow to propose the best approach with smart locks and also assist you if you are facing any error.

We will also arrange a meeting, if necessary.

On one project can you divide different teams as organizations? So the art team only has access to certain folders while the programmer has access to others and some common folders that everyone can have access to? and maybe QA team can only download but never be allow to submit anything.

Would be nice to be able to lock files by different teams

1 Like

How can we disable smart locks?

2 Likes

Hi
In our company I have all the users requesting if we can remove the feature. We are loosing a lot of time trying to bypass a new problem we didn’t have. @vitor-unity . For example:

  • User A creates a branch /new and locks file File1,
  • User B needs to fix something in File1 which is more important/urgent than the feature in /main/new. Does a new branch /main/urgent from /main to fix the problem, not having the latest version.
    He can’t make the any change because File1 is locked until /main/new is merged again into /main. Which sometimes we don’t want, we can’t or simply the branch /main/new will never be joined to /main.
  • User A is unable to fully release the lock so userB takes ownership of the file.
  • The admin can remove the lock, but branch /main/urgent can’t be merged because it keeps saying the File1 didn’t start from the latest version and refuses to merge. The admin can’t solve this. I don’t want to open a support ticket for every time this happens.

Other problems have appeared because some locks were created in branch before the feature was deployed. We

If the branch /new is never joined to main, can we fully remove any trace of the lock for File1, so the users can create new locks on that file?

You can remove the lock wherever you want. You shouldn’t be ever stuck. If you want to perform changes in a “/main/urgent” branch, you can run:
cm lock unlock --remove

It’s important that /main/urgent was created from the latest in /main to load the last version from /main and avoid conflicts.

If the branch /main/urgent already contains a revision for this file, you can create the lock to say that the last valid version is the one in “/main/urgent”:
cm lock create --help

  • If the lock was removed (see above), you will always be able to merge your branch to /main.
  • If you cannot, it means the lock was not removed and the lock is somewhere else. You could merge from /main to your task branch (rebase) and after that, you can merge your task branch to /main.

If you open a support ticket with us, we are open to arranging a meeting to be sure you are not stuck and review in detail your workflow and how you can continue working in every scenario using smart locks.

Thanks, will try from the command like next time.