Release Notes

Public

9.0.16.4164: Apr 20 2020

New

All platforms - CLI: We improved how the 'getworkspacefrompath' command works!

Now, the getworkspacefrompath automation command returns a failure result if the specified path is not in a workspace. It used to always return success, which made catching problems when scripting more difficult than it should have been. Sorry about that!

New

All platforms - Logging: We changed the default filename format of the daily rolling file appender.

It was "yyyy-MM-dd-{filename}" but now it's "{filename}.yyyyMMdd". This way we think it is easier to navigate these files using a shell with autocompletion.

We also added the option to preserve the file extension. You'll probably want to use this on Windows so that, for example, if your base filename is "logfile.txt", the generated log files will be like "logfile.yyyyMMdd.txt" instead of "logfile.txt.yyyyMMdd".

To configure this log appender, add something like the following to your "log.conf" file.

    <appender name="DebugAppender" type="Codice.LogWrapper.DailyRollingFileAppender">
        <file value="cm.debug.log.txt" />
        <maxFileCount value="3" />
        <preserveLogFileNameExtension value="true" />
        <appendToFile value="true" />
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date %thread %property{TransactionID} %property{ClientMachine} %-5level %logger - %message%newline" />
        </layout>
    </appender>
    <root>
        <level value="DEBUG" /> 
        <appender-ref ref="DebugAppender" />
    </root>

This will generate files like: cm.debug.log.20200227.txt, cm.debug.log.20200228.txt and so on.

The maxFileCount property is the maximum number of files to keep on disk. The system removes the oldest files once the number of log files exceeds maxFileCount.

The preserveLogFileNameExtension property should be true if you want to preserve the extension, as discussed before.

Bug

All platforms - Command line client, Plastic: We fixed two errors in the 'undo' operation.

The first one is that undoing changes could fail with a null error. This happened very rarely and only when the pending changes contained a duplicated change.

The second one is that undoing changes could also fail with the error message "An error occurred processing the request. No more information is available...". This happened when a merge operation deleted a cloaked directory.

Both are now fixed!

Bug

All platforms - Command line client, Plastic: We fixed an error in the move operation.

Moving items around in a controlled manner could fail with the error "Can't add an entry with the same name. Duplicated child...". This happened when you moved a Copied or Added item to a directory that contained another workspace change with the same name. Now it's fixed!

Bug

Linux - Watchdog: We fixed a bug after upgrading servers using a ZIP.

The watchdog removed write permissions to the plasticd binary after an upgrade. This caused consequent upgrades to fail, as the watchdog could not override the plasticd file. Fixed!

For now we don't distribute the Plastic SCM Watchdog, but if you think you could benefit from it, don't hesitate to contact us at support at codicesoftware dot com.