More on shelving

More on the phantom comments. I missed a couple comments to my shelving post that I want to follow up on.

Keith outlined a basic scenario to help him understand the workflow:

I have checked out a file and made extensive changes then get told to make a simple fix in the file. I'm not ready to check in all those changes. So I shelve the file. Now I'm back at the previous version of the file. I check it out make the fix and check it back in. My boss is happy. Now I want to get back to my other changes, so I unshelve. What happens then? Does the tool want to merge my changes to the file with the version I just checked in with the bug fix?

When you unshelve, it sets the "have" version back to the version your shelved changes were pended against. So, after unshelving (well, anytime before checking in, ultimately), you'd run get, and as you expected, you'll have conflicts with your checked-in changes, just as if someone else had checked in a change since you pended your shelved changes. You'll be prompted to resolve the conflict via the normal means, with the typical version conflict options: automatically if possible, manually, or you can choose to discard either set of changes.

Mickey asks for some examples:

I have not started delving into the source control portion of VSTS yet, but I would love some specific examples, to make sure I understand the concept of shelving, and how it interrelates to source control in general.

Keith's scenario above is actually one common scenario - ongoing work is interrupted by a high-priority but unrelated change to the same item or items. Shelving lets you 'save off' that work in progress and address the interruption safely - you can both make the 'right now' change without worrying about your other changes in progress getting accidentally introduced early, and you can easily get back to that ongoing work once the 'crisis' has been addressed.

Another scenario which has made shelving very popular with our dogfood users has to do with approved checkins. Many of you will be familiar with this scenario - as you approach a release (for example), it's common to enter a phase or 'mode' where a bugfix or change request must go through some sort of elaborate ritual, I mean, approval process, before it can be checked in. The dev may have the fix ready in a matter of minutes or hours, but QA signoff, perf impact, doc impact, loc impact, bugbar check, approval process, etc. may take far longer. The dev can shelve the changes for the change request or bugfix in a clean, ready-to-go state, which makes it easier to safely and reliably make the change once approved. And, as a shelveset, it's actually easier to get through those approval hoops - a buddy build can be done, QA can build and do perf testing, anyone can view the shelved changes, etc., all by accessing the shelveset, rather than tossing around a zip file and an ever-growing email thread, for example. And, the shelveset itself can capture/accumulate most of the data that must accompany such 'formal' checkins - the details of the problem and the solution, the approval/reviewer signoffs, the associated/resolved work items (a bug #, the change request #, whatever your process mandates). Unshelving optionally sets all the metadata so the FULL checkin is ready after unshelving, not just the pending changes.

I hope that helps. As always, feel free to ask additional/followup questions.

When the levee breaks, I'll have no place to stay.
Chris

Comments

• Anonymous
  August 22, 2005
  Launch Tour 2005 Knowledge Center
  
  The launch site for VS2005 and SQL Server 2005
  
  Thom Robbins -...