Shelving (stashing) introduced

Shelving (stashing) introduced

Monday, February 20, 2012 Pablo Santos branching , news 0 Comments

We had automatic shelving on versions 1 to 3.0 but it was removed in 4.0 due to the major underlying re-design and also time constraints.

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
Store temporary 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.

Context Switching: saving your work on your current task so you can switch to another high priority task. Say you're working on a new feature, minding your own business, when your boss runs in and says "Ahhh! Bug Bug Bug!" and you have to drop your current changes on the feature, and go fix the bug. You can shelve your work on the feature, fix the bug, then come back and unshelve to work on your changes later. Altenatively in Plastic SCM and “branch per task” you can simply checkin and switch. But shelving definitely adds flexibility on top of branch per task.

Sharing Changesets: if you want to share a changeset with another developer without checking it in, you can shelve it and make it available on the server side. This could be used when you are passing an incomplete task to someone else (although here ‘branch per task’ solves the scenario in a cleaner way) or if you have some sort of testing code you would never EVER check in that someone else needed to run.

The answer highlights one point I wouldn’t use “shelves” for:

Saving your progress: while you're working on a complex feature, you may find yourself at a 'good point' where you would like to save your progress, this is an ideal time to shelve your code. Say you are hacking up some CSS / HTML to fix rendering bugs, usually you bang on it iterating every possible kludge you can think up until it looks right. However, once it looks right you may want to try and go back in to cleanup your markup so that someone else may be able to understand what you did before you check it in. In this case, you can shelve the code when everything renders right, then you are free to go and refactor your markup knowing that if you accidentally break it again, you can always go back and get your changeset.

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”:

From here you can simply select “apply shelve” on the shelve context menu and a “merge will happen”.

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.

When will it be available?

Our plan is to make 4.1 available in March 2012, before the Game Developers Conference. We plan to create a “labs” area under downloads to make the new version available for the ones who can’t wait! :P

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.