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

vitor-unity · Jul 3, 2023

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.

mpgholden · Jul 6, 2023

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.

GMG-Sam · Jul 7, 2023

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?

mpgholden · Jul 7, 2023

GMG-Sam said: ↑

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:
View attachment 1267513

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?
Click to expand...

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.

vitor-unity · Jul 7, 2023

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.

jasonpierce · Jul 7, 2023

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.

mpgholden · Jul 8, 2023

vitor-unity said: ↑
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.
Click to expand...
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.

TPGZuko · Jul 8, 2023

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!. -.-

vitor-unity · Jul 10, 2023

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.

mpgholden said: ↑

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.
Click to expand...

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.

TPGZuko said: ↑

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.
Click to expand...

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.

niki_unity224 · Jul 12, 2023

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).

carlosalba1985 · Jul 12, 2023

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

niki_unity224 · Jul 13, 2023

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>

jasonpierce · Jul 17, 2023

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.

LazloBonin · Jul 17, 2023

GMG-Sam said: ↑

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:
View attachment 1267513

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?
Click to expand...

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.

carlosalba1985 · Jul 18, 2023

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.

Ereroa · Jul 18, 2023

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

spear_unity · Jul 20, 2023

How can we disable smart locks?

john_unity746 · Jul 20, 2023

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?

carlosalba1985 · Jul 20, 2023

john_unity746 said: ↑

n 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?
Click to expand...

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 <file> --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

john_unity746 said: ↑

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?
Click to expand...

- 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.

john_unity746 · Jul 20, 2023

carlosalba1985 said: ↑

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 <file> --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.
Click to expand...

carlosalba1985 said: ↑

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 <file> --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.
Click to expand...

Thanks, will try from the command like next time.

TournesolBancal · Aug 21, 2023

Hi everyone,
I have been waiting for smart locks a long time, and I’m very glad it’s finally there.
But I can’t seem to have a productive workflow with it.
An example:
* I change a few files save them and realise they need to be locked so as to avoid others to modify them before they merge my branch.
* So I try locking from Workspace explorer, turns out it’s impossible because the file is checked-out and I need to revert my changes then take the lock then reapply my changes.
=> seems like an incredible hassle.

Also another remark: I think we need to be able to lock from pending changes, because nobody is going to navigate to every single file in workspace explorer.

The feature is otherwise sounds, seems to me with very few UX improvements it will be perfect

carlosalba1985 · Aug 22, 2023

TournesolBancal said: ↑

I have been waiting for smart locks a long time, and I’m very glad it’s finally there.
But I can’t seem to have a productive workflow with it.
An example:
* I change a few files save them and realise they need to be locked so as to avoid others to modify them before they merge my branch.
* So I try locking from Workspace explorer, turns out it’s impossible because the file is checked-out and I need to revert my changes then take the lock then reapply my changes.
=> seems like an incredible hassle.

Also another remark: I think we need to be able to lock from pending changes, because nobody is going to navigate to every single file in workspace explorer.

The feature is otherwise sounds, seems to me with very few UX improvements it will be perfect
Click to expand...

It doesn't seem to be realted with Smart Locks but also with the legacy lock system, right?

If you enable file locks, you will need to change your workflow to always checkout the files before modifying them (you can force it if you are using the Unity Version Control package).

TournesolBancal · Aug 23, 2023

> It doesn't seem to be realted with Smart Locks but also with the legacy lock system, right?
I don’t have experience with the legacy lock but you are probably right.

>(you can force it if you are using the Unity Version Control package)
If it’s possible to do so via the package I am surprised it’s not possible to do it via the plastic client. I am talking from a perspective of someone who cannot use the Unity version control package.

carlosalba1985 · Aug 23, 2023

TournesolBancal said: ↑

If it’s possible to do so via the package I am surprised it’s not possible to do it via the plastic client. I am talking from a perspective of someone who cannot use the Unity version control package.
Click to expand...

You can also check-out the items via the Plastic GUI. But you need to remember to do it before editing the files on disk with your editor.

GMG-Sam · Aug 23, 2023

Some feedback:

Currently if you merge from a branch that has a retained lock on a file, and it has a conflict with your current branch, and you keep the destination version rather than the locked version, you enter a stuck state where your branch does not have the latest locked version of the file, but you've already merged from that version and can't merge again.

This scenario is causing problems for us, and it's hard to resolve because you have to manually release the locks and create them again in the resolved branch, which is hard to do for a lot of files.

I think in this scenario, resolving the conflict should move the lock to the resolved CS and the latest version should be considered the version in the merge CS.

GMG-Sam · Aug 24, 2023

We have just run into and resolved another locking issue where two different users on the same changesets were getting different results trying to checkout a file.

User A could lock and checkout the file, and undo, no problem.
User B when trying the same thing, got "Cannot checkout because you don't load the latest version in /main" even though both users are on the same changeset with no pending changes.

For context, at this point the latest version of the file is on the branch that both the users are on, but there is no lock present.

Eventually, we did a workspace update on User B, and even though it did not find any new changes, all of a sudden user B can now lock and checkout the file.

I'm still not sure what happened here and it cost us hours to debug. What could have caused this?

TournesolBancal · Aug 30, 2023

>You can also check-out the items via the Plastic GUI. But you need to remember to do it before editing the files on disk with your editor.

The process is very cumbersome:
* After realising you need to lock say, 10 files that already have modifications
* Revert the changes on the 10 file through "pending changes"
* For each of the 10 files do:
- Locate the file in the "Wokspace explorer"
- Lock it
- Redo the changes on the file
* Commit

I cannot ask that of my team, that would be really hard on people especially those who work on many files at once, and/or if every single one the10 files are in different folders.

carlosalba1985 · Aug 30, 2023

Hi @TournesolBancal, if you want to use file locks, you need to switch to a Checkout/lock --> Edit --> Checkin workflow.
This is not something related to the new Smart Locks feature but also related to the legacy lock system.

If you use the Unity plugin (or some other plugin), yu can configure it to force users to lock the items before editing them.
But if you are not using any supported plugin but some other editor/IDE that Plastic is not aware if it, you will need to checkout the items before modifying them.

TournesolBancal · Aug 30, 2023

Ok, thanks for the quick replies.
I will re-evaluate the unity plug-in and keep you updated with the results.
I must say this does not feel like a great solution though.

palamangelus · Sep 15, 2023

We just tried using the new smartlocks and now are completely stuck. We have 3 branches, one that has the full code set that we've only been working in (Development - it is also the "destination" as mentioned in "retained"). We added a rule just for *.unity files (scenes), and then checked out + locked them. Not a single person can check them back in or unlock them. I'm the admin and can't do it from the dashboard or locally. The original dev can't do it either. It just says only an admin can do this and in the dashboard says to "check the logs" (except, you know, it's a login to the UGS service and I don't have access to Unity's logs). It says the files are "retained" and there's literally nothing we can do with them. How can this be resolved asap? We have multiple deadlines coming up and unfortunately tried to add this to our workflow and it failed immediately and spectacularly.

carlosalba1985 · Sep 15, 2023

HI @palamangelus, please open a ticket with us so we can assist faster: devops-vcs-support@unity3d.com

Search Unity

Unity ID

Useful Searches

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

Unity Technologies

Attached Files:

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies