Shelving Subversion
My colleague Clinton Begin asked me whether Subversion supports shelving. This is something that the new Visual Studio may have as part of its “Team” features, and is basically a way for a developer to put aside a set of changes come back to them later. Storing shelved changes in your version control tool is pretty sensible—your repository is reliable, backed up, and not liable to disappear if someone pinches your laptop.
So can you do this kind of thing with Subversion? You betcha. Here’s roughly how it would work:
- Whilst working on adding the new “frobscottle” feature Alice decides she’d like to shelve her current working copy changes. Her project, codenamed “xyzzy,” is checked out from
svn://svn.acme.com/xyzzy/trunk. - Needing somewhere to store her changes, Alice branches the trunk to create
svn://svn.acme.com/xyzzy/shelves/alice/frobscottle. - Alice uses the Subversion switch command to switch her working copy from the trunk to the new frobscottle branch. When switching, Subversion preserves any changes you’ve made to the working copy.
- Alice checks in her working copy. The changes will be safely stored under the shelves directory.
- Alice switches her working copy back to the trunk and works on something else. In future if she wants the shelved frobscottle changes she can merge from the branch to her trunk working copy, then commit the changes back into the main code line.
There are a few details you’ll need to get right—you may need to create the new branch from an older revision on the trunk rather than from the head—and it’s less pretty than a “shelve” button in a GUI, but it’ll work great and you’ll understand exactly where your changes actually are.
mike on March 30th 2005 in Version Control
Chris Rathjen responded on 02 Jan 2008 at 6:25 am #
I’m glad to see a nice clean example of this.
Shelving vs. Branching (or creating a new view/workspace/enlistment) is definitely a tradeoff. Shelves are intended to be temporary creations and satisify a particular set of scenarios. If you need rich control over a set of potential changes, or need a lot of ‘bake time’ before committing them, a private branch is definitely the way to go.
Having said that, there’s times where the shelve feature can speed up part of your process. We find it particularly useful internally for code reviews (just email around the unshelve link and anyone can do a complete code review, buddy build, buddy test, etc.), and for late stages in the cycle where every checkin receives higher scrutiny. The shelveset becomes ‘the proposed change’, but is a more tangible artifact than the difference between a private branch and the source branch: It’s easy for ANY party to review, not just other devs and testers, and it makes building and testing *just that change* a straightforward process.
I imagine you could create those scenarios in a Subversion UI without much (if any) changes to the core feature set – it builds on logic that already exists in commands like branch, merge, and new workspace.
Uwe responded on 18 Nov 2010 at 7:45 am #
Seems that als “shelving subversion” Google searches lead to pages that contains explanations like yours.
I was looking for a kind of “daily backup” method into a constant folder.
When trying to “shelve” into an existing folder, this fails because of the fact that the folder already exists.
So I have to find another solutions for this.