We found an article online recently, where one of the Subversion guys is talking about shelving. First, despite the title, we're not against each other (at least, not exactly) - we have a couple Subversion fans in our own office, for that matter.
But I figured, given Mike's description of how you might do shelving in Subversion, it might be interesting if I highlighted some of the similarities and differences in our approaches, given my perspective on TFS and my somewhat less-informed knowledge of Subversion. I'll state up front that I like our approach better, and I have an obvious bias, but don't let that detract too strongly from my take on how they compare.
To begin with, both of us rely at least partly on convention when it comes to naming shelvesets. I think you need the flexibility, but we've already seen how some processes built around shelving capability might run up against the fact that you can't *know* where a shelveset for a particular bugfix or DCR or whatever lives. We'll always let you look by owner name, and we display the chosen names by owner; Mike's proposal would be at least as capable as long as a path and naming convention was agreed to and adhered to.
The branch/switch approach lets you "edit" shelvesets, something we don't exactly let you do in TFS v1 - at best, you can unshelve a shelveset into a 'clean' workspace, make some changes, and then shelve with replace using the same shelveset name.
I wasn't sure at first if you could unshelve changes shelved by OTHER users with Mike's approach - a big part of the scenarios we considered when spec'ing out shelve for Hatteras. But, after asking a couple guys who are more familiar with Subversion, it's pretty clear that you can. So, no big difference there.
The big difference, to me, is that any user of shelve would have to know a fair amount about branching and merging in order to do shelving the way Mike outlined it. This is not the case for Shelving in Hatteras - it's amazingly simple to use and as soon as the concept 'clicks', people start seeing how handy it is. It's become wildly popular for creating "fix ready" changesets for DCRs, bugs that need approval before checkin, feature work in progress but not ready to be committed, etc. I'm not sure the typical version control user is comfortable enough with branches to deal with many such branches being out there that they might want to interact with, particularly when they may be organized along multiple lines (by user for work in progress, by feature area for DCRs and bug fixes, perhaps). Now, I realize that Subversion and CVS are both more branch- and promotion-oriented than Hatteras to begin with, so maybe that's a stretch.
I'd love to hear what you like and dislike about each approach, and especially about any drawbacks or limits that you'd like to see overcome. There are probably user scenarios we haven't even thought of yet, after all...