New Plastic SCM is now out!

Wednesday, November 27, 2013 0 Comments

I’m happy to announce a new release of Plastic SCM 5.0, this time with a bunch of new features.

You can download the new release from the download area as usual.

The new features are:

  • Client changelists: a way to group changes in the pending changes view, making it easier to organize your workspace.
  • Improved graphical annotate/blame: line age, new look & feel, added stats and more. It is also available inside Visual Studio.
  • Improved cloaked rules: we’ve greatly improved the way in which cloaked rules are written so that it is easier to cloak directories, add exceptions and so on.
  • Branch Explorer adds kinetic scrolling: now you can drag the diagram as in a tactile screen and it will continue moving with inertia.
  • Leap Motion support in Branch Explorer: if you have one of the cool Leap Motion devices you can now use it to control the Branch Explorer. Cool for team meetings...
  • While it was released back in release 504, it is worth noting that we now have Unity support!!
  • Also, new look and feel for Visual Studio 2013 was out on 505 and of course available here.

Let me now describe each of the features in detail.

Client changelists

Now it is possible to group the changes on the pending changes view (the checkouts) on different groups called changelists. It is just a way to help you dealing with your own changes on your workspace (and it will sound familiar to the developers coming from Perforce).

As you can see in the following picture, there are some ‘built-in’ changelists and also some user-defined ones:

In the example you can see:

  • The ‘default changelist’: grouping the changes that are not into any other group.
  • A ‘nuget changes’ changelist: user defined. The user can move checkouts to any user-defined changelist from the ‘default’ or from other changelist.
  • A ‘merge changelist’: each in-progress merge on your workspace will be displayed as a changelist, greatly simplifying the view.
  • A ‘hidden changes’ changelist: ‘hidden changes’ are files that are were added to the ‘hidden changes list’ which means they won’t show up if they’re only modified but only if they’re also checkedout.

We expect this new feature to be useful to many users and especially for the ones migrating away from Perforce. While our implementation is not the same as P4’s if you’re used to clists you’ll probably feel at home here.

In order to enable the client changelists just go to pending changes, then to options and click on the following option:

Creating a new changelist is also rather simple as you will see below:

User defined changelists can be of two types: persistent, meaning they’ll stay even if they do not content any more, and non-persistent which means they’re automatically removed as soon as they get empty.

New annotate/blame GUI

After improving the annotate/blame internal mechanism a few releases ago, now it was the turn for the look and feel. We’ve done some clean up and also added some useful features.

As you can see in the picture below we’ve added new fields to the annotate view (now you can choose to select the author, changeset, branch, date and line age in days), also a way to color the lines by developer or date, and a new statistics panel showing the number of total lines, the average file age in days and finally displaying the number of changes done per developer.

We believe all this new information is going to make the annotate more useful when you’re reviewing a file and need to better understand its history.

We’ve also added the same info to the blame inside Visual Studio. In the screenshot below you can also check the look and feel of the ‘dark theme’ :-).

Improved cloaked/ignore/hidden rules

This is one of the key improvements on the new release. We’ve basically improved all the filter engine used by ignore.conf, cloaked.conf, hidden_changes.conf and writable.conf.

All the ‘old rules’ are still valid since we decided to keep it backwards compatible but we have introduced much powerful and simpler new rules.

Notes about the old syntax (still supported)

  • */dir_name will cloak all directories named "dir_name", but not their contents.
  • */dir_name/* will cloak the contents of all directories named "dir_name", but not the directories themselves.
  • */filename.extension is the preferred syntax to cloak all files named "filename.extension". Just typing "filename.extension" will work as well.
  • *.extension will cloak every file having ".extension" as its extension.
  • Workspace-relative paths are allowed by prepending the text "$workspace/" before a dir name or file name.
  • Inserted regular expressions will be automatically surrounded by characters '^' and '$' (start and end of line).

Main flaws

