TFS2010 Build fails because unshelve fails to remove deleted directories with a merge shelveset - by Rasmus Sigsgaard

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 790299 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 6/17/2013 2:18:21 AM
Access Restriction Public


This issue concerns TFS 2010 SP1, and not 2012 as I can select under the version drop down.

Error reproduced here, and told to post on connect:

When we merge changes between branches, we verify that it builds by creating a shelveset of all merge pending changes, and running a validate shelveset build on a build server.

For the second time we have now run into a situation where we have build failures, which have proven to be caused by unshelve failing (silently). The build failure is due to old deleted projects being "resurrected" and built.

Our build automatically creates a solution with all projects found in all directories. And since unshelving brings the workspace into a state where deleted projects are "resurrected", these projects are built and causes errors.

The only indication is from the revert workspace activity in the build which lists the following type of warnings:

C:\Builds\42\Sources\code\aa\bb\cc cannot be deleted because it is not empty. 

I can get the same messages when calling tf.exe unshelve shelveset in a clean workspace.

Follow steps to reproduce.

The files in test00sub might not be under version control, but since I started with a clean workspace, it should be unshelve's job to clean them up.

This seems like a bug with unshelve. And since this happens in the SyncWorkspace activity during a build, I can't figure out how I would be able to make any kind of workaround.

Is it possible to get a hotfix for this issue?
Sign in to post a comment.
Posted by Justin [MSFT] on 6/25/2013 at 1:42 PM
We were not able to repro this in VS 2012 or later. We believe it is fixed.
Posted by Macy [MSFT] on 6/19/2013 at 2:50 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Macy [MSFT] on 6/17/2013 at 2:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(