Release Notes

Public

11.0.16.8223: Oct 19 2023

New

All platforms - Server can checkin directories with lots of direct entries.

The server used a buffer of 5M to calculate the hash of the directory entries. This was not enough for folders with more than 150.000 entries, so the checkin failed. Now, this limit is much bigger.

New

All platforms: Greatly improved the performance while finding locally removed files.

Removed an unneeded check for moved files when the workspace only contains locally removed items, no private or ignored files.

Example: In a working copy with 14K locally removed files, the search took 20 seconds to complete; now it takes 500ms.

Also, improved the search operation for moved items. Before, we downloaded all the locally deleted content to attempt a move-match with private file candidates. Now, we only download those whose size will be a valid match for the existing candidates.

New

All clients: Client-side check-in triggers support added to partial workspaces

If you configure a client-side check-in trigger, it will now run for partial workspaces:

> cm trigger mk before-clientcheckin MyBeforeTrigger before_trigger.sh
> cm trigger mk after-clientcheckin  MyAfterTrigger  after_trigger.sh
> cm partial update
> cm co file.txt ; cm partial ci

# The triggers (MyBeforeTrigger and MyAfterTrigger) will run before and after the changeset creation!

New

All platforms - Desktop GUI: Improved checkin operation startup time

In the check-in operation, we have made an enhancement to optimize startup time. Previously, the operation included a phase where paths were resolved to expand them and make them canonical, as well as resolving symlinks. However, it was observed that the GUI doesn't require this step. Therefore, we have decided to skip it, resulting in a faster check-in operation.

New

All platforms: Faster workspace status calculation with added items.

Improved heavily the time to calculate the workspace status when a big number of items were added under the same folder. This is only noticeable if the number of files is greater than 1.000.

In our tests, the workspace status calculation of 8.000 added files goes from 9s to 0.15s.

The workspace status calculation is performed when running the 'cm status' command or refreshing the pending changes from Desktop GUI & Gluon.

Bug

All platforms - Desktop GUI/CLI: Delay in visual feedback during large check-ins

When performing a large check-in, there was a noticeable delay between initiating the check-in and receiving visual feedback through the UI or CLI. This delay became especially prominent during very large check-ins. We were missing notifying visual feedback during the "Assembling check-in data" phase. Now it's fixed.

Bug

All Platforms - Desktop GUI: Improved performance expanding nodes in the Workspace Explorer

Previously, expanding a node in the Workspace Explorer that contained 18k items took a variable amount of time, ranging from 6 to 15 seconds. This performance issue was impacting the user experience.

Expanding 18k nodes is now significantly faster (about 750ms), enhancing overall usability.

Bug

All platforms - Desktop GUI: Show notification dialog when pending changes in diff window

The Unsaved changes dialog will be shown in Diff window after a new branch/changeset selection is done and exist any pending changes to save/discard in the diff view.

Bug

All platforms - Desktop GUI: Super-slow check-in of many deleted files.

The pre-processing time of the checkin operation (when launched from Desktop GUI) was super-slow when the changes to checkin included lots of files deleted under a folder that still loaded lots of files.

Let's see a scenario where it happened: there is a folder '/Assets' with 20.000 files. If we deleted 10.000 of them and tried to check them in from the Desktop GUI, the check-in operation took more than one hour to start. Now, it only takes around 50s. This means x100 times faster.

As a workaround for this slowness, you could disable symlink support on Windows in the client.conf file: <EnableSymlinkSupportOnWindows>no</EnableSymlinkSupportOnWindows>.

This problem also happened from the command line if the 10.000 deleted paths were passed as individual arguments to the 'cm checkin' command (not very common, but possible).