Release Notes

Security: Now it is possible to restrict "read" access to certain paths so that some parts of the repository are not visible to certain users. It is useful in centralized setups where sensitive areas of the project must be protected in such a way they can't even be seen by some project members.

The way to secure the paths is very easy: just deny or remove the "read" permission for certain paths (what we know as "secured paths" internally).

This way the users without effective "read" permissions won't be able to download (doing update) these secured paths. These paths won't be visible in diffs or merges either.

What happens during merge? If a user needs to merge a branch and there are changes in a path he can't "read", the merge will fail notifying that the merge can't proceed due to security restrictions.

Note about effective permissions: remember that permissions on paths inherit from repository permissions and can be applied to all branches or a subset of branches.

Most relevant behavior changes:

* The update operation will not download files and directories where the user doesn't have "read" permission.

* The diff operation will filter out the differences. If the source of the diff can't be seen, the diff won't be visible. (Remember there is always a "src" and "dst" on diffs).

* The merge is rejected if the user doesn't have "read" permission for any change in the source contributor.

Current known "issues": There are some issues that will be fixed in the upcoming releases, but they are present in the current version:

* If the user doesn't have "read" permission for the root item, any try to update or view the repository content will end up in a "null exception". This is an ugly one that will be fixed soon, but it doesn't make sense to remove root "read" permission (it is better to deny access to the repo).

* The update-merge (you know, when you are on a branch, you have checkouts, you update to latest, and your checkout is simply moved to latest using a merge under the hood) will fail with a weird message if there is a local change (co/add/rm/mv) under a location where the user doesn't have "read" permission anymore (you had permissions, you downloaded the content, and then someone remove access to this path). The message will be something as follows: "item 12386 could not be found in the tree. The new tree cannot be built". While the error is ugly, we consider it will be an uncommon case, so we decided to release and fix the issue later.

* When you configure path permissions for an Xlink directory entry, the permissions are applied to the root path of the Xlinked repository instead of the specified path in the parent repository, which will lead to the same issues defined in the first 'known issues' point. This is something we need to get fixed soon. Example: you have /src/subrepo => pointing to /@cset:1320@opengl-lib. Well, you try to set permissions to /src/subrepo but they are set to /@opengl-lib instead, which is not what you really want to achieve. We'll fix it ASAP.

Remarks:

* GitSync & GitServer ignore any path based security.

* You must update both clients and servers to take advantage of this new security functionality.

* Diff will show secured paths if the user has permissions to "read" the change in the destination changeset. We still have to decide whether

* If the user has permissions to "read" an item/path, he will have permissions to see all its revisions from the history views.

* In distributed scenarios, enable the following setting inside server.conf: <SecuredPaths>true</SecuredPaths>. This will reject operations when the path permissions of a revision cannot be checked because its changeset was not replicated yet.

* It is recommended to configure the path based security to protect "read access" prior to start using the repository. Otherwise, the admins must take into account that the users will have to run update operations (without local changes) to propagate the new "read" permission rules to their workspaces and avoid further issues with the fast-update, merge & update-merge operations.

XLinks: Partial readonly Xlinks are now available!!

We finally added support for "partial Xlinks" (readonly) as requested on top User Voice request.

It means that from now on you can Xlink not only to the root of another repo, but also to any path inside, mounting a "subtree" on the parent repo. The reason why "writable partial Xlinks" are not supported yet is because they would overly complicate the merge (what if you have conflicts on parts you are not mounting?).

Remarks:

* At this point you need to use the command line to create Partial Xlinks. GUI support will come soon.

Restrictions:

* This restriction only applies to the Plastic Gluon client. It is not recommended to use the 'partial readonly Xlink' feature in Gluon workspaces where multiple Xlinks pointing to the same repository are loaded. The reason is that Gluon workspaces use a single cache per repository, so if there are multiple Xlinks pointing to the same path with different root paths, it can potentially lead to weird issues.

Gluon: Improved 'switch workspace' usability. From now on, when a user switches to a new workspace, other Gluon windows + 'switch workspace' dialog will be closed.

(Nevertheless, this new behavior can be overrided by choosing to keep them open with the new option: 'open workspace in a new window').

We did this due to we had feedback from several users suggesting that having too many open windows wasn't comfortable.

Windows GUI: The 'merge' view is now automatically closed after a 'merge-to' operation. Also, the dialog to enter comments has been aesthetically improved.