Team Foundation vs. Subversion: Shelving


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

Comments (5)

  1. Mike Mason says:

    Hi Chris!

    I like the "shelving" concept a lot and it’s great that you’re working on it. My post about whether Subversion supported such a thing was mostly intended to demonstrate that you could achieve the same effect in Subversion, albeit with a few conventions thrown in to make a shelf meaningful.

    The great thing about Subversion is that it provides a decent base for building on, and this is especially true for features like branching and tagging, where directories are really all it provides. Other tools built on top of Subversion, such as TortoiseSVN which integrates with Explorer, can take these conventions and make them concrete in the UI. I can imagine an extension to Tortoise that allowed you to shelve a set of changes, browse other peoples shelved changes, and re-introduce a shelve set to your working copy.

    Overall it’s the concept that I find interesting, and I might well start including a "shelves" directory with my projects in future.

    Thanks for writing an interesting blog, please keep up the good work!

  2. CRathjen says:

    Thanks for the feedback, Mike.

    It’ll be interesting to see if anyone DOES persue one of the approaches you suggested once Team System becomes available and people starting using shelving.

    I know from our dogfood deployment that shelving has become a very popular way to streamline some of our development workflow…wait, that came out sounding WAY WAY too buzzword-compliant. Let me try again.

    I know from our dogfood deployment that shelving has made our devs and testers more productive, because it makes managing changes that can’t be checked in yet less painful. For any coder who has to work within the constraints of any kind of process (and I imagine that’s nearly anyone with a team above about 3 people), anything that makes process take less time and effort is something to celebrate.

  3. Visual Studio Team System

    Today, we have a double-header of Team System webcasts:

    9:00 AM PDT –…

Skip to main content