views:

159

answers:

3

I am using Tortoise SVN.

I had checked in a crapload of code recently (one commit). In a 3 hour meeting they decided to scrap a bunch of my code and that feature. My boss wants me to put Subversion back in place with the old code for that area of the application.

I'd say there were about 3-4 files affected. Meaing in that last commit where I had commited the new feature changs, I'll need to roll those files back to the state they were in before I had checked them in.

So, I'm not really understanding what Revert Back to Revision does. I went ahead and found the most recent version of those files in past commits in the log and right clicked those files in the log and did that revert back to revision.

Now does this replace my local copy completely with the older version? Did I do this right if I wanted to only turn back a subset of the functionality I checked in last?

So do I lose all the changes once I revert on my local version of that file? It looks like it merges the older with my local which has newer code...um, not exactly what I expected.

(yes I read the page on it from subversion's docs and it's not very clear or thorough on what it means outside of the technical way they briefly put it which is at a very top level and skips the underpinnings of what actually happens locally in your working copy)

So lets sum up what I did:

  1. I checked in a bunch of changes at one point.
  2. collegue gets that update via an svn update
  3. We have a meeting, boss says we're ripping out that feature
  4. That feature was around 3-4 files of the list of files that were committed in that revision
  5. I want to put those specific files in a state where they were before...some will have be be reverted to Revision x some to y, etc. because the last changes to some of those files were done at different revision numbers.
  6. So I start with the log. I look for the first file. Lets call it somefile1.aspx. I find that the latest of that file was checked in at Revision X. So I right click it in that revision's change set and do a Revert Back to Revision
  7. I notice that it seemd to actually merge that revision's code with my local copy?? I think...not sure that's why I'm posing because eI don't understand this.
  8. I do the same for 3 more files...look for the last time they were commited and right click them in the specific revision and do a revert back to revision on them...assuming that this will put my local version in that state as well and pretty much wipe out even my changes also for that file locally

but I'm a little shaky and confused on all this. If I'm approaching this right and if I should be using revert back and what the heck it's actually doing under the covers. I see it's done a merge but what?? I just want to put back those 4 specific files back to a previous state..not that entire commit that I had just commited that I am mentioning in the beginning here...just specific files related to as specific area of code..the rest can stay commited and be downloaded by anyone else.strong text

+1  A: 

You might be interested in my answer to an extremely similar question a while ago:

http://stackoverflow.com/questions/1409407/how-to-remove-1-revision-of-a-folder-in-subversion/1409409#1409409

Basically, your best plan of action is probably to re-check out the code at the previous revision, and then commit that code as the latest revision.

If you're finding that it's merging the old copy with the version that's on your disk, the best way to fix that is to delete your local copy, and then check out the specified revision of the file cleanly. Once you've got it, you can re-commit it.

Paul McMillan
am I screwed now that I've done a few revert from revisions on several revision files? It did some sort of merge locally which scares the hell out of me.
CoffeeAddict
his is different. He's wanting to revert back an ENTIRE revision. I only want to revert back a few files of a latest revision of mine that I commmited.
CoffeeAddict
If I re-check out the code, then I'm screwed. I can no longer use the existing working copy that might have newer changes.
CoffeeAddict
That was the point. Remove the 4 files you've screwed up from the disk, and re-check them out. You'll lose progress on them between now and whenever it was that you last checked in. Next time, commit more often, and make a tag or branch if you can't break the build.
Paul McMillan
+2  A: 

Assuming that you want to revert the changes you made in revision 1234: just merge the differences from 1234 to 1234-1.

In CLI this would be: svn merge -r 1234:1233 http://your-repo/ && svn ci

In TortoiseSVN, get a merge dialog box, "Merge a range of revisions", enter 1234 as revision to merge and click "Reverse merge". Then check if you didn't get any conflicts (with changes other people did after 1234), and make a check in. Then your HEAD revision won't have that code.

I am not sure if you can do that on specific files in TortoiseSVN. I did that in CLI, and you can try too (CLI tool, TortoiseSVN, AnkhSVN, they all share metadata).

The SVN will still remember that you have wrote this code, and this is what it is designed for. If there are no real reasons to remove this code from SVN (like, legal or blackmail or whatever), keep it.

liori
I just showed log and then in my latest revision, right clicked those files and did a revert changes from this revision. I guess it looks like it replaced it with the last checked in version of that file...or so it seems
CoffeeAddict
liori
+1  A: 
Michael Hackner