Release Notes

Internal

5.4.12.575: Jul 01 2014

New

Improved the symbolic information that is shown in the mergetool, when resolving a three way merge:

* Added a parameter in mergetool ('--progress') to notify the current merge operation to the mergetool

* Added a parameter in mergetool ('--extrainfofile') to get extra information about the current merge in the mergetool

* Implemented a panel in mergetool to show the extended merge info

* Implemented the needed changes to pass progress and extra info to the mergetool in merge command.

* Improved the symbolic names passed to the mergetool.

* Implemented a mechanism to identify virtual changesets when a recursive merge is performed.

* Symbolic paths are now relative to the workspace.

* Changed the default merge tool to provide both '--progress' and '--extrainfofile' parameters

* Fixed maximize and restored botton image aligment (also fixed the restore button image, that was wrong)

* When the contributor text is trimmed in the 'select contributor' buttons, now the tooltip shows the entire string.

NOTE: In order to see new changes if you use the Plastic SCM built-in merge tool (Xmerge), you need to add the following parameters to the mergetool in plastic preferences: --progress="@progress" --extrainfofile="@extrainfofile"

New

P4 sync: Now the sync process will stop the execution if the inner P4 command cannot be successfully executed. Also, the inner P4 commands are now logged in the configured log4net file.

Currently, pushing a Plastic SCM changeset to a perforce stream with remapping rule is not supported, but before this task, the sync process was continuing, marking as 'synced' with perforce the Plastic SCM changeset, when it shouldn't, as the push operation from Plastic SCM to P4 couldn't be completed. From now on, the sync process will be stopped in that scenario before marking as 'synced' Plastic SCM changesets that weren't pushed to P4.

Nevertheless, this behavior can be overriden by using the '--continueonp4error' flag in the 'cm sync p4' command (not recommended).

New

Server: The changeset tree loading has been improved on MySql backend for big trees.

Now, a temporary table with the involved revisiond is created when loading a tree.

This table will be created in the hard disk by default. To override this setting and create the temporary table in memory, the following parameter in the server's db.conf file can be set:

        <MySqlTmpTablesOnMemory>yes</MySqlTmpTablesOnMemory>
        

The 'LOAD DATA LOCAL' setting in MySql backend must be enabled. (This setting is already enabled by default).

More info on:

http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_local_infile

Test performed:

Repository with 11 million revisions. Changeset tree loading measurement, with 418950 files and 27914 folders.

Time to read all the changeset tree revisions

(about 440.000 revisions):

- Before this release (release 4.1.10.559):

* Read 440.000 revisions from the 'revisions' table (which contains 11 million revisions) -> 11404 ms.

- Whith this release (release 4.1.10.561):

* Read 440.000 revisions from disk temp table -> 9688 ms.

* Read 440.000 revisions from memory temp table -> 6084 ms.