Can Subversion do shelving? And should you really?

This morning Chatura, one of the Puzzlepart core developers, asked me how we should approach the need for "shelving" with our Subversion repositories. Chatura has extensive experience with TFS and wants be able to use the powerful tools of TFS on our development platform too.

Shelving is a Team Foundation Server term describing ”temporary” commits. Svn doesn’t put a name on this, but encourages teams to establish their own strategy for shelving. In my opinion this is a good thing because you'll need to get the communication and understanding going within the team and establish some best practice for your scenario. With svn teams usually select one of two trunk strategies that influences how you “shelve”:

• Stable trunk; Team thrives to keep commits to trunk always building and testing out OK. This often introduces a need for an explicit shelving strategy. Most common here is (as probably described below) the use of temporary branches.
• Unstable trunk; The team accepts the trunk to be unstable and encourages frequent commits. This strategy is often supplemented with a versioned branch which is used as source for the CI system etc.

I.o.w. shelving in svn, regardless of strategy, requires the team to master branching. Branching (imo) is a lot easier in svn than in other scc systems, but it’s easy to get confused about what is connected to what branch etc. In this regard its always best to try to keep it to a minimum. Trumpi has a pragmatic guide on the use of svn branches to mimic shelving.

My approach so far has been to aim for “Stable trunk”. Whenever I’m releasing or using components in some other project I create a descriptive tag (not branch) for this version so that I can always get back to exactly that codebase in case the release or consuming project gets into trouble.

If a pressing need for branching occurs we should create a new branch, commit our “shelved” code here and return to working on the trunk (much as Trumpi described). The important thing is that the branch-commit should be completed and merged into the trunk ASAP. Rouge branches collecting dust in your repository is lethal cruft for your codebase.

Much of the shelving needs often stems from working on too many things at once, or that the trunk contains too many, or unrelated components. We need to keep this in mind too. If we make sure we work on, and complete, one autonomous piece of value at a time, and that these tasks are split into < 8 hour chunks we’ll very seldom get the need for shelving. Said in another way; a frequent “need” for shelving might be a “smell” indicating that we could have done better planning. So this actually stems back to our work in the issue tracker. Think about defining tasks for yourself and your team members that can be completed as a whole, instead of huge tasks that take days or weeks and you'll see much less need for shelving.

So yes; we can do shelving from time to time, but it should most definitely be an exception to the rule and we should think long and hard about what we are doing to the codebase whenever we feel the need to put something on the shelf. This is also one of the reasons why we prefer Subversion over TFS; you have to think about how you do things. Software development projects are complex and with individual needs, and these issues should be well communicated and understood within the team. Giving developers easy-out-options and quick wizard'ish buttons might help immediately, but often omits the real challenge.