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

Comments

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:
6
5
was not my project (4)
3
2
1

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

TFS Reports Out of Date

You may have noticed it takes a while for Team Foundation Server (TFS) reports to reflect changes you've made to work items or builds. Let me guess...about an hour, right? Out of the box, TFS is set to refresh the data warehouse from its transactional store every 60 minutes. How do I change the frequency of the data warehouse refresh? Browse to the TFS Controller Web Service on your TFS application tier server within IE at: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx Select the ChangeSetting option Enter RunIntervalSeconds for the settingId and the desired number of seconds for newValue (300 for 5 minutes...5*60) Select Invoke How do I force a data warehouse refresh? Two methods here: either via the above web service or using SQL Server Management Studio. Via the web service: Browse to the TFS Controller Web Service within IE at: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx Select the Run option Click Invo...

Certified or Certifiable?

As a senior technology professional, I interview a lot of candidates. I also maintain solid relationships with other folks in the community. Frequently, the topic of certifications arises: A good investment? Valuable? A clear measurement of skill? Consensus appears to draw the line related to one's seniority. If you're (for example) just out of school and looking for an instant creditability boost, by all means pursue a certification. Likely, this credential will assist you in overcoming the "junior" tag and likely land you more interviews and client roles. (Note: I'm going to use the terms senior and junior here...no offense to either. Can't think of a better one word description. I was a junior once too.) In stark contrast, the value of certifications drops off the table around the 2-3 year mark. Some in my circles even perceive certifications as a negative for the senior professional. They think, "If this guy is so solid, why is he wasting valuable...