Release Notes

Command line client: the cm label command now comes with added subcommand goodness.

Check out these examples:

cm label create BL001

Sets the label BL001 on the latest changeset in the current workspace.

cm label BL001

'create' is the default subcommand for 'label', so this works too!

cm label rename BL001 BL002

Rename the label

cm label delete BL002

Delete the label

cm label BL003 cs:1 -c="Label on changeset 1"
cm label BL004 cs:2@myrepo -c="Label on changeset 2 of repository 'myrepo'"
cm label BL005 \workspace_path - c="Label on current changeset of specified workspace"

Some other ways to set labels.

Note: 'makelabel', 'removelabel' and 'renamelabel' are now deprecated, but remain available in the tool.

Command Line Client: the new 'clone' command joins the family! You probably already imagine what it does: the clone command clones a source repository (all of its branches, changesets, labels, code reviews, and so on) into a destination repository. If the destination repository does not exist, it is created automatically. If it does, it must be empty, or the clone is cancelled.

These are a few examples of how to use the clone command:

cm clone codice@skull.home:9095
(Clones codice repository from skull.home:9095 into a repository also named codice in my default repository server.)

cm clone codice@skull.home:9095 codice-local
(Clones codice repository into a  repository called codice-local in my default repository server.)

Like its push and pull siblings, the clone command also supports authentication and owner translation options:

cm clone codice@skull.home:9095 --authmode=UPWorkingMode --user=sergio --password=pwd
(Clones codice repository using a user and a password to authenticate against skull.home:9095.)

cm clone codice@skull.home:9095 --trmode=table --trtable=table.txt
(Clones codice repository, translating the users using the content of the table defined in table.txt.)

You can also use the clone command to clone repositories from your Plastic Cloud organization:

cm clone myRepo@tardis@cloud
(Clones the myRepo repository from Plastic Cloud tardis organization into a repository with the same name in my default repository server.)

For further information, you can execute:

cm help clone

Hope you find it useful!

(This closes the UserVoice request Simple repository clone operation).

DevOps: The trunk-bot CI Integration plug selection is now optional. This is done this way to ease the evaluation of the DevOps mergebot cycle for a repository without actually having to configure a CI system and its related plug. Therefore, no builds in any CI system will be triggered when merging a task branch.

Server: DevOps: trunk-bot configuration for fixed recipients in the "notifications" section now allows entering a comma-separated list of values, where these values could be either a raw value (such as an email address) or a plastic user. In case of the latter, the actual value will be resolved with the defined user profile field, if possible.

Consider the following example, where a trunk-bot is configured with an email notifier:

The "Always notify to" contains :

- An actual email address: developers@plasticscm.com

- Three plastic users: jemago, will and andrea -> their actual email addresses will be calculated getting their configured "email" profile value:

(Before this release, the "Always notify to" field in trunk-bot configuration didn't allow specifying plastic users, just email addresses).

Command line client: No need to checkout a changed file before checkin. Before, to checkin a locally changed file, you had to do one of the following actions:

1) Check out the file, then check it in:
    $ echo foo >> file.txt
    $ cm co file.txt
    $ cm ci file.txt

2) Checkin the file with the --applychanged flag:
    $ echo foo >> file.txt
    $ cm ci --applychanged file.txt

Now the flag is not necessary if you specify the files you want to checkin:

3) Just change the file and check it in:
    $ echo foo >> file.txt
    $ cm ci file.txt

We think that if you explicitly specify the file then you know what you're doing, and forcing you to checkout the file first is just a hassle.

However, this does NOT work with directories nor wildcards, as it might be dangerous (we humans tend to overlook things!):

a) This does NOT work:
    $ echo foo >> src/file.txt
    $ cm ci src

b) This does NOT work either:
    $ echo foo >> src/file.txt
    $ cm ci src/*.txt

c) This DOES work:
    $ echo foo >> src/file.txt
    $ cm ci src/file.txt

d) This ALSO works:
    $ echo foo >> src/file.txt
    $ cm ci --applychanged src/*.txt

All of these changes also apply to the 'cm partial ci' command, the checkin command for partial (Gluon) workspaces.