0

Checking in shelvesets is a nice feature of the build system in TFS, but the shelveset is deleted after the build finishes. Is there a way to change this behavior so that the shelveset is preserved?

I use the build+check in shelveset feature all the time to check in code from teammates, but sometimes I don't want the original shelveset to be deleted by TFS. In some situations, this can cause problems, like when the shelveset is associated with a code review work item. In that case, all comments from the code review are hidden by Visual Studio because it can't find the associated shelveset.

I searched on the default properties window when queuing the build in Visual Studio but there doesn't seem to exist any option to control this behavior. Will I have to customize the build xaml to change this, or is there a known way without having to get to that?

julealgon
  • 7,072
  • 3
  • 32
  • 77

1 Answers1

1

If you mean build+ check in shelveset is building shelveset and check in the changes after build successful as below:

enter image description here

Then it's impossible. Since you have checked in your shelveset. This is not related to build. So this question is the same as how to check in shelveset and prevent deleting shelvesets. Shelve saving all of the changes on your box without actually checking in. The changes are persisted on the server. So other team members can see the source code and can also check in other's shelvest.

You can also treat is as a kind of container.

  • You create your file and commit it to a shelveset (container A).
  • You then go to the build agent and get that Shelveset into the local workspace (container B)
  • You then commit the shelveset (from container A to source control) the check in from Container A is successful and Container A is deleted to reflect that the Gated Shelveset has completed it's life cycle (if it failed it would remain intact)
PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • That's a bummer... I think TFS should have an option to handle this, same way as you can keep the shelveset on the server when unshelving (by selecting the checkbox for that). I'll have to come up with a way to check in other people's work without interfering with the associated code reviews then. I think asking coworkers to create a copy of the original shelveset and then checking that in is what I'll do from now on. – julealgon Mar 09 '16 at 13:04
  • The reasoning above doesn't make sense. One does not "check in a shelveset." The developer checks in the code in the workspace they are currently in. This may have come from a shelveset, but the shelveset remains and is not connected to the action of checking in. – Shawn South Mar 22 '16 at 23:32
  • @ShawnSouth . Afraid not, maybe my description is not accurate. Have update my answer. You can treat shelveset as a kind of container. You create your file and commit it to a shelveset (container A). •You then go to the build agent and get that Shelveset into the local workspace (container B) •You then commit the shelveset (from container A to source control) the check in from Container A is successful and Container A is deleted to reflect that the Gated Shelveset has completed it's life cycle (if it failed it would remain intact) – PatrickLu-MSFT Mar 23 '16 at 02:19
  • @Patrick-MSFT That is the point I was making, but it turns out you were correct. I just learned this morning that it *is* possible to checkin a shelveset directly using the commandline: http://stackoverflow.com/a/4507264/1058872 – Shawn South Mar 23 '16 at 19:47