Plastic SCM CLI guide

Plastic SCM is a visual version control system. But, it can also be used from the command line.

This guide walks you step by step through common command line interface (CLI) scenarios to help you get familiar with Plastic.

To create a new workspace, use the cm workspace create command.

Then, go to the newly created directory:

Which is still on changeset 0 because there hasn't been an update yet. By default, the workspace is configured to use the branch main.

You can check what the latest changeset on the branch is by running cm status --head:

You can update to the latest changeset by simply typing:

The command then will start dumping all the info about the files being copied until it's up-to-date with latest changeset.

573 in this case.

To create a new branch, run the cm branch (or cm branch create) command:

As cm status shows, the current branch hasn't been switched to yet:

Since a starting point hadn't been specified, the new branch starts from the latest changeset on the parent branch, in this case, cset 573 at main. You can use the --changeset and --label modifiers to specify a given changeset or label to start the branch from.

Switch the workspace to the branch by using the switch command:

The new branch is still empty, so Plastic didn't update anything on the workspace to do the switch because fix-1342 points to the same cset 573.

To edit a file in your workspace and search for changes to locate it:

status shows not only the wk configuration (as shown before) but also the files changed, checked-out, moved, deleted, and so on.

To move FileSystem-renamed.cs to a new location:

Run status to find the moved file:

Where Moved locally means the file was moved outside of Plastic control, but it is able to find the moved file because it is still 99% similar to the previous version.

Then I can checkin my change easily:

The default ci command checks in all added files. With ci --all you're telling Plastic: detect everything that changed and perform a checkin. And all means: files that are changed, deleted or moved. We can also include private files by using ci --all --private.

The cm log command shows the changes made on a given cset or in a specific cset range:

In the last changeset checked in, the file FileSystem.cs was modified and moved.

The command cm diff does something similar, but it is always limited to a given cset:

You can throw away all your pending changes and start from scratch.

Check the current status:

To undo changes, run the undo command recursively:

The current status with no changes:

Note:

• By default, undo applies to all changes, whether they're real "checkouts" or simply changed files, but you can limit the undo to specific change types. In Plastic, a "changed file" and a "checkedout file" are slightly different, and some commands reflect that.

You can restrict the undo to specific change types by using the filter options:

Suppose you have the same changes as above, but this time, you have added and deleted a couple of files:

To undo the Add and the Remove, but leave the changes untouched, use the filters:

And now the status is:

What if you just want to undo a single changed file?

Here, a couple of files have been modified:

To only undo the changes to cg_main.c, run the following command:

You can undo a few changes under certain paths:

To undo the changes under code but leave the one under merge:

And now the status is as expected:

You can target the undo even more precisely using wildcards:

This time, to undo the header files under code but leave the source files:

And now the status is as expected:

You can checkin specific modified files on a given path:

To only checkin the ones inside q3radiant\alpha, run the checkin command:

In Plastic SCM, files can be changed, or they can be checked out. Hence you can follow two workflows: edit-checkin or checkout-edit-checkin.

Checking out a file just means telling Plastic "hey, I'm going to modify the file" so it adds the file to an internal list of checked out files.

There are 3 main reasons to work with checkouts:

1. You're used to working this way because you come from Perforce (p4 edit) or ClearCase (checkout). If you work this way, chances are that you also like setting all your files as read-only in your workspace as some sort of "protection" so that the filesystem will warn you if you modify a file before checking it out.
   
2. If you need to work with exclusive checkouts (locks), you need to checkout files before editing them. Read more about locks here.
3. If you're working on a huge codebase (>500k files), you might use checkouts to speed up all operations. cm status walks through your workspace looking for changes. If you use checkouts, the status command lists the files in the checkout list, no disk access is required.

Working in checkout-edit-checkin fashion is simple: run a cm co command before editing any file.

Bmp.cpp is marked as checked-out instead of just changed.

Files moved using the cm mv command are considered to be another form of checked-out, as you can see in the following example:

You see that aselib.c is not "locally moved" but simply moved.

You can checkin the two checked-out files as follows:

Since the --all modifier hadn't been specified in the checkin, only the checked-out files were checked-in, and the Socket.cs file is still a pending change:

Merging from the CLI is straightforward: run the cm merge command.

So far, changes were made in the main/fix-1342 branch, so they'll be merged in the main branch.

Switch to main:

The switch can't happen because the Socket.cs file is left behind. You would undo the change first and try to switch again:

The switch command updates the workspace, replacing all the files changed on the branch with the versions in main.

Now the status is as follows:

Which is also reflected in the Branch Explorer:

Run the merge command:

Merging without any modifier just prints a preview of what's going to be merged so it is very useful to understand what is going to happen.

In order to make the merge more interesting, the FileSystem-renamed.cs file is modified (it was moved and renamed on the branch):

Re-run the merge and add a comment:

In the last line, FileSystem-renamed.cs now needs a 3-way merge since it was modified by the two contributors.

Run the merge adding the --merge (to actually perform the merge), and the --commentsfile (to set the new changeset's comment from the file content) modifiers to the merge command:

Plastic applies all merges to the workspace, and it launches the 3-way merge tool you've configured (by default, Plastic's Xmerge) to solve the conflicts in FileSystem.cs. Note how FileSystem.cs has been properly moved and renamed and that the file contents were correctly merged.

Now, if you run a status command, all merged files are in a checked-out status:

You see new statuses in use now: Replaced which means that, for efficency, rather than copy the file in version control, a pointer to the original location on the branch is stored, and then the FileSystem.cs file marked as a real Checked-out since it was merged.

At this point, the Branch Explorer looks like this:

The dashed-line means the merge is still in progress and it is not yet checked-in.

Now you can simply check-in using the cm ci command:

To label the newly merged code, run the cm label command:

And the Branch Explorer now appears as:

To listing the repos on a given server, use the repository [list] command:

By default, repository shows the repos in the default server, which is the server you configure in your config wizard and is written in your client.conf:

The repository list command is extremely helpful to diagnose connection issues with your server because you can also type different servers as follows:

Plastic SCM keeps a list of the workspaces you have on your machine (at least the ones it knows about because you can always copy a workspace from somewhere and Plastic will not have it on the list).

This guide is just a small piece of all the things you can do with the CLI. To find out what other commands are available, you can run cm showcommands.

Also, all commands come with built-in documentation of their options cm <command> --usage, and comprehensive help with examples cm <command> --help

There may be an occasion when the CLI isn't behaving as you expect, and you want to get in touch with our wonderful support team. To help them diagnose your issue, you can send them a zip-file full of useful diagnostic information, which you can generate using the cm support command as follows.

A script has been run which has made a bunch of changes to the source files, including a local move and delete. The status looks like this:

To bring these changes under source control, now that the files have moved or been deleted, run the move or remove commands and create controlled changes:

When working on some experimental code changes, you may want to save them in source control and share them with teammates, but you don't want to check them into any branch because they are experimental.

In this situation, use the shelveset command to, in effect, commit a changeset not associated with any branch.

To get back those experimental changes, use the apply subcommand to apply the shelveset to my workspace.

An often overlooked feature of the Plastic CLI is that it can read arguments from stdin one-by-one, using the - option, like this:

This is useful because it means you can pipe output from other commands into cm.

The following commands accept piped paths:

• add
• applylocalchanges
• checkin
• checkout
• getstatus
• partialcheckin
• remove
• shelveset create
• undocheckout
• undochange
• uncounchanged
• wktreenodestatus

• You can pipe from the Windows dir command to easily remove all files matching a pattern from my workspace: >dir /S /B *.txt | cm rm - Item c:\Users\pablo\wkspaces\mcga\a.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\b.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\c.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\z.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\lockwkB\file.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\src_dir\dest_dir\a.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\src_dir\dest_dir\b.txt has been removed. Item c:\Users\pablo\wkspaces\mcga\src_dir\dest_dir\c.txt has been removed.
• The checkout command can recurse into piped directory arguments: Directory of c:/mcga/pipe 11/05/2020 19:48 <DIR> . 11/05/2020 19:48 <DIR> .. 11/05/2020 17:57 <DIR> dir 11/05/2020 19:46 <DIR> dir2 11/05/2020 19:47 12 dirlist 1 File(s) 12 bytes 4 Dir(s) 23,714,631,680 bytes free c:/mcga/pipe>type dirlist dir dir2 c:/mcga/pipe>type dirlist | cm partial co -r - The selected items are about to be checked out. Please wait ... Item c:/mcga/pipe/dir was correctly checked out Item c:/mcga/pipe/dir/file was correctly checked out Item c:/mcga/pipe/dir2 was correctly checked out Item c:/mcga/pipe/dir2/file2 was correctly checked out

Now there's nothing stopping you building cool scripts using pipe and cm together!

June 10, 2020

• In the Using pipe chapter, you can now find an example about how the checkout command can recurse into piped directory arguments.

June 08, 2020

• We edited the cm status examples because its output now includes the head changeset by default.

January 21, 2020

• Now, it's possible to update the whole current workspace without specifying any path .

May 16, 2019

• We added a section about using pipe with the Plastic CLI.

March 26, 2019

• We updated the examples of how to undo changes to use the new cm undo command.

May 14, 2019

• We replaced the references to deprecated workspace administration commands like cm mkwk with their new counterparts.

March 22, 2019

• We replaced the references to deprecated repository administration commands like cm lrep with their new counterparts.
• We edited the chapter Create a new branch and switch to it to replace the deprecated cm mkbr command with cm branch.

March 21, 2019

• We updated a section about shelving changes using the cm shelveset command.

March 13, 2019

• We changed a reference to cm mklabel to cm label inline with the new label related commands in the CLI.

February 8, 2019

• We updated the output of cm status throughout the guide to reflect the new output format and changes to the options.
• We edited the Create a new workspace chapter to show you how to use cm status --head to view the head changeset.
• We added a new chapter Getting help to show you how to use cm support to generate diagnostic information.
• We added a new chapter Local changes to show you how to use cm mv and cm rm to bring local changes under source control.
• We shortened a few paths in the examples to improve readability.

September 4, 2018

• We edited the Merging chapter to show you how to include comments (-c and --commentsfile modifiers) during the merge operation.

February 26, 2018

• Run the cm help objectspec command to learn about the definition of the different object specs supported by Plastic.

August 24, 2015

• The cm log and cm diff examples have been updated: now these commands print the workspace root relative paths by default, instead of the full workspace paths.
• Improved format string for lrep and lwk commands.