Sometimes you'll find yourself in a situation where you need to revert back to a previous version of a file, stored on the Subversion/SVN server. Maybe you made some changes that didn't work, maybe you need to test an older version of code, or maybe you just want to look at a copy of the project from a specific point in time. Whatever the reason, this video will talk about how to roll back changes and switch to earlier versions of files using Eclipse.
- So far in this chapter we've talked about seeing what changed in your project, what changed between versions of a file, and how to deal with conflicts. One last thing you might want to do along these lines is go back in time and revert your changes to a previous version. This might be the case if you made some changes that just don't work, or you need to troubleshoot an old piece of code or maybe your cat sits on your keyboard and destroys a file. Whatever the case, in this section we'll talk about reverting changes to a file. The first scenario we'll talk about is reverting to a local copy of a file you haven't even committed yet.
So let's say you made some changes to the jelly donut file an hour or so ago and everything worked pretty well but then you made a few more changes but you broke something, and unfortunately you didn't make a commit between the time you had a good copy and when you broke it. And that happens. Eclipse has a nice feature called local history that keeps track of all your local file changes for a short amount of time. By default, this is the last seven days of changes and only up to about a megabyte of file storage so it won't save everything you've ever done but it's really nice in a few specific situations.
This means you might be able to get your good local copy back. So first let's simulate a cat sitting on the keyboard. I'll open the jelly donut file and... Awww cat nap! Cancel Okay so the cat laid on my keyboard, I put my hand down, I have a lot of characters and let's say the file accidentally got saved. So if I want to see the older local copies that I have of this file, right click the file, and choose replace with local history.
This gives us a window that's going to act very similar to what we saw in the previous section when we talked about file merges and file divs. It will give us a comparison of the file as it is now and the file as it was previously. It has a list of local revisions at the top and these all correspond to times of days I saved the file locally. If you choose a time in the list at the top left the comparison window underneath gets updated with information about the difference between the file at that specific time over on the right and the file as it is now over on the left.
If you find an older version of the file you want to switch back to, just select it in the list at the top here and click the replace button down at the bottom. Now we're back to a slightly older version of the file. I will point out that the changes you see here won't correspond to the changes on your local machine. You might not have any local changes at all. That's fine this was just an example. Another scenario is you made an SVN update to your project and that pulled down a change to the file that you don't want yet. So let's say that this copy of the jelly donut file got pulled down from our last update but we don't like some of these changes and so we want to go back to a previous version on the server.
Right click the file and choose replace with, revision or URL. This bring up a dialogue where you can choose where to get the file from and which revision to use. Interestingly, you can even choose a revision of the file from a completely different branch. I'm not going to do that here, I'm just going to pull it straight from trunk but I don't want the head revision so I'll click revision and then click the browse button and this gives us a list of all the revisions in the branch where this file was changed.
I'll choose the previous revision of the file at revision tab. Look okay? And revision ten is now entered in this box. Like the other examples in this course the revision numbers here might not match up to the revision numbers on your local machine. That's fine just pick the revision number that makes sense for what you see. I have revision ten and I'm going to click okay. And it asks if I'm sure I want to do this, yes. If I look at the file again, I'll open it up here I can see the file contents been reset to the older versions so I don't have this toppings multiplier and the set toppings multiplier method at the bottom.
What's interesting though is that file on the left hand side in package explorer, that still has the right angle bracket next to it and it still shows it's a revision 28 even though we chose revision ten. That means SVN still considers this to be a changed file and the next time we do a commit we'll be sending this file up as a change. Even though we replaced it with an older copy, SVN considers this to be a change. So first you need to do a revert. In SVN terms reverting a file tells SVN that all of our local changes will be erased and replaced with a last known version of the file in our working copy.
Right click the file, choose team, revert. This doesn't really give us any options about which version to revert to, it's always going to be the most recent local version, but Eclipse does ask if we're sure we want to do this. We say okay, and then we're back to the file as it was when we made the update. Private int toppings multiplier and the set toppings multiplier method are back. Back in package explorer the right angle bracket next to jelly donut that indicates the file has been changed, that's gone.
So SVN no longer considers this to be a changed file. However the revision number is back at 28. That's the revision we pulled down when we did our last update, so version reverted to that because it's the most recent version we got from the server. We don't want that we want the revision before that. However we had to do the steps so SVN doesn't think there are pending changes to this file, we wanted to get rid of that right angle bracket. After we've done a revert that angle bracket next to the file name is gone, so we can go back to our previous version of the file with an update. Right click the file again and choose team, Update to revision.
So this gives us a dialogue where we can choose which revision we want to update to. Now the term update is a little deceiving here because update makes you think that you have to go to a newer version of the file. That's not true we can actually go back in time too. If you click revision here and then the browse button this brings up a history dialogue that shows us the last revisions for this file. Choose the revision we want to go back to in this case I'll choose revision ten, and click okay. Now the number ten is revealed here in the revision box and I can click okay to finish.
In package explorer, the right angle bracket is still gone so SVN won't try to send this file with an x commit and the file is also back to revision ten not 28 like before. If you look at the file contents you can see the file contents have also been reset. So in summary, if you just want a different copy of the file and you aren't worry about what happens on your next commit to the server, the easy way to switch copies of a file is with a team replace with menu option. If you want to go back to a clean copy of your file and reset all the local SVN change flags then you need to do a team revert followed by a team update to revision.
The end result of both cases is the same but SVN treats them both slightly differently on your next commit. I'll also point out you can do this on an entire project too not just a single file. So if you want to revert your whole project back to a previous version, follow these same steps but right click the project itself instead of just a single file in the project.
- Trunks, tags, and branches
- Checkout, commits, and revisions
- Merging, locking, and working with a team
- TortoiseSVN on Windows
- SVN integration with Eclipse
- Connecting to a project
- Creating a new Java project in Eclipse
- Connecting to an existing Java project using Eclipse
- Dealing with projects that move to a new location
- Making changes and creating branches
- Tracking changes and dealing with conflicts
- Creating a release