Release Notes

GTK & Mac GUI's: Shelve view has been implemented and it is fully functional. The context menu options are 'View shelve', 'Apply shelve in the workspace' and 'Delete'.

The shelve view can be opened from the "Show Shelves View" button in the pending changes view and it will be displayed on the right side of the view.

Triggers: Client side triggers can now be customized using relative paths or user-defined paths. The script execution paths can be built in the following ways:

* Using two new predefined variables: PLASTIC_BIN_PATH (Plastic SCM client installation directory) and WKSPACE_PATH (Current workspace location). Example:

 cm maketrigger before-clientcheckin "Relative trigger path" "@PLASTIC_BIN_PATH/triggers/checkdirectories.pl" 

* Using customized trigger variables, defined in the 'client.conf' file. The syntax is the following:

  <TriggerVariables>
    <TriggerVariable name="TRIGGERS_PATH" value="c:\triggers" />
  </TriggerVariables>

The path directory separator char will be replaced depending on the target platform (i.e "@PLASTIC_BIN_PATH/triggers/checkdirectories.pl" will match "@PLASTIC_BIN_PATH\triggers\checkdirectories.pl in a Windows platform).

The use of these approaches will allow the definition of platform-independent client side triggers.

GTK & Mac GUI's: SSL certificates from Plastic SCM servers can now be accepted.

Windows GUI: Changed blogpost notification icon. Now, the number of unread blogposts is shown near to the "BLOG NEWS" menu item.

Bamboo plugin: Automatic merging feature is now supported (Both 'branch updater' mode and 'gatekeeper' mode).

GameUI: New option added in history context menu to show changeset differences.

Game UI: A new context menu option has been added in the history panel: 'Diff selected revisions' to let the user diffing two specific revisions (and not only diffing with previous revision).

The new context menu option will be available when two revisions are selected.

Game UI: Application startup performance has been significantly improved. Before this improvement, the application startup time was depending on the connection to the server, but now the application starts inmediatly.

Game UI: Usability improvements:

* Now it is possible to checkout files from the 'search item'.

* Ctrl+O (checkout) over an item moved away the focus from the selected item. Fixed.

* Focus is kept over an item after creating or renaming it.

* The scroll position is now remembered in the workspace explorer tree after restarting the application.

* Workspace name in window title was lost when switching between configuration mode and explorer mode. Fixed.

Greatly improved branch (and changeset) diff window to better explain merges.

This feature is an evolution of the original "item-merge-tracking" effort and greatly improves the way in which branches (and csets) receiving merges are diffed.

This feature is one of the most relevant improvements in branch/cset diffing the Plastic SCM team have developed.

When diffing a branch (or cset) that receives one or more merges, it is often hard to figure out what was really modified on the branch and what comes from the merge. It complicates reviewing code, specially when big rebases (merge from parent branch) happens.

Suppose the following scenario:

* You start branch "task1010" from label "build-117" on main.

* You modify a number of files and work on the branch for a couple of days.

* In the meantime "build-118" was created, including changes in more than 250 files.

* Prior to integrate your branch to main you're asked to rebase it to "build-118", so you merge down from label "build-118".

* Now your branch doesn't only contain the changes you made, it also contains all the changes (more than 250 files) coming from the merge.

If another developer (or yourself) diffs the branch "task1010" now, he will have hard time figuring out what was modified in the branch and what was merged. The branch is not clean anymore.

This is precisely what this new feature solves: it is able to split the diffs in groups, so it is easy to understand:

* which files just come from the merge and were untouched on the branch,

* which ones were modified on the branch,

* and more importantly, which ones were modified both in the branch and also in the merged branch, they were merges, and they're grouped under a category called "changed/changed" (or CC for short).

This third group of files changed/changed is the one greatly improved by this feature: when a file was both modified on your branch and also changed in the branch you're merging, it is grouped under CC, but then it was not easy to know which lines were actually modified on the branch, which ones were in conflict during the merge, and which ones were just modified on the source branch of the merge.

Now the branch (and cset) diff is able to render differently the lines that were modified on the branch, during the merge (result of a manual conflict resolution) and from the source branch being merged (automatic conflict resolution), making much simpler to review code of branches (and csets) with one or many merges.