The main issues we had were:

  • Cloaking a directory requires two different rules. It leads to really cumbersome cloaked.conf files for advanced scenarios (we found some in the gaming industry).
  • Generic rules have to begin with a superfluous "*/" sequence.
  • Having "$workspace" as a keyword feels cumbersome.
  • A difference is being made between directories and files, overcomplicating the path resolution.
  • Regular expressions don't support features that others version controls do.
    • For instance, typing "*lib" will be translated into "^.*lib$", which will match with directory C:\lib but not with its contents, C:\lib\foo.c . This leads to inconsistency.
    • Other VCS match '*' as 'any string of non path separator characters' and '**' as 'any string of characters', whereas we interpret '*' as 'any string of characters'. This prevent us from allowing fine expression tuning.

New syntax

  • Remove the distinction between file names and directory names.
  • Match each element by its name first, and then by the one of its parent or ancestors.
  • Indicating a directory name will cloak all of its contained items.
  • Workspace-relative paths will begin by "/", no need to specify $workspace. This could introduce a conflict if working on UNIX systems, where "/" is also the root element of the filesystem. This way, we've introduced the symbol "//" to represent the actual root of the filesystem.
  • Suppress the restriction for regular expressions to be whole-line matches. It will mean that:
    • Users will have to explicitly indicate the start/end of line characters on their cloaked.conf files.
    • PlasticSCM will have support for basic scenarios where it isn't working at this time (see examples below).
  • 'name' will match file names and directories. If a directory is matched, all its descendants will be matched, too.
  • /'path' will match a path relative to the current workspace.
  • It won't be required to write */ to start a rule nor /* to finish it. It will be treated as a regular expression if done, though.


A 'obj' rule will the following items:

- /obj
- /obj/code.o
- /obj/Debug
- /obj/Debug/code.o
- /project/obj/
- /project/obj/code.o
- /project/obj/Debug
- /project/obj/Debug/code.o

‘/obj' rule will cloak the following items:

- /obj
- /obj/code.o
- /obj/Debug
- /obj/Debug/code.o
But it won't cloak the following items:
- /project/obj/
- /project/obj/code.o
- /project/obj/Debug
- /project/obj/Debug/code.o

A '/lib/*.dll' rule will cloak the following items:

- /lib
- /lib/new.dll
But it won't cloak these:
- /lib/new.exe
- /lib/Debug [this is a directory]
- /lib/Debug/new.dll

A '/lib/**.dll' rule will cloak the following items (note it matches any subdirectory inside /lib):

- /lib/new.dll
- /lib/Debug/new.dll
- /lib/Debug/old/new.dll
But it won't cloak these:
- /lib/new.exe
- /lib/Debug/new.c
- /lib/Debug/old/new.h

Leap Motion support for the Branch Explorer

You’ve probably heard of LeapMotion, the cool device to interact with your computer using your hands.

And you've probably seen how Elon Musk himself explained how to shape the future of design. It was actually our inspiration to come up with the following video :-D

Let’s watch the intro video recorded by Manu Lucio @mrcatacroquer (Miguel acting as director :P):

In case you already have a Leap Motion or feel the urgent need to order one now to plug it to Plastic, what do you need to configure it?

  • Make sure you install the Plastic SCM .NET 4 release (otherwise it won’t work). It is easy to find the .NET 4 release on our downloads page, it is clearly labeled.
  • Install the Leap Motion software:
  • Create an empty leapmotion.conf file in your plastic config path (tipically c:\users\xxx\appdata\local\plastic4\leapmotion.conf). This is what the Branch Explorer needs to start up the Leap Motion engine and look for a connected device.
  • Plug your Leap Motion to the USB.
  • The Branch Explorer will render a Leap Motion icon.

Then, in order to control the Branch Explorer, the following gestures are supported:

  • Pan horizontally: place you hand over the Leap Motion controller with your fingers slightly apart from each other. Move hand left and right to move the diagram horizontally.
  • Pan vertically: use the 'key tap' gesture (like pressing a button with your finger) to change the displacement mode from horizontal to vertical. Then, move your hand up and down to move the diagram vertically.
  • Zooming: place both hands around the Leap Motion controller, like holding a ball. Then move both hands, towards or away from each other (like compressing or expanding the ball).

Set it up on a big screen and your team meetings won’t be the same :-P

Branch Explorer dragging improvements

While implementing Leap Motion support we’ve added the ability to drag the diagram and it will have inertia like we’re used to on tactile devices (smartphones and tablets).

As you can see, we’ve added quite a good number of features to this new release, hope you enjoy it!

0 comentarios: