none
TFS2010 Build fails because unshelve fails to remove deleted directories with a merge shelveset

    Question

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

    Steps to reproduce:

    1. Create a main folder and branch it to main-branch
    2. In main create test00\test00sub\test00sub.csproj
    3. In main create test00\test00sub\test00sub.cs
    4. Check in changes
    5. Merge main to main-branch and check in
    6. In main delete test00\test00sub (and thereby all files under it)
    7. Check in changes
    8. Merge main to main-branch and check in
    9. In main rename test00 to test01
    10. Check in changes
    11. Merge main to main-branch without checking in
    12. Shelve pending merge changes
    13. Unshelve in clean main-branch workspace
    14. Observe test00sub failing deletion and test00sub with files are present in workspace

    I have found this post mentioning the warning. But the reply by Richard Berg just mentions that it is a warning due to files not being under version control. 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.

    If this is indeed a bug within unshelve, is it possible to get a hotfix for it?

    Best regards,
    Rasmus Sigsgaard



    Thursday, June 13, 2013 2:16 PM

Answers

All replies

  • Hi Rasmus, 

    Thanks for your post.

    In step 13, to unshelve in clean main-branch workspace,  this mean create a new clean workspace on the same machine, or perform the unshelve on another machine?

    Your VS is VS 2010?

    I suggest you upgrade your TFS 2010 and VS 2010 to TFS 2010 SP1 and VS 2010 SP1 separately. 

    If you will no longer to use that deleted folder/files, I suggest you to destroy it.


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, June 14, 2013 8:25 AM
  • In step 13, to unshelve in clean main-branch workspace,  this mean create a new clean workspace on the same machine, or perform the unshelve on another machine?

    In my test I used the same workspace, but made sure to undo any pending changes. I expect the result to be the same regardless which workspace you use, as long as it has no pending changes.

    Your VS is VS 2010?

    I suggest you upgrade your TFS 2010 and VS 2010 to TFS 2010 SP1 and VS 2010 SP1 separately. 

    Both VS and TFS is 2010 latest SP1.

    Version information:

    VS2010 Professional Version 10.0.40219.1 SP1Rel

    TFS 10.0.40219.1 (SP1 KB2182621)

    If you will no longer to use that deleted folder/files, I suggest you to destroy it.

    This is not an option. Besides the fact that destroy will make it impossible to undelete, we will most likely get into a situation where someone renames a directory which contains a deleted directory in the future. And then we will be in the same situation again.

    In my opinion, destroy should never be necessary for normal version control operation.

    As I wrote, this is the second time we've hit this problem, so it will most likely not be the last.

    Friday, June 14, 2013 10:16 AM
  • Hi Rasumus, 

    Thanks for your reply.

    I reproduced this scenario in my VS 2010/TFS 2010, and received the same result. For this scenario, please submit it to Microsoft Connect Feedback portal at: https://connect.microsoft.com/VisualStudio. Microsoft engineers will evaluate them seriously. 


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, June 17, 2013 7:07 AM
  • Monday, June 17, 2013 1:55 PM