Undoig pending changes failed

Oct 30, 2009 at 10:14 PM

Greetings,

I'm running  Buddybuild and I'm getting the following error: undoing pending changes failed (exit code: 100). Changes will need to be undone manually.

Any help/pointer will be very much appriciated

Coordinator
Oct 31, 2009 at 12:20 AM
Edited Oct 31, 2009 at 12:23 AM

This seems to be failure while the build script is trying to remove the temporary changes made to the workspace on the build agent. The buddy build script does this by creating a temporary shelveset that removes all changes from the workspace and packs them into the shelveset. The temporary shelveset is then deleted.

There might be many reasons why the shelving might have failed on the build machine. One reason might be that one of the files that carry pending changes might have got somehow locked in the workspace. The best thing to do is to search in the build log above the place where you saw this message for the following text:

tf.exe" shelve /move /replace

You should see some TFS error message (something that starts with TFnnnnn where nnnnn is the TFS error number). The message might give you a clue about what actually went wrong with the shelving and why it failed.

Hope this helps. Let me know if you can't find anything helpful in the log or if you still have an issue.

-M

Oct 31, 2009 at 12:30 AM

Hi,

Thank you for your prompt reply. Here is what the log says:

Task "CreateProperty"

Done executing task "CreateProperty".

Task "Message"

Using temporary shelveset [BB.01.00.0001.00].

Done executing task "Message".

Task "Exec"

Command:

"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe" shelve /move /replace "BB.01.00.0001.00"

Unable to determine the workspace.

The command ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe" shelve /move /replace "BB.01.00.0001.00"" exited with code 100.

Done executing task "Exec".

It dit create a temporary location but I'm not sure as of how to specify the worspace.

Thans again.

 

Coordinator
Oct 31, 2009 at 1:13 AM

This would happen if the working directory where the tf.exe command is executed is not a location that is mapped within the current workspace.

In the build script, the WorkingDirectory property for the Exec task that runs "tf shelve /move /replace" is set to the value of the $(TfUndoWorkingDirectory) property. This property in turn gets initialized to $(SolutionRoot) if no other value is provided to it by a parent script to override it. If in your case the value of $(SolutionRoot) happens to fall somewhere outside the workspace mapping, then what you can do is set the value of $(TfUndoWorkingDirectory) in your parent script (i.e. TFSBuild.proj) to the root of your workspace. For example:

In TFSBuild.proj:

<PropertyGroup>

  <!-- Add the following property declaration: (you might need a different value though) -->

  <TfUndoWorkingDirectory>$(BuildProjectFolderPath)</TfUndoWorkingDirectory>

...

</PropertyGroup>

Note that the value specified above (i.e. $(BuildProjectFolderPath)) is just an example. You might need to specify a different value depending on your workspace mappings and build script customizations.

Let me know if this does not work.

Nov 3, 2009 at 4:15 PM

Sorry for the late reply. That's right the working directory is not the location that is mapped within the current workspace.

I did change the TfUndoWorkingDirectory but I'm still getting this error. Before I was getting two errors: Unshelving Buddy Build Shelveset failing and Undoing any pending changes was also failing. Now only the first is failing...

Coordinator
Nov 3, 2009 at 6:16 PM

Unfortunately, for the unshelve, the WorkingDirectory is hard-coded to the value of $(SolutionRoot), so you cannot solve this problem by overriding a property in your script. This is a bug as there is a $(TfUnshelveWorkingDirectory) property that should be used there instead of the hard-coded value. I will make the fix so that it is available in the next release (I plan to release by the end of this week).

You will need to set the value explicitly in the BuddyBuildExtensions.targets file itself. This is where you need to make the change (starting at line #298). The red bold text shows the new value replacing the old value of $(SolutionRoot).

<ExecMulti Command="$(TfCommand)"
          ArgumentsTemplate=" unshelve {0} /recursive /noprompt"
          WorkingDirectory="$(TfUnshelveWorkingDirectory)"
          ParametersList="$(ShelvesetList)"
          Delimiter="|"
          IgnoreExitCode="true">
            <Output PropertyName="UnshelveExitCode"
              TaskParameter="ExitCode" />
</ExecMulti>

Next, you will need to assign a value to $(TfUnshelveWorkingDirectory) the same way you did for $(TfUndoWorkingDirectory). Also, if you plan to use the tool to automatically check in the changes for you after a buddy build succeeds, then you will also need to assign the working directory value to $(TfCheckInWorkingDirectory).

Thanks for pointing out this bug and hope this workaround helps get you get past the issue.

Nov 3, 2009 at 7:10 PM

Great! Thanks for the pointer. Editing the BuddyBuildExtensions.targets file did it. That error ("unable to determine workspace" is resolved.  However I'm getting the following error:

The item $/XYZ/<path>/filename.ext already has pending changes.

for all the files in the shelvesets.

The other question I have is more generic.  For the previous fix, does that imply that members of a team have to have the same mapping for their current  workspace for the buddybuild to work?

Coordinator
Nov 3, 2009 at 8:06 PM

The error you are getting is probably due to the fact that the shelveset was successfully unshelved at some point and the cleanup failed. Are you performing incremental gets for your team builds? If you have IncrementalGet set to false (the default), Team Build will always recreate the workspace on the build agent, thus removing any pending changes that were left over from a prior build. However, with IncrementalGet set to true, no cleanup of the workspace is performed and pending changes from prior builds remain there until cleaned up properly.

Rather than turn off Incremental Gets, I suggest that you queue a buddy build against a file that was not part of the prior buddy build's shelveset(s) and let it go through. If all goes well, it will clean up the workspace from pending changes when done. This way you would get a clean workspace on the next build / buddy build.

Team members do not have to have the exact same mapping on their workspaces as the build definition, but if you are to buddy build any changes, the contents of the buddy build shelveset should be files that when unshelved will fall within the build definition's mappings. You can find out the mappings of the build definition against which you are queuing buddy builds and make sure that your workspace has the folders marked "Active" mapped. Also, make sure that you are not queuing changes that would fall under "cloaked" folders within the build definition.

Hope that helps clarify things. Let me know if you have any further questions or if you are still getting buddy build failures.