PlasticSCM–First encounters

I was looking for a source-control system that I could use at home, which meant that TFS would not be a good candidate for me (although it’s the SCRM that I have the most experience with). I have tested out SVN and Mercurial, but for some reason they didn’t grow on me.

Today I came across PlasticSCM (via a recent blog post regarding their new release 4.0). So I decided to give it a try. (The main reason being that it’s a distributed SCM and based on what I had seen on PlasticSCM’s website, the visualization tools were very good and it also had decent integration with Visual Studio). Another thing that I liked is that the free community edition allows you to use it with up to 15 users free of charge.

So here are some things I found out (based on usage with Visual Studio): (Remember these are just first impressions and this is also my first true usage of a distributed SCM).

1. I found having a separate repository for every solution was the way to go. When I first tried it out, I used a single repository and added all my solutions to that repository. (Each solution represented a completely distinct project). But it started getting very confusing, as I had to perform all sorts of merges everytime I opened a solution.
   Instead, when I created a separate repository for every solution (or group of solutions that represented the same project), things began working in what I considered a more predictable way.
2. I use Resharper and when I first added a solution to PlasticSCM, I had trouble everytime I closed the solution, as the file .user files could not be saved. In addition, PlasticSCM attempted to check-in all the Resharper temporary files. Currently, I am deleting these files after I add the solution to PlasticSCM and then check the files in. Also, once I have done that, I set PlasticSCM to ignore the *.user files and the _Resharper.* folder.
3. Although I havent performed much branching and merging as of yet, I found the visualization tools pretty cool

Some useful tips:

First thing to do is set PlasticSCM as the current Source Control Provider:

Next open up a solution that you want to put into source-control. Right click on the solution and select the “Add to source control” item.

This will bring up the New-Workspace dialog. Create a new repository for your solution (click New).

 

When you click on OK, it will automatically add the solution into PlasticSCM (into the newly created repository).

Now bring up the PlasticSCM client application (via the Start Menu).

You will find that a new Workspace has been created for the solution:

Click on the Items node in the left pane and then ensure that all the files that should be under source-control, show up with a status of “Controlled”.

You do this by selecting any item that is setup as “private” and select the “Add to source control” option.

Your final step is to check in all the files. This is done by selecting the “Pending Changes” option in the left pane and then clicking the “Check-in” button.

That’s it. Your solution is now under source-control.

What does PlasticSCM check-ins look like?

Here is an example: I had a main branch. I created 2 separate branches from main to represent 2 sets of changes that I wanted to make: Add a multiplication feature task and Add a division feature task. Both of these features were to be added to a single change-set in main (the most current changeset).

The 2 features represent coding tasks that 2 separate developers may be involved with. Once the 2 features are completed they are checked into their respective branches. After the features are checked into the branches, the branches are merged one by one into the main line.

And here is what the above scenario looks like:

Some final thoughts:

1. There doesn’t seem to be any in client help for PlasticSCM. So many times I had to go about exploring trying to attempt to do various tasks in PlasticSCM (for example setting the current workspace – there doesn’t seem to be a way to do this in the branch-explorer. Instead you do it via the Branches view).
2. During merges, I found that PlasticSCM didn’t do a lot of stuff automatically. I was always provided a diff/merge view (which was very beautiful in its rendering), and had to manually accept the merges. On large projects, this will become quite painful for the person incharge of merging various changesets into the main-line.
3. I definitely like PlasticSCM and will continue testing it out on my personal projects. I think it will be cool for large teams, but I am not entirely sure whether it’s a good replacement for TFS (which we currently do use at work). I plan on figuring this out as I work more with PlasticSCM.