Now we’re working to release 4.1 and it includes, among others, the new shelve system that blends the good things of the traditional shelving mechanism and the ability to “merge” shelves like some DVCS do (consider git stash).
This is the list of features of the new “shelve mechanism”:
|Feature||Plastic SCM 4.1||TFS||Git||Perforce|
work in progress
||Yes||Yes (shelve)||Yes (stash)||Yes (p4 shelve)|
|Apply temporary work to a different branch||Yes||No (can't merge, just copy)||Yes (stash)||Partial (you can later apply a "resolve")|
|Share shelves among developers||Yes||Yes||No||Yes|
|Share shelves among different servers (DVCS way)||Yes (using replica)||No (is not a DVCS)||No (can't share stash)||No (not a DVCS)|
When is shelving useful?Check this great Stack Overflow post for more info.
The answer highlights one point I wouldn’t use “shelves” for:
I would never use shelves for this. Branch per task is simply a much better pattern. You checkin when you want to create a new “checkpoint”, that’s it, easy and simple, no extra operations needed.
TFS needs to use “shelving” for this because “branch per task” is not doable with high number of branches (I mean, it works in “hello world” projects but not in real conditions).
How does it work?Suppose you’ve some debug code that you don’t want to checkin but want to keep the same debug statements when switching to a new branch.
You go to Plastic’s “pending changes” view but instead of “checkin in” you decide to “shelve”.
Now you decide to switch to a different branch (for instance due to a context change, priority change or whatever).
Then you look for the “shelves view” in Plastic:
And show the available “shelves”:
The important change from 3.0 is that a shelve is not just a copy that you can “restore”, you can make some changes and apply them to a different branch using the same underlying merge mechanism you’re used to.