Release Notes



Nov 07 2017

No-data replica is now ready! Grab metadata but skip data to have light but fully workable local repos.

You can use the --nodata flag in the cm replicate command to pull metadata to your repo while skipping the actual data.

== What is replica no-data all about ==

The motivation is clear: huge local repos (dozens of GB) are painful because you end up with tons of data you won't be using most of the time. Why not simply replicate the metadata so you can effectively branch and checkin, while getting the actual data from the original server on demand?

== An example is worth a thousand words ==

You just create a clean local repo, then replicate a single branch from the remote server, without data. You can branch from it, checkin, do whatever, and freely push changes back correctly, but your local repo will be tiny.

cm mkrep game-of-cores@localhost:8087

cm replicate main@game-of-cores@volantis:8087 game-of-cores@localhost:8087 --nodata.

cm mkwk wk-dev .

cm mkbr main/got-1023

cm switch main/got-1023

Since localhost:8087 doesn't have any data, files will be downloaded from the original server volantis:8087 during update.

Your working copy will be fully operational, and your local repo will be tiny.

By the way, as soon as you checkin locally, new data will be entered in your local repo, no problem about that.

Finally, you will be able to push your newly created branch back to volantis:8087

cm replicate main/got-1023@game-of-cores game-of-cores@volantis:8087 --push

== What is the vision ==

Our vision here is: working distributed is the way to go but since we are online most of the time, why not take advantage of it?

All checkins go super-fast locally (waiting to checkin is a productivity killer), but we are online, so let's grab actual data from the central.

== What if I really need to go offline ==

First, if you updated your workspace while connected... well, you already have the data locally, so chances are we got you covered.

Alternatively, you can always continue using regular replica, which is fine.

Finally, there is a way to simply "hydrate" certain changesets (or branches) while the rest of the repo remains data-less :-P

== Hydrate - nodata perfect companion ==

Nodata replication has a perfect companion: the cm replicate hydrate command, which lets you download data for a certain changeset to your local repo from a given specified source.

It works as follows:

cm replicate hydrate cs:1724@myrepo quake@central:8087

And you can also hydrate a branch if you want to (which will actually hydrate all its changesets):

cm replicate hydrate main@myrepo quake@central:8087


The revert operation was not locking (getting the exclusive checkout) the reverted files. Now the lock is done as expected.


The cloaked exception rules were not working inside a cloaked xlink. See an example:

Cloaked rules:







/theme (xlink)



Before the fix, all the workspace content was cloaked and no content was downloaded. The second line ('*.jpg') didn't affect the xlinked contents.

Now, that rule is properly applied to the whole tree and only these items will be downloaded:




REMARKS: this fix requires both server and client to be updated.


When configuring ignored/cloaked rules, the workspace-relative paths are still allowed by prepending the text "$workspace". But it was not properly working for exception rules.




Internal and public releases

The Plastic SCM development team works in short iterations delivering frequent releases.Our goal is to have at least one new release every week, with new functionalities, bug fixes and performance tweaks.

Every 'weekly' release is not published to our customers, but we like to detail each of them in the release notes so users can easily follow what we achieved on every short iteration.

The releases marked with the word "public" are the ones we do publish on the website. The ones marked as "internal" are the releases we create in-house to keep the project moving week after week.

Version numbering

Starting in Plastic SCM 4.0 the version numbering schema has been modified:

  • major.minor.compatibility.buildnumber

  • Sample: means:
    • 5 -> major release number
    • 0 -> minor release number
    • 44 -> compatibility -> all clients and servers with "44" in the compat number are compatible, even if the build number changes
    • 511 -> internal build number