How to rollback bad check-in?

Question

How I can rollback files checked in a source control? The only things I found that I can specific version before the bad check-in but when somebody will get latest version he/she will screwed again. And also I have all kind of problems when trying to modify and check-in those files I loaded from previous changesets - Source Control detects that newer version is available in database and offers me to merge the changes. Which I am obviously do not want as newest check-in is a bad one.

How can I remove this bad check-in from the top of the stack?

Answer 1

If it's just 1 file, the simplest way is something like:

tf edit file.txt
tf view file.txt;C100 > file.txt
tf checkin /i

That is, pend an edit on the file, download the version you want to roll back to (changeset 100 in this example), then checkin that old version.

For more complicated rollbacks, I'd let tfpt rollback do the work for you.

Answer 2

Wow... I wouldn't like to have Junior Devs from my team operating all those command lines in a hurry of bug-fixing or pre-deployment.

I hope the rollback feature will be avaiable in next versions...

Answer 3

I don't see why downloading a prior version and using it to submit a bugfix would be considered difficult or unusual. Fixing regressions is a fact of life in software development. Rolling back the most recent changeset is just a special case, and probably not the most frequent one. You can argue that we need a new feature that simplifies this case -- I might even agree -- but I have a hard time believing it's crucial in any way.

Thanks for the feedback, hope this helps.

Answer 4

You can also download the Visual Studio SDK. It contains a Team Foundation Power Toy (TFPT.exe) that supports the rollback command.

the power toys for Team system contain commands that are very usefull but did not make it in the current product. the tool is developed by the TFS team but provided as seperate DL.

You can download the SDK from http://affiliate.vsipmembers.com

You need to register, but it's for free.

Look in the folder: c:\Program files\Visual Studio 2005 SDK\2006.03\VisualStudioTeamSystemIntegration\Utilities\Team Foundation Power Toys\tfpt.exe

There is also a document describing the possible options for rollback, like picking the correct changeset to roll back etc.

The tool supports many other feastures very usefull, like merging of shelvesets, ofline working with TFS, etc.

Answer 5

As I see it - the main advantage of Subversion before the Team System (let's not talk here about the size of installation or administering efforts) is that Subversion doesn't try to think instead of me. Rollback is pretty common requirement and Subversion handles it very well. Of course if VSS or Team System make rollback painfull it won't be natural function for development teams - but the maindset which VSS nurtured for ages in MS developers community is wrong! It was good in 1999 but same approach would suck today. I think that TS shelving is an overweight attempt to replace twisted rollback functionality. Subversion would let me handle 90% of situatios which shelving is intended for with rollback and it will be elegant.

As I said I don't like inexperienced guys playing around power toys but I trust them enough to let them try new things, check them in and rollback if build brakes or for another reason. Much simpler in a process...

I am talking about Subversion that much because for current company I am defending the choice in favor of Team System and I really want it to be better. Version 1 is impressive but not perfect. I think if developers will get more freedom instead of process the tool will be accepted wider.

Answer 6

I think that TS shelving is an overweight attempt to replace twisted rollback functionality.  Subversion would let me handle 90% of situatios which shelving is intended for with rollback and it will be elegant.

Yeah, I'm going to have to completely disagree.  Lowering the bar for checkins might seem easier to an individual developer, but having an unstable tree hurts productivity for everyone.  As teams expand beyond a few people, checking in a regression becomes a bigger & bigger sin.  It doesn't take a very big mistake for QA to come to halt, or worse, the build process to break.  Meanwhile bad code propagates through the system as people sync.  By the time you rollback, dozens or hundreds of workspaces may be affected.  Even if you manage to email everyone to tell them to re-sync after the rollback, that's a lot of wasted time & bandwidth.

Checking in untested code with the assurance that "I can always rollback" is not elegant, it's unprofessional.

Hopefully that's not what you meant :-)

the maindset which VSS nurtured for ages in MS developers community is wrong!

VSS does have a very simple rollback feature.  You can highlight any version in the history dialog, click "Rollback", confirm "Yes," and voila all changes made after that point are deleted.

That sort of feature is very much against the TFS philosophy of atomic checkins and overall change management.  At best a TFS-based rollback should commit new versions equivalent to old ones, never changing the prior changeset which must continue to represent a consistent snapshot of the depot.  That's essentially what tfpt rollback does; if we productize it it'll be better tested & integrated, but will probably be implemented in essentially the same way.

As I said I don't like inexperienced guys playing around power toys

The TFS powertoys are built on the same client OM that tf.exe and Source Control Explorer are.  Unless there's a bug in the OM or the server, there's virtually no chance that a powertoy could corrupt things.

I haven't played with SVN recently but I'd be interested to hear what parts of it you like better than TFS.

Thanks,
-Richard

Answer 7

Checking in untested code with the assurance that "I can always rollback" is not elegant, it's unprofessional.
Hopefully that's not what you meant :-)

Aha! On this case I will have continuous integration on guard (as soon as I will have Team System Build running :). I was talking about rolling back some features which QA or BA didn't like and not just crappy code. Following the Agile concept test and business guys always have access to the latest working build which is automatically compiled and deployed on the test servers. It won't be possible if code which provide the features wasn't checked in (and god forbid us from manual deployments!). Agile says that mistakes are totally acceptable and should be embraced ASAP.

So let's check my scenario: programmers develop feature (fully test it, check it in with full automated uint testing), continuous integration runs it's tricks and deploys the application. Testers/BAs/Customers coming in and saying: "Oh, sorry, that's not what we wanted". And there I would like to have easy and seempless rollback which any available developer can perform.

TFS gives nice picture vs. SVN. So far with small annoyances I matched all SVN functionality I used. I didn't dig deep enough yet but what I would like to see:

Policies.Maybe it's just me but seems like check-in policies should be deployed on the individual machines. That's strange assuming that check-in mechanism and database are out on a server. In SVN I develop policy (hook), deploy it on the server and forget forever. Also - to attach test run to the policy I have to have Test List which is not createable through VSTS Developer Edition! That's pure crazy! (The same thing with Build, when I can't attach tests without lists to the Build). What are those test lists anyway? They should be optional or default test list with all test should be created automatically!
Merge editor. Windows sections should be better synchronized: not just on up/down but also on left/right scrolling. - that's small but annoying thing.

