Hi,
It is 2018 now.
Very disappointing this request wasn't handled and barely got a response.
Shelving is a basic source control operation and lack of it make DB developers and code reviewers collaboration harder.

Here is how we plan to handle Shelve Sets (and other Long-Running projects):
Example: Long running project, where we:
1. Create a Dedicated DB called Integration_LongRunningBranch_PBI2891,
2. Create a TFS branch called “Integration_LongRunningBranch_PBI2891”:

Advantage:
- Can Commit changes to TFS to save the changes we make.
Disadvantage:
- Only long running project changes make it to TFS (we see no conflicts because no one else is committing to this TFS Branch)

Once all changes are made and all commits are complete, unlink and relink to TFS Branch “Main”:
- “Linking” does a Get Latest to “Working Folder”
- “Get Latest” does a Get Latest to “Transient Folder”, a copy of what’s currently in TFS
- “Working Folder” and “Transient Folder” at this moment are identical
- If a SQL Object has changed in TFS, and you also changed it in your DB, you will see the change as a “Conflict”. If you want to see who made the change(s), you can look at TFS History on the object.
- If you have changed a SQL Object only in your DB, you will see it as a “Edit”.

Advantage:
- You can resolve Merge Conflicts on long running projects
Disadvantage:
- You will have to resolve all Merge Conflicts before you can commit to the TFS “Integration” branch
- You may have to migrate all differences and run tests.

As Martin said, this would come in very handy for code reviews (note there is another request specifically regarding code reviews which could possibly be combined with this one: https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/4260600-i-want-to-be-able-to-list-a-code-reviewer-when-i-c )

As an example, Visual Studio 2015 does a nice implementation of this where you have the option either to "check in" changes or "request code review". Requesting a code review shelves the changes and notifies the specified user, who does the actual commit.

Forgive me, but it you haven't looked into this in over four years, it seems to me that maybe you're not all that interested in pursuing it... Let me tell you why you have now suspended development for the rest of the day...

Unfortunately, one of my fellow developers on the team is off work sick today, but still trying to contribute by working remotely. We are each tasked with working on a very complicated problem on two similar but not identical databases. The issue is very complicated, and requires changes to three stored procs and four views, and I want to show my solution to the other developer.

I'm not about to do this manually - partly because I'm lazy, and partly because there is always the chance for human error to creep in. So - I want to share a set of changes, without actually checking them into the repository - why the VERY DEFINITION of a shelveset...

Please, get this stuff supported for TFS. It's not that hard (I have used the TFS API on other projects).

Hi everyone. Sorry for not having updated the status on this one for so long. As you probably guessed, this isn't something we've yet been able to look into. The latest comment that Mitch posted did suggest a possible option though, specifically "maybe if we just had the ability to apply the current changes to the DB scrips in our local workspace, then we could shelve through TFS explorer ourselves"

SQL Source Control has the ability to link to what we call "Working Folder". This is another option on the link dialog instead of picking the TFS one. This option will let you simply read/write to a folder on your disk, which can of course be a folder checked out from TFS via Team Explorer. Although this has the downside of turning commits and retrieves into a two-step operation (you'd commit in SSMS to the folder, then use Team Explorer to commit to TFS itself, and vice-versa), it should enable you to utilise features of TFS which we don't currently support.

I realise that's not a full solution to the problem, but it may help in some instances. Please do keep voting for this if it's important to you- we do look at Uservoice as one source of work to do however there are many other inputs to the process both internally and externally that all need to be juggled.

Not that I expect it'll make a difference after 4 years, but +1 on this.

We are currently using a 2 branch approach to deal with this. During initial development changes are committed to a WIP (work in progress) branch. Then when completed functionality is ready for QA, merge the WIP branch to a Master branch where all the builds are actually delivered from. It works but it's a lot of extra friction that could be eliminated if we could just shelve from SSC.

If the problem is that the shelving concept isn't universal to all source control systems, then maybe if we just had the ability to apply the current changes to the DB scrips in our local workspace, then we could shelve through TFS explorer ourselves. Another dev could then get the shelveset into their local workspace, but I guess you'd still need a way to apply the changes to the other dev's DB from the local scripts instead of directly from source control.

Still, the idea of SSC working with the local workspace instead of directly with the source control repository could open up a whole host of other possibilities for end-user customization of the process. And also give you indirect support of pretty much any source control system.

Could we get a response as to if this is being investigated? Simply not responding for several years on a 'User Voice' forum doesn't give me much confidence

Any more progress on this issue?

Any more progress on this issue? This is still a major feature that our development team is lacking. If we can shelve SQL changes we can keep a clean Source Control. Branching the Source Control Tree and having multiple version of a development Database per Branch is way too much and shelving gets us around this.

This is a critical feature to our team. We are moving towards a continual integration model, yet still have items that get shelved for future use, and shouldn't be used for committing.

Is there any updates on this being included in Version 4? I see that the Check-In Policy project is coming soon... Now we just need this!

I am trying to take our deployment system to the next step and automate it. It all comes down to not having this feature. I want my developers to only Check in Completed projects. Shelve Sets will be used to check in incomplete projects for Sharing between developers and backup of work in progress. Until we get this, I will be doing manual deployments.

We were looking to buy SQL Source Control from Red Gate, but since it doesn't support shelve sets, we have decided to wait for the new tools for Visual Studio from Microsoft, that should support this feature.

Had SQL Source Control supported shelve sets, then we would have purchase 3 developers toolkit licenses now. Perhaps we may still buy it to get some of the other tools, but for now we will wait and decide what to do.

Shelving is also available with Sourcegear Vault, and as I SGV user, I'd like to suggest this feature as available on the SGV integration as well.

Similar to Karen Wallace and Adam comments, we too would like to have the ability to Shelve changes along with our C-sharp code during a code review instead of having to check it in. Also, since mulitple developers can be potentially touching the same code and scripts. Shelving helps us play nicely until we are ready to check-in. If this product allowed shelving, this would be a slam dunk purchase for us.

I'm looking into this product because we're moving to TFS and the consultants helping us prepare for that recommended it, but the inability to shelve makes it of little use to us. Our shop avoids dependencies between projects that need to modify the same file by shelving changes until a project is ready to go to QC.