All platforms - Plastic, Gluon: Pending Changes will now fly when you have files with timestamp but not content changes.
Many Unreal and Unity users face this issue: their IDEs modify timestamps of files "randomly" but not content. Plastic finds them as changed.
Then they check this preference in Plastic: "Check the content to determine files as changed, not only timestamp" and the fake changes disappear but... at a cost. Pending Changes starts getting slower and slower because it has to calculate the hash of each "fake change".
Now this is fixed because Pending Changes (on GUI, CLI, plugins, everywhere) will update the timestamp of its metadata to avoid having to rehash next time.
From now on, fresh installs of Plastic SCM Team or Enterprise editions will be packed with a 5 days free trial license for 5 users (before this version, the free trial license only allowed 1 user).
Windows, Plastic: More improvements in the prototype of the upcoming Code Review system.
We removed the initial dialog to create the code review. Now it will be created directly and users will be able to edit anything (title for now) in the code review window.
As we already announced, it is not yet functional but you can give it a try if you start your Plastic this way:
And then go to create, edit and delete a Code Review.
More improvements really soon :-)
All platforms: We improved the error message you get when you try to undo some locally moved files but their original directory cannot be found. This usually happens because you aren't allowing plastic to detect locally deleted directories, so the client can't restore them. The error message now suggests you to enable deleted item detection.
For instance, let's say you transform this workspace tree:
/a `- /b (1) |- fileA.txt (2) `- /c `- fileC.txt (3)
/a `- /x (1) (LM from /a/b/c) |- fileB.txt (2) (LM from /a/x/fileA.txt) |- fileA.txt (3) (LM from /a/x/c/fileC.txt) `- /c (private)
/a/b is detected as locally deleted in this scenario.
At that point, if you run 'cm undo --moved -r' the client can't restore the moved files because directory /a/b can't be found (it's detected as locally deleted). You'd need to include the --deleted argument.
In the GUI you'd normally get a dependencies warning before the undo; however, if you don't check the "Show deleted files and directories" option in the "What to show" tab of the Pending Changes view, the operation can't properly calculate the dependencies and it will fail.
All platforms - Plastic, Gluon: When diffing from the history view, when the loaded revision was the right revision, the diff was not editable. Now we detect that case, and make it editable.
All platforms - Command line client: We improved the error message generated when 'cm undo' can't undo a change because there is a dependency. It now advises you to include the depended upon item in the set of paths passed to the command.
All platforms - Plastic, Command line client: merging a change to a binary file (when only the source has changed) used to fail if file in the destination branch was read-only. You used to get an error about "Access to the path" being denied. We fixed this, and the merge now completes successfully.
macOS, Linux - Plastic: The checkin operation did nothing (and displayed no feedback) if you performed a merge that created no changed files. That can happen e.g. if the only merge conflict is a readonly-xlink modified in both contributors (a directory conflict) and you select "Keep destination" to solve it.
Linux, macOS - Plastic: The external tools failed to launch for items that were not in the workspace (for example, opening an external tool on a file when browsing the repository in other cset different than the current one). That's now fixed!
All platforms - Gluon: The update was not able to download new items in a very specific scenario with delete, add and move operation related among them. The error shown in the report was the following "The new item cannot be loaded in the workspace. Probably, the path is already used. Please unload the item (from the configuration view) and retry the operation." The specific scenario was the following:
Having this repository structure:
/src /src/code /src/code/foo.c /bar.c
One user loads in the workspace (wk1) the following content (the whole repo except for /bar.c).
/src /src/code /src/code/foo.c
Another user that loads the whole repo, make the following changes and checkin them:
add /src/code/qux.c add /source move /src/code /source/code rm /src
When the user (wk1) run an update, he got the "The new item cannot be loaded..." error. Now, the /src/code/qux.c is correctly download.