Release Notes

Public

Release 5.4.16.793

Nov 18 2016
New

Move changesets to a different branch!

The top UserVoice request has been released: Move changesets to different branch

It helps in a very common scenario: you checkin to the wrong branch by mistake. Now you can move these changesets to the branch were they belong.

The feature is supported both from the command line and the 3 GUIs (Windows, Linux, OS X).

Command Line Client: the cm changeset command has been refactored to support the new feature and provide a more consistent way to perform advanced changeset actions. It now includes two subcommands: cm changeset move and cm changeset remove.

* cm changeset remove <changeset-spec> deletes a changeset from the repository. Please have in mind that the target changeset must fulfill some requirements. See command help (cm changeset remove --help) for further detail.

* cm changeset move <changeset-spec> <branch-spec> moves a changeset and all its descendants in the same branch to an empty branch. If the destination branch doesn't exist it will be created in the process. See command help (cm changeset move --help) for further detail.

Windows, Linux and OS X GUI's: the 'Branch Explorer' and 'Changesets' views now include a context menu option to move the selected changeset and its descendants in the same branch to a different branch.

New

Branch Explorer filters now available on OS X.

A new submenu called 'Branch explorer' has been added to the 'Branch Explorer' view context menu. This new submenu contains the previous 'Go to branch base' action and three new actions: 'Filter selected branches', 'Filter selected and related branches' and 'Filter pending merges for selected branches'.

Each of them will refresh the 'Branch Explorer', showing only those branches affected by the selected filter. A new 'Remove filter' button will appear. Clicking on it will clear the filter and refresh the 'Branch Explorer' view using the previous conditional filter settings (if any).

New

Windows, Linux (GTK) and Mac OS Mergetool: User voice: Simple diffs in a merge tool

Now it is possible to diff the three revisions involved in a merge in a separate window launched directly from the mergetool. To do that:

* Click on the new button on the top-right section of the mergetool

* Select the desired diff: source revision with base, destination revision with base, and source revision with destination.

New

Cloud: Improved the exclusive checkout (a.k.a. distributed lock) performance (30% faster than before).

New

Gluon: The 'Update report' dialog has been refurbished. The error message for each update conflict has been moved to a dynamic text area on the right hand side of the dialog and errors can be update forced from now on.

New

Server (Linux): The server will now run as the 'plasticscm' user, instead of 'root'.

Bug

Gluon: After deleting or renaming a file in the 'workspace explorer' view, the item position (the scroll position) was unexpectedly changed. Fixed.

Bug

Mac OS Mergetool: Fixed some aesthetical issues:

* The margin colors were not correctly updated in the result text view when conflicts were edited.

* Sometimes the scroll position was wrong on application startup.

* Fixed clipped text in 'Mark as resolved' button.

Bug

Linux (GTK) GUI and Mac OS GUI: The message 'Can't edit the xlink root' appeared when trying to edit partial read-only xlinks. Fixed.

Bug

Mac OS GUI: Wrong height and bottom margins in the filter field on 'Available Plastic SCM Branches', 'Server explorer' and 'Changeset selection' dialogs. Fixed.

Bug

Linux (GTK) GUI: under some circumstances, the GUI could throw an unexpected error. For example, while diffing an item that has no previous revision. Fixed.

Internal and public releases

The Plastic SCM development team works in short iterations delivering frequent releases.Our goal is to have at least one new release every week, with new functionalities, bug fixes and performance tweaks.

Every 'weekly' release is not published to our customers, but we like to detail each of them in the release notes so users can easily follow what we achieved on every short iteration.

The releases marked with the word "public" are the ones we do publish on the website. The ones marked as "internal" are the releases we create in-house to keep the project moving week after week.

Version numbering

Starting in Plastic SCM 4.0 the version numbering schema has been modified:

  • major.minor.compatibility.buildnumber

  • Sample: 8.0.16.3333 means:
    • 8 -> major release number
    • 0 -> minor release number
    • 16 -> compatibility -> all clients and servers with "16" in the compat number are compatible, even if the build number changes
    • 3333 -> internal build number