Release Notes

All Platforms - Unity DevOps Version Control: Color Picker: Removed alpha channel slider

In this release, alpha channel slider was removed for Color Picker controls

Server: Allow to see the branch changes pending to integrate when it doesn't fulfill the merge rules.

The diff --integration (e.g., 'cm diff br:/main/task --integration') allow to see the pending changes to integrate for the given branch. But, when the branch doesn't fulfill the merge rules defined on the server (e.g., you need to review the branches prior to merge them into /main), you get the error "Cannot perform the merge because of the Merge Rules. Review the branch '/main/task' to merge it to '/main'." when you try to see the changes pending to integrate on a branch without a code review.

Now the diff --integration works, no matter if the server has any merge rule enabled or if the branch fulfill those rules.

All platforms - Unity DevOps Version Control, Gluon: Improve visibility of current changeset or branch

We added some visual cues to the Branches and Changesets view so that you can more easily see which is your current branch or changeset.

We also applied the same style change to the item history view in Gluon.

All platforms - Unity DevOps Version Control, Gluon: Highlight path changes for moved items

We added highlighting to the paths for moved items so that you can more easily see which parts of the path were changed.

This applies to the Pending Changes, Merge, Diff and Incoming Changes views in Unity DevOps Version Control and Gluon.

All platforms - Unity DevOps Version Control: Notification added to invite users to try the new Code Review experience.

We have added a notification bar that invites users to try out our enhanced Code Review experience from the Unity Dashboard:

All platforms - Command line client: Revamped the client configuration from the command line.

We improved the way of configuring the client interactively from the command line client (cm configure).

The first change is that now you are not asked for the repository server specification in different steps. Take this as an example - this is what you had to do before to configure a SSL server:

Configure the Unity VCS server address/port:
Unity VCS server address [localhost]: version-control.unity-hq.domain
Unity VCS server port [8087]: 8087
Use encryption (SSL)? [y/N]: y
Unity VCS SSL server port [8088]: 9095

You had to specify a plain TCP port despite the server might not be even listening on one. Then you were asked whether or not you wanted to use SSL, and only then you could specify the port you really wanted to use. This process was both slow and error prone.

This is what you need to do now to achieve the same:

Enter server address: ssl://version-control.unity-hq.domain:9095

Additionally, if your server requires connection credentials (User and password, or email and password), the command line client checks that the credentials are correct before saving any configuration - letting you retry if you fail to type in your user or password.

And last but not least the cm configure command now supports configuring your client directly against a Cloud organization (using email and password, Unity ID, or any other Single Sign-On mechanism you might have configured). Before these changes, only email and password were allowed for configuring your client directly against the Unity DevOps Version Control Cloud servers.

Windows - Wwise plugin: New location for the Wwise plugin

From this version on, the Wwise plugin compatible with version 2021 and below can be found in the PlasticSCM installation folder, under the path "client/plugins/wwise".

Windows - Wwise plugin: New plugin for Wwise 2022

We are pleased to announce the first release of the Unity DevOps Version Control Plugin for Wwise compatible with version 2022.

This new plugin can be found in the PlasticSCM installation folder, under the path "client/plugins/wwise2022".

Command-line client: Update command improved for automation

Now moved files will be also regarded when option --xml is specified. On top of that, a new field "ChangeType" has been added in order to make the output more understandable and easier to parse. For instance, if we are 1 changeset behind the head and within the last changeset we renamed a file "math.c" to "stats.c" and moved "dice6Tex01.png" into "textures" folder, then we changed the content of dice6Tex01.png. When updating the workspace to the head, we could see something similar to the following:

$ cm update . --xml 2>update_errors.txt
<?xml version="1.0" encoding="Codepage - 437"?>
<UpdatedItems>
  <List>
    <UpdatedItem>
      <Path>c:\wkspaces\BestGameEver\stats.c</Path>
      <User>john.scott</User>
      <Changeset>7</Changeset>
      <Date>2023-01-12T15:30:39+01:00</Date>
      <OldPath>c:\wkspaces\BestGameEver\math.c</OldPath>
      <ChangeType>Moved</ChangeType>
    </UpdatedItem>
    <UpdatedItem>
      <Path>c:\wkspaces\BestGameEver\textures\dice6Tex01.png</Path>
      <User>john.scott</User>
      <Changeset>7</Changeset>
      <Date>2023-01-12T15:30:39+01:00</Date>
      <OldPath>c:\wkspaces\BestGameEver\dice6Tex01.png</OldPath>
      <ChangeType>Moved</ChangeType>
    </UpdatedItem>
    <UpdatedItem>
      <Path>c:\wkspaces\BestGameEver\textures\dice6Tex01.png</Path>
      <User>john.scott</User>
      <Changeset>7</Changeset>
      <Date>2023-01-12T15:32:12+01:00</Date>
      <ChangeType>Changed</ChangeType>
    </UpdatedItem>
  </List>
</UpdatedItems>
CommandResult 0

See --usage for details:

> cm update --usage

Special considerations:

- Have in mind that every operation performed on an item will appear as different UpdatedItem nodes. As seen in the previous example, the file "dice6Tex01.png" is both relocated and changed in the same changeset, so it appears twice (one per operation) in the XML output.

- If a controlled file has been deleted and added again with the same name (either with the same or different content), it will be reported both as a delete and an add operations. This is, the item will appear twice in the report, the same as it works in other commands such as 'cm partial update'. Before this code change, when the content of the file was identical, the file was not reported at all. When the content of the file was different, it was only reported as a change.

- If a file has the exact content of the revision we are updating it to (i.e. for revision X and revision Y the content of the file is "hello", and we are updating the file from revision X to revision Y), it is reported as a changed item. Before this code change the file was not reported as changed because Unity DevOps Version Control didn't need to download data from the repository server (the hashes from both revisions match).