It's often very useful to see exactly what changed in your code between two different versions of a file, either based on changes you've made locally, or changes between two completely different revisions on the Subversion server. This video talks about how to use the visual diff tool and SVN history in Eclipse to look at changes between file versions.
- [Instructor] Version control systems are great for managing your code, even if you're not working with a team. If you're a solo developer, and you're the only one working on a project, a version control system still gives you some great tools to see what's changing your code and when it changed. In this section, we'll talk about using a Eclipse to see the history of your project and what changed in a file from one revision to the next. We've already created an Eclipse project and connected that project to a subversion repository. We'll be starting from that point. So, if you don't already have an Eclipse project that's connected to your subversion server, please review chapter three to see how to check out a project from SVN.
In this case, we're starting from the project in the state it was in at the end of chapter four. To see your project history, you simply need to right-click your project in Eclipse Package Explorer and choose the Team, Show History menu item. I'll expand that so we can it a little better. This opens a history view that displays a list of all the revisions in the repository that are related to the branch you're currently working in. Keep in mind that trunk is really another kind of branch. So, since you're in trunk right now, this shows you all the revisions in trunk.
One think you might notice right away is that the revision numbers on my screen might be different from the revision numbers you see on your screen. This is because each SVN server has its own set of numbers, depending on how many commits you've made and where you made them. Also, there are gaps in the revision numbers. This is for a couple of different reasons. First, the revision numbers are incremented across the entire repository every time any project in that repository is changed. So, some of those missing revision numbers might be changes to other projects that have nothing to do with us.
Second, this view only shows you the revisions that have to do with the history of this particular branch. Some of the revisions might have been in other branches that aren't directly connected to this history of this specific branch. So, we could be missing revision numbers from other branches of this project, too. In any case, if you click revision number to select it, you can see the commit comments for that revision in the center of the view, and you can also see a list of all the files that were changed with that commit at the bottom of the view. You'll also notice that the revision at the very top has an asterisk next to it and is in boldface type.
This means it's revision we're currently working on. It's at the top in this case because no one has made a revision to this branch since the last time we did an update or a commit. But, if someone else has made a change to the branch recently, there might be other revision numbers above our working copy revision. I'll close that and show you another way you can see history by using the revision graph. In Package Explorer, right-click the project again and choose Team, Show Revision Graph.
I'll choose the default options for From and To. This gives me all the revisions from the start of the project until now. And I'll also click the Show nodes for all revisions box. Click OK, and you'll get a view like this. Branch creations are green boxes. If there were any deletes, those would be in red boxes, and normal edits and changes are gray. A branch that was made off of this branch, in this case, branches that were made off of trunk, have a connector and are over to the right. If you hover over a box, it gives you information about what change was that particular revision.
The history view we saw before is probably easier to look at if you're only concerned with what change with each revision, but this kind of diagram gives you a good sense of how and where the branches happened, especially on larger, older projects with a lot of revisions. Another thing that might be useful with the revision graph is this: if you right-click any of the revision boxes and choose Show History, it will give you a history view. I'll expand this just a little so we can see it better. And this history view has everything from this specific revision backwards.
That's nice sometimes because if there's a lot of branching, and you need to see what change in a particular revision of a branch, this is how you can go straight to that revision. Now, I'll close all this. And, that's looking at things from a high level view of the entire project. What I actually find most useful in the Eclipse integration, and in fact, this is something I use more than any other feature, is the ability to see what changed in a specific file. So, here in our code, I'm going to make a change to the JellyDonut class.
Double-click and open that, and first, I'll add a new variable to the top. Now, I'll call it private int toppingsMultiplier, and I'll have that equal to one. I'm going to save, and then I'll add a setter for that, public void setToppingsMultiplier int multiplier, and this dot toppingsMultipler equals multiplier.
Okay. I will save that again. And then, finally, here in the addToppings method, And I'll change that so the toppings is five times the toppingsMultiplier. There, okay, File, Save. So, I've made some changes, I've saved them. And you can see that there's a small right angle bracket next to the JellyDonut dot java file name in Package Explorer.
This indicates that we've change the file since our last commit. If I want to see exactly what I've change in that file before I commit my changes, that's really easy to do. Right-click the file and choose Compare With, Base from Working Copy. I'll expand this view, and this shows us a really nice view of what changed between the version of the file that's in the working directory, that's the file we've changed, over here on the left, and the original file that we originally pulled down from the repository on the right.
All the sections that were added or modified are highlighted in gray. Here, you can see I added the toppingsMultiplier variable at the top, and I also created the setToppingsMultiplier method, and I modified the addToppings method. The small lines in the middle connect all the changed sections on the left and the right. As we scroll up and down, we can see how the line numbers between the two versions of the file stay in sync. So, that's pretty cool and pretty useful. In the top section of the view, there's also a summary list of all the code sections that got changed: ToppingsMultiplier, addToppings and setToppingsMultiplier.
If you want zoom in on just one of those changed sections, you can double-click the list item at the top. The bottom comparison now just shows that section. To zoom back out, double-click the label titled Compilation Unit, and we'll see the entirety of both files again. Okay, I'll minimize that and close it. And, of course, the most recent file update isn't the only thing you can compare you changes against. If we right-click the file and look at the Compare With menu again, you can see that we can also compare with Latest from Repository, a specific revision, or a branch, or a tag.
And we can also compare with other saved versions in our local history. Let's compare against the Latest from Repository, which is the most recent version of the file in this branch in the repo. I'll expand that, and we really get the same information as before because our previous working version actually was the latest version from the repository. But the difference here, this time, we actively pulled from the server. When we compared with Base from Working Copy before, we didn't have to make a connection to the server at all.
So, the previous compare was completely local. This compare had to communicate with the server. That means we could have compared earlier with the working copy, even if we were sitting on a train or on a remote island without any network connection at all.
- 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