1
votes

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

3
Could you more precisely explain what you did? Did you use the command line svn client (if yes, what commands) or a special svn gui client? It's hard to imagine, what you've done.Michael
I'm using Tortoise. I'm still confused on this. I think I'm doing it right but not sure. I right-clicked those files in my latest commit and did a revert back to revision. It seemed to replace those files locally with the code in the previous revision, the revision before mine that had the latest changes for those files.PositiveGuy
Michael Hackner's description is a step by step guide; just follow it and you'll be done. It seems to me that you don't really understand how SVN works (as Michael said, wording in SVN is somehow misleading)... I'd suggest you to read the SVN book -- whole, not only one section.liori

3 Answers

1
votes

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

How to remove 1 revision of a folder in Subversion

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.

2
votes

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.

2
votes

coffeeaddict—

revert and update are both misleading terms here. You are doing neither of these. You are "reverse merging" changes.

You can think of a reverse merge as doing the opposite change...so if a revision added a line to a file, reverse merging that change will delete that line from the file.

In TortoiseSVN, the way you do it is:

  1. Start with your updated working copy
  2. Pull up the log
  3. Click the revision that contains the changes you want to roll back
  4. Right-click a file you want to roll back and select “Revert changes from this revision”
  5. Repeat step 4 for each file to roll back
  6. You will see that this resulted in local modifications to those files in your working copy. This is what you want; it’s just as if you undid the changes by manually editing the files. But you won’t lose any changes from revisions that happened after the one you’re rolling back.
  7. Resolve any conflicts that arose
  8. Commit

Now you have undone only the changes that took place in that one revision, without throwing away any changes since then that you want to keep.