Skip to main content

Rollback a Ooops in TFS with TFPT Rollback

Rhut roe, Raggie. You just checked in a merge operation affecting 100's of files in TFS against the wrong branch. Ooops. Well, you can simply roll it back, right? Select the folder in Source Control Explorer and...hey, where's the Rollback?
Rollback isn't supported in TFS natively. However, it is supported within the Power Tools leveraging the command-line TFPT.exe utility. It's fairly straightforward to revert back to a previous version--with one caveot.
First, download and install the Team Foundation Power Tools 2008 on your workstation. Before proceeding, let's create a workspace dedicated to the rollback. To "true up" the workspace, the rollback operation will peform a Get Latest for every file in your current workspace. This can consume hours (and many GB) with a broad workspace mapping. To work around this, I create a temporary workspace targeted at just the area of source I need to roll back. So let's drill down on our scenario...
I'm working on Program.cs and I accidentally check in a change I shouldn't have. Oops.

Let's create a workspace mapped just to the folder housing Program.cs so we avoid a massive, entire workspace "Get" during the rollback operation.

Afterwards, select that workspace and perform a Get Latest (just to establish the file system directory). Open up a Visual Studio 2008 command prompt and browse to the workspace on the file system.
To perform a rollback, you can target a changeset or a filespec. I prefer the specificity of the changeset but whatever works for you. You also have flexibility with merge and recursive behavior. Here's the full write-up on MSDN for Rollback. Alternatively, just type in a

TFPT rollback /?

Executing the TFPT rollback command (with the /changeset option in this example), will earn you a prompt to get the latest. Go ahead and click Yes.

Important to note here with the changeset option: you want to identify the changeset one prior to the version you wish to rollback to. So, if I want to rollback to changetset 227, I want to use changeset 228 in the TFPT operation.

Next, you'll be presented with all the assets (files) in that folder involved in that particular changeset (228 in this case). We only want to roll back Program.cs so we'll only select that file. If you Ctrl-A and uncheck one box, it will uncheck them all. Click Rollback.

Next, you'll receive feedback at the command line about the operation. But wait, you're not finished! Rollback is a local operation. You still need to check in your change. This is a great "safety" if you messed up the rollback itself. Just Undo Pending Changes.
Ok, so we're ready to check in our changes.

Looking at View History once more, note we actually have a third version and changeset now: 229. But, we've indeed returned to the original (the first, changeset 227) version of the source.

Being back to square one never felt so good...


Rob Streno said…
Hmmm. Wouldn't it be great if someone created a nice PowerShell script to do this?
Ricardo Wilkins said…
Re: your comment about choosing "the one prior to the version you want to rollback to..." - would you agree that rollback is not just important for moving the codebase back to a previous state, but is also important when an 'undo' of a feature or change to the code is necessary? Thus, that could mean a rollback of a small changeset that was checked in 3 weeks ago, for example. Of course, testing now becomes more important. Would you agree, or is this bad practice?
Jeff Hunsaker said…
@Ricardo Maybe I'm old school but if I were removing functionality, I would want to create a new work item and merge that removal into the history. Probably more CYA than anything but it's a data point which would be shoved under the rug if we did a rollback. I'd want to be able to log/audit this feature removal b/c "Well, Ms. Sponsor, we're 2 weeks late b/c we were asked to add and remove this feature 4 times. See here on this report...? It shows Mr. Product Owner approving this work item and re-opening it 4 times." Also, what about functionality added in those past three weeks?
Ricardo Wilkins said…
the first CYA moment happens automatically - the rollback itself is a check-in/changeset; it's now part of version history. CYA #2: add a comment to the rollback check-in. CYA #3: associate the check-in with the work item you created the moment they asked you to remove the feature. Regarding functionality added since that rollback moment... that's the part where you have to cross your fingers. :) But my experience w/ this feature-rollback scenario so far has been [suprisingly] successful.
Jeff Hunsaker said…
@Ricardo Ok, uncle! Good points. I'd still be careful about wacking modifications made between the original and the rollback. Developers are sneaky. :)
Anonymous said…
Interesting. Of course TFPT just wraps TF and TF is just a command line for doing what you can do in the VS GUI. And, underneath the covers, they're doing the same thing we do now:

Check out; get a specific version of the branch that you want to roll back, undoing local changes when prompted. This checks it all in to the version to which you rolled back.

I thought the instructions he had were longer and more confusing than just doing it the original way.
Michael said…
what if I have the following changesets:
was not my project (4)

and I realize that I need to roll back to 2.

Do I issue tfpt rollback /changeset:3 or do issue individual commands (one for each of my changeset numbers (6, 5, 3)?
Jeff Hunsaker said…
@Michael You simply want to issue the rollback ... :3. It doesn't matter who committed the previous versions. Note however, the changes committed by others in v4 will be removed as well.
der Nico said…
I assume the merge candidates already processed before the rollback will be lost after the rollback. Or will I see them again?
Jeff Hunsaker said…
@Nadine I would assume so but before attempting the rollback, I would clear out your workspace of any merges, edits, check-outs, etc.

Popular posts from this blog

Get Your Team Foundation Server Hate On!

[Google ranking skyrockets... ;-)] I'm a big fan of TFS/VSTS. However, there are a good pocket of folks who take issue with the way TFS handles or implements a certain feature. Well this is your chance to vent! I'm planning a presentation around the "Top 10 TFS/VSTS Hates and How to Alleviate Them"...or something along those lines. But I need your help. Post a comment below detailing your dislike. If it's legitimate, I'll highlight it in the presentation and [hopefully] provide an alternative, resolution, or work-around. Thanks in advance! Update 7/19/2008: Version Control and Microsoft

Installing the .Net Framework 3.0 SP1 on Windows 2003 Server

I'm building an [automated] build server requiring the .Net 2.0 and 3.0 runtime. Unfortunately, at my client, they leverage a proxy server. The standard .Net 3.0 SP1 framework redist is really just a bootstrapper. Logged in as a local admin on the box, I didn't have the opportunity to authenticate the installation EXE with my domain credentials. So, the install kept timing out. Finally, I found this helpful post from Aaron Ruckman on how to download the very elusive, full framework package. It's here , BTW (x86). I finally get the full installation EXE downloaded to a fileshare, re-run the install and wham--" XPSEPSC: XPS must be installed..." Excuse you? This isn't an XPS's a VM. I found a few MSDN posts here and here outlining the problem. I'm still not clear on what XPSEPSC does (Google yielded little) but you can download it here (x86) . After installing XPSEPSC, the framework installed without issue. Update : Somewhat related, there i