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
authentication mode
in the server is "local name". You can use this mode for evaluation purposes.
Your username will be used by default in the client.
If you need to configure a particular setting, then open the
webadmin - the Plastic Server admin console
. To do this, just open your favorite web browser and connect to your server
address like this: http://ipserver:7178
Once you finish the configuration, your local client and server will be ready to use.
The Plastic SCM default installation uses
Jet
as the embedded repository storage. So that installation and configuration becomes extremely
easy.
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:
Plastic SCM - Windows - Create repo & wk
Plastic SCM - Mac OS - Create repo & wk
And then, you have your workspace (working directory) and new repository up and running:
Plastic SCM - Windows - Workspace created
Plastic SCM - Linux - Workspace created
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).
Screenshot of pulling some code
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
server demo.plasticscm.com.
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
and changesets.
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
distributed operations.
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
partial replica
(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
Baseline109.
Click "Create branch from this label". We're going to create a branch named
bugfix4001.
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
bugfix4001.
In order to do that, we're going to do two things:
We're going to move the file
common\FileSystem.cs to
libs\cmdlib\FileSystem-Renamed.cs.
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
to art\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.
Now we're going to merge from
bugfix4001
into bugfix4002.
In order to do that:
Go to the Branch Explorer.
Right click bugfix4001.
Select "merge from this branch".
Then a new tab with the merge will be displayed (very similar to the one in the
screenshot below).
Plastic SCM detects a "divergent move conflict" as we expected.
Now click "Choose" in the "Resolution method" column in the "Divergent move conflict"
and a dialog like the one in the screenshot will show up. Here you can choose how
to solve the conflict.
We will keep the source
contributor which means we will keep the move done in
bugfix4001.
It means that the file will be moved to
/libs/cmdlib and renamed to
FileSystem-Renamed.cs.
Note: Do not forget to follow these instructions precisely in order to complete the
exercise correctly and qualify for the awesome Plastic SCM T-Shirt :-)
Look carefully in the "merge tab" and you will find an "explain merge" button. Click it
and you will see a diagram like the one on the screenshot below.
It explains which ones are the 3 contributors on the merge: the 'source' (or theirs),
the 'destination' (or yours) and also the 'base' (a.k.a. 'common ancestor').
Now go back to the "merge tab" and click on "Process all merges". Once the directory
conflict was solved, Plastic SCM will try to solve the file merge.
Remember that the file FileSystem.cs
was not only moved but also modified.
So when you run "Process all merges" the built-in 3-way merge tool will be launched.
It shows the following information:
Left panel shows the 'source' revision, the revision coming from branch
bugfix4001.
The center panel shows how the file was prior to the two modifications performed
in parallel. Actually, the content of the file in the label
Baseline109.
The right panel shows the 'destination' or how the file is on the destination
branch, this time bugfix4002.
The panel in the bottom shows the 'result' of the merge.
Plastic SCM detects a "divergent move conflict" as we expected.
You can click the 'blue', 'yellow' or 'green' buttons to select the right contributor
for the conflict (remember, the line with
count_ = ).
In order to complete the exercise correctly, please make sure you keep the change
containing the line count_ = 350;.
Then click "Save & Exit" and the merge tool will be closed. Now go to "pending
changes" and checkin.
Congratulations, you've completed your first merge cycle with Plastic SCM!
Plastic SCM implements the most powerful merge engine, enabling full parallel development.
No other version control system, including the modern DVCS like Git and Mercurial, are able
to handle a case like this. They will end up duplicating the divergently modified file.
This is just a small example of the underlying merge power of Plastic SCM ‐ the
merge machine.
Submit
Congratulations for completing the Evaluation Guide. Now, if you want to request your
free Plastic SCM t-shirt please complete the following steps.
Now, your Branch Explorer should look like the one below, with the branch
bugfix4001
correctly merged into bugfix4002:
Create a new branch from bugfix4002
and give it a new name.
The really important step is to fill in the "comment" of the branch with your email
address, so we know how to enable the t-shirt claim page in your www.plasticscm.com account.
Click "OK" to create your new branch:
Now, it's time to push your changes back to the
demo.plasticscm.com server.
Right click your newly created branch.
Go to "replication / push branch".
Type demo.plasticscm.com:38087 as the server to push your branch to.
Select the "result" repository from the list. Remember the user and password is
demo/demo in case you are asked for it.
Press "Replicate" and you are done!
Now, if the exercise was completed correctly, you will receive an email notification
and you will be able to claim your t-shirt from www.plasticscm.com.
