Release Notes
Public
8.0.16.3515: Aug 29 2019
New
All platforms - Command line client, Plastic: until now, if a user had the applyattr permission denied at the repository level, said user could not apply an attribute on an object (branch, changeset or label) inside the repository even if the applyattr permission was overridden-granted for said object (changesets here have the same permissions of the branch they belong to).
Now, the applyattr permission is only checked at the object level, and not at the repository level (which prevented Plastic from checking overridden permissions for this operation!). Remember that permissions are inherited, so if you deny said permission at the repository level, it will be denied for all objects inside it unless explicitly overridden.
New
macOS - Plastic, Gluon, Mergetool: We improved the dark theme colors used in syntax highlighting. We noticed that some of them (comments, keywords) made text difficult to read if it was inside a changed block, due to the highlighted background. Here's a before/after comparison:
New
All platforms - Command line client: the automation command "getworkspacefrompath" / "gwp" now admits keywords in its format string argument. For example:
$ cm gwp README.md --format="{wkname}{tab}{wkpath}"
CHIPEIT c:\Users\sergi\wkspaces\chipeit
For further information about the available keywords refer to the integrated help:
$ cm help gwp
New
All platforms - Server: We have new types of merge rules!
1) restrict_merges_to_branch 2) only_allow_merges_from_parent 3) only_allow_merges_from_children
Let me walk you through them:
1) works as follows: during a merge, if the destination branch matches the "to" restriction of a merge rule, the merge can only continue if the source branch of the merge matches any of the "from" restrictions in the same rule.
For example:
// [{
// "enabled": true,
// "repositories": "codice",
// "rule": "restrict_merges_to_branch",
// "to":
// {
// "branchNames": ["/fix3.0"],
// },
// "from":
// {
// "branchNames": ["fix3-*"],
// }
// }]
For the repository "codice", merges to branch "/fix3.0" are only allowed from branches named "fix3-*" (remember that you can use wildcards).
2) and 3) are pretty similar. only_allow_merges_from_parent only allows a merge for a destination defined in the "to" restriction of a rule if the source is its parent. only_allow_merges_from_children will check the opposite - that the source is a direct child of the destination.
For example:
// [{
// "enabled": true,
// "repositories": "game*",
// "rule": "only_allow_merges_from_parent",
// "to":
// {
// "branchNames": ["task*"],
// }
// },
// {
// "enabled": true,
// "repositories": "game*",
// "rule": "only_allow_merges_from_children",
// "to":
// {
// "branch_names": ["iteration*"],
// }
// }]
In the repositories with name "game*", branches with name "task*" can only receive merges from their parent branch. This way you can prevent merges across different task branches.
However, branches with name "iteration*" can only receive merges from their child branches. So, for example, "/main/iteration-32/task23" can be merged into "/main/iteration-32", but it cannot be merged into "/main/iteration-15", as it is not a child of that branch.
Right now you can edit these new kind of merge rules manually - the WebAdmin doesn't support them yet. The file is stored alongside server binaries, and its name is "mergerules.conf".
This new merge rules are not available for Cloud yet, but will be soon!
Bug
Windows - Plastic: The GUI was not able to restart the file system watcher if it stopped due to an internal watcher error. In that eventuality, the pending changes calculation would take a noticeable amount of time more because it would need to check the disk contents instead of using the cached contents. This affects the auto-refresh feature as well, because it would trigger a refresh of the pending changes view whenever the GUI is focused, even when the workspace doesn’t contain any changes. Now, the file system watcher errors are properly handled and the watcher is correctly restarted afterwards. This issue appeared first in version 8.0.16.3281.
Bug
Windows - Plastic: Semantic multifile - We addressed several usability issues in the case that we detect that code has moved between files and the displayed file is either added or deleted:
* The semantic outline panel didn't keep the selection.
* The option 'Go to moved code', that you can find under the 'M' icon, didn't go to the right location for multi-file moves.
* Sometimes the moved icon for the multi-file moves was not shown.
Bug
All platforms - Server: There was an issue when moving an older repository to be a submodule of a newer one. Imagine the following scenario:
$ cm repo list --format="{repid}{tab}{repname}
1 default
2 myProject
2_1 myProject/webpages
2_2 myProject/doc
3 otherWork
The repository myProject/webpages is older than myProject/doc (as determined by the moduleId, which is 1 for webpages and 2 for doc). Now, we are going to move doc to be a submodule of webpages:
$ cm repo rename myProject/webpages myProject/doc/webpages $ cm repo list 1 default 2 myProject 2_1 myProject/doc/webpages 2_2 myProject/doc 3 otherWork
Everything looks sort of right (doc should be listed before webpages, but all of the repos are there). But see what happened when you restarted the server:
$ cm repo list 1 default 2 myProject
What happened to all of the repositories that should be after myProject? Well, we had an issue in the way we load repositories from the backend, which is now fixed:
$ cm repo list 1 default 2 myProject 2_2 myProject/doc 2_1 myProject/doc/webpages 3 otherWork
Bug
macOS - Plastic: A few releases ago, we changed the order of the sidebar items. However, if you opened views using the View menu, or using the shortcuts, the views showed up corresponded to the old ordering. Fixed!
Bug
All platforms - Plastic: The "create replication package" command failed with the error "Can't create a replication package from a repository with data replicated using the --nodata flag. Please hydrate the source repository first." if there was an empty file revision (i.e. its size is 0 bytes) without a related empty data object. Now it's working, as empty file revisions don't really need data objects.
Bug
Jenkins: We fixed an issue in the polling results parser that prevented the SCM Polling from returning the appropriate results.
Bug
Linux - Plastic: symlinks pointing to directories or to themselves had a wrong status and icon in the workspace explorer. Fixed.
Bug
Windows, Linux - DevOps: Users with spaces in their username were not able to configure a profile for DevOps using the GUIs. They'd receive an error message that said something in the lines of:
Cannot retrieve the profile from localhost:7178. Details: The user 'Sergio+Luis' does not exist.
That's now fixed.
Bug
All platforms - Server: The fast update was not able to switch to a different branch when the user cannot perform a merge from that branch because they don't have the mergefrom permission or because there is a merge rule that restricts it. Now it's working.
Bug
Windows - Plastic: The new Code Review system allowed you to comment xlink changes but, later, it would fail when trying to visualize them.
For now, we have disabled comments on files under xlinks (same as in the old system). We will work to add this functionality and much more soon!
Remember, right now, you need to start with plastic --codereview to enjoy the new feature.
Bug
All platforms - Jenkins Plugin: We fixed some serialization issues that prevented the REST API output from working.
Bug
Jenkins: Builds failed if your selector targeted a cloud repository. Fixed.