The Plastic SCM server will be installed as a Windows Service.
In Windows, the Plastic Gluon client will also get installed. Select the Plastic SCM GUI
to be the tool we will use during this guide. For this evaluation, select only the
"Server components", as you see on the following screenshot:
Once the software is installed, you'll enter the Plastic SCM Server configuration phase.
It is rather simple. You can even go for the default options. We recommend the default
settings for all the installations (Windows, Linux, and macOS).
In Windows, the default
in the server is "local name". You can use this mode for evaluation purposes.
Your username will be used by default in the client.
Once you finish the configuration, your local client and server will be ready to use.
The Plastic SCM default installation uses
as the embedded repository storage. So that installation and configuration becomes extremely
For team servers, backends such as SQL Server, MySQL, or Postgres are more suitable.
Create repo & wk
This is the first screen you're going to see once the Plastic SCM client starts up.
We're going to create a new "project".
I created a new repository called quake
on my localhost:8087 which is the
server we just installed.
By default, Plastic will assign to the new workspace the same name you use to the repository
and a path on disk for the workspace.
Click "OK" to go create the repository and the workspace:
And then, you have your workspace (working directory) and new repository up and running:
Pulling some code
Let's start by unveiling the distributed way of working
Go to your branch explorer, right click on the "main" branch (the area surrounding
the "home" ellipsis) and show the replication menu.
You're going to "pull" from a remote server we've setup on "amazon" with sample code.
Use demo.plasticscm.com:38087 as the source Server.
To "browse" the remote server you'll be prompted for a user and password: enter demo/demo.
Select the "quakecode" repository. And now you're ready to click on the "replicate" button.
The replication process will fetch all the remote information for the "main" branch.
First it will get the metadata, write it to the local destination repository, then
it will replicate all the file data (the actual changes).
Distributed Branch Explorer
Go to the Branch Explorer and you will see a diagram like the one below.
This Branch Explorer contains the new changesets (ellipses) and labels that you have just
pulled from the remote repository. We only pulled the "main" branch so far.
Now click the "options" button. Then go to "replication sources" and click the
The Branch Explorer will get updated with new branches coming from the remote server.
They are not pulled but they are still rendered and you can diff the remote branches
With this simple "pull" operation, we have just demonstrated some of the unique features
of Plastic SCM:
It is fully distributed.
It provides visual representation of the branching & merging and also the
It provides "partial replication" - we just pulled the "main branch" but there are many other
branches available. Plastic SCM is the only DVCS able to perform
(git & mercurial can't).
It can explore remote repositories and remotely diff changes ‐ the other DVCS don't
provide remote "browsing" capabilities.
We're going to create our first branch. Right click the label
Click "Create branch from this label". We're going to create a branch named
And don't forget to switch your workspace to the new branch.
Once you have switched correctly to the new branch, your workspace should look like this:
Now we're going to change a file on the new branch
In order to do that, we're going to do two things:
We're going to move the file
As you see, we're moving the file to a new location and also renaming it.
Then, we're going to modify the file. Look for the line where it says
count_ = 400;
and change it with count_ = 350;
as you can see in the image below.
The screenshot shows you the pending changes view with the file that has been modified
and also moved and renamed.
Finally, type a comment and checkin your changes.
Once we've created our first branch and the first checkin, we're going to create a second change to force a merge conflict.
Create a new branch named bugfix4002
also starting from Baseline109.
And switch to it.
Now that we are at bugfix4002
branch, let's do the following:
Move the file common\FileSystem.cs
Edit the file and locate the same line that we modified on the previous branch. Now
it should be modified as follows:
count_ = 250
(check the screenshot below).
Checkin your new change.
As you can see, we've forced a
divergent move scenario
which means the same file has been moved in parallel to two different locations.
To make things even worse the file has also been modified.
This scenario means really big trouble for almost all other version control systems,
but Plastic SCM can handle it correctly.