Unity Version Control 11.0.16.8101

All platforms: Introducing Smart Locks

All platforms: There are many kinds of files that present a challenge for merging content changes:

All platforms: It is quite easy to see how important it is to apply changes to these assets sequentially and always iterate over their last revision. The creation of parallel histories usually means that some changes are discarded and redone down the line, since conflicts in these files cannot be merged.

All platforms: So far, you could set up these lock rules to guarantee that nobody else made changes to the same file at the same time. When you were done, changes were checked in — or unchecked out — and the lock was removed. This "legacy" lock system was devised mainly for artists that work on a single branch, forcing the user to work on the last revision of the branch.

All platforms: However, protection did not extend to multi-branch scenarios, allowing the creation of parallel changes in different branches:

All platforms: Yes, both are using the last revision on their branch, but they don't take into account new revisions in other branches.

All platforms: Now introducing Smart Locks.

All platforms: Smart Locks are the mechanism that Unity DevOps Version Control uses to track which branch retains an asset for edition, and it works as a baton pass or as a "torch". Even if the file is not exclusively checked out right now, task branches retain the lock and prevent developers from checking out an outdated revision in a different branch.

All platforms: Moreover, locks are not retained by the users who created them. As long as they keep working with the last revision, other developers can still exclusively check out the file you just checked in! This is true even for multi-branch scenarios.

All platforms: In other words, Smart Locks ensure a single line of development for assets among different branches while enabling collaboration between developers. Long gone are the days when you needed to keep a physical token on your desk to let your colleagues know that you were holding an asset: Unity DevOps Version Control keeps you covered.

All platforms: == CREATING SMART LOCKS ==

All platforms: Smart Locks are here to replace legacy locks, and the new version of the server already uses them from the get go (see details in the 'COMPATIBILITY' section). If you were already using locks, you probably just need to upgrade.

All platforms: First of all, you need to set up the lock rules (if you don't already have them!):

All platforms: Note that there are two new optional fields available in the lock rules:

All platforms: After setting up the rules, you can create a task branch and try to check out a file. The "lock list" subcommand will help you to inspect which locks are in place and their current status:

All platforms: Within the Desktop GUI, the Workspace Explorer now tells explicitly which files are locked by other users, and they are represented with special icons for clarity.

All platforms: Also, a new panel was added to the Desktop GUI and Gluon to display the Smart Locks that currently exist in the workspace repository. Since there, you can release or remove the locks too:

All platforms: Moreover, this panel is available in both, the Workspace Explorer and the Home View, so you don't even need a workspace to manage the locks of a repository.

All platforms: Likewise, the same functionality is provided by the WebUI:

All platforms: See in detail how to configure exclusive check-out using an on-prem server in our administrator guide:

All platforms: https://docs.plasticscm.com/administration/plastic-scm-version-control-administrator-guide#Chapter7:Configuringexclusivecheckout(Lock)

All platforms: == LIMITATIONS ==

All platforms: Even if you bump into such scenarios, none of them are unrecoverable. See the following section.

All platforms: == REMOVING AND RECREATING LOCKS ==

All platforms: You might land in a situation where a lock must be forcefully unlocked — maybe somebody locked an asset and forgot to release it, or maybe a lock was invalidated for some other reason.

All platforms: You can use the Desktop GUI, Gluon, or the WebUI to release or remove the lock. Alternatively, you can also use the "lock unlock" subcommand:

All platforms: By the way, if you really need to remove a lock entirely, you might want to recreate it somewhere else. You can use the "lock create" subcommand for that. Lock rules already determine which is the destination branch, but you still need to explicitly specify the holder branch, like so:

All platforms: == COMPATIBILITY ==

All platforms: You can find more information in the official documentation:

All platforms: /unity-version-control/smart-locks

Command-line client: cm update now has its own update report

Command-line client: The update command usually does not show an update report. Instead, it shows a progress bar (if used interactively) or all the relevant events that happen on items as they are updated (a behavior intended for tool automation).

Command-line client: However, the progress bar does not clearly communicate errors. Now using cm update interactively features an update report at the end, which helps to better understand what happened:

Unity scenes

3D models

Images and texture maps

Sound files

Excel spreadsheets

Etc...

Alice made some changes to `player_icon.jpg` at `/main/level_12` . The scene is waiting to be integrated, and the file is not locked anymore.

Bob is working on its own branch ( `/main/level_11` ) and makes a quick change to the same file too.

The "destination branch" — br:/main by default — is the source of truth when creating a new lock: the revision loaded here is considered the last revision. Locks created in other branches are not released until they get integrated back into the destination branch.

Some "excluded branches" where the lock rules are ignored. Note that you can use wildcards at the beginning and at the end. Excluded branches are matched by name, so bear it in mind when renaming branches!

Smart Locks do not travel across replicas.

Replicas might add newer revisions to the repository, leaving the lock outdated.

Some scenarios involving changeset deletion might leave the lock outdated for obvious reasons.

Merge-to does not support locks — neither legacy nor smart ones —... yet! Stay tuned.

Before, lock rules allowed a lockserver field (although this was barely used and could introduce some issues). It won't be supported anymore.

Old versions of the client can perform exclusive check outs over files, but they won't be able to release Smart Locks, only legacy ones. If you try, you will be prompted to upgrade in order to continue.

After upgrading, legacy locks already in place will stay as they are. But as soon as files get checked in or unchecked out, the legacy lock will be gone. The next time you check out such files, they will start using the new system.

There could already be parallel versions of some files (coming from legacy locks, if they were used this way). In this case, some manual operations could be needed to continue working with these files during this transition to Smart Locks. 'cm lock unlock' and 'cm lock create' are here to help.

Legacy locks will still be supported, at least for a while. Indeed, you can disable the new behavior in the server by adding the following key to the server.conf:

All platforms - Desktop GUI, Gluon: Links not properly formatted in release notes

All platforms - Desktop GUI, Gluon: The release notes were not properly formatted when any link tag was included, we have included a fix in order to accept the different link formats we support.