Answer 8

I was mostly confused by the comment about shelvesets. We use
shelvesets for code reviews, buddy builds, and temporary backups. Those
obviously aren’t things a healthy team should replace with checkin +
rollback.

The customer/BA “no, that’s not what we meant” scenario makes a lot more
sense. I do think rollback is useful, I just don’t like the VSS way –
it makes it too easy to permanently erase things. Ideally I’d want to
see a feature that’s just as easy but (a) applies at the changeset level
instead of the file level (b) preserves history.

The other quirks you mentioned are all known pain points. If you can
find them on connect.microsoft.com, add your vote – our PMs do take that
data very seriously. Thanks again for helping us improve a v1 product.

Answer 9

OK, so for your scenario I would use branching+merging+rollbacks - I still not convinced shelving as a required feature - but it's nice to have it anyway.  I would think about it as a my private shareable source control. For the process I replaced buddy and code reviews by paired programming - saves time and preserves morale while gives same code quality.

I am completely agree with your note on changesets instead of files. About history - yes, great to have it but if you overengineer this it will defeat the whole idea of rollbacks. I would say "yes" to restricting rollback by just one level down... It's up do dev team to establish approval process on rollbacks but as soon as rollback is approved - it should be easy to implement. I would prefer Team System cooperate but not dictate my process. MSF for Agile Programming forgot one of core Agile Manifesto postulates - "People and Communication instead of Tools and Process" - give us more space...

Couldn't find anything on connect.microsoft.com - it's too crowded. maybe more structure needed for it.

So there is hope that check-in policies will become easier to manage? Cool! They so usefull, especially for distributed teams.

Answer 10

G'day,

See also the following thread.

Yours truly,

Answer 11

The "tfpt" rollback command is completely useless as far as I'm concerned.  I just tried to use it, and it insists on syncing the ENTIRE WORKSPACE (of which I have a small subset actually present on my machine) before it would do anything.  This in spite of the fact that I had just done a get latest on the entire tree that includes all the files I wanted to revert.

I wanted to roll back a given changeset (a developer checked in some files, forgot a file, and this was breaking builds, the developer left, and so the only option was to rollback the changeset).  So tfpt rollback is utterly useless for a simple act, and the UI is completely painful...

I have no clue why this should be difficult.  I should be able to just right-click, rollback, have it check out, and then check in the change.  it should be a really simple process, not requiring scribbling notes on post-its, looking and searching in different areas, opening command lines, following a completely unintuitive set of steps (get specific version THEN check out?!?)  Ugh.  I want to rip all my hair out every time I need to do a simple rollback of changes... and every time I have to do it, I have to google and 're-learn' how, because it's so completely unintuitive.

PLEASE tell me this is fixed in VS/TFS 2010!  Because the current implementation is, imho, completely and totally broken.  TFPT "Rollback" is NOT the answer.  Why should the entire workspace be synched?  That's beyond ridiculous.  And renders the tool completely and totally useless to our entire organization.  It should be simple, straight forward... get specific version on the files in the specified changeset, check them out (as one atomic step, not as me having to do both), and let me review the changes adn check in.  It should be simple and obvious.

Answer 12

Please don't resurrect threads that have been dead for 3 years (they're probably out of date anyway).  If tfpt rollback seems incomplete to you, well that's why it's a Power Tool.

On the bright side- yes, rollback is now part of tf.exe (no support in IDE yet) in VS 2010 and you do not need to sync the entire workspace anymore.