Once you're done making changes in your Subversion/SVN branch, and the changes are ready to be added to the project, you'll need to merge your branch back into the trunk. This video will show you how to properly merge a branch to trunk using Eclipse, in order to share your updates with the rest of your team.
- [Presenter] We've made changes to our branch, and we've been diligent about keeping it in sync, and now we're done with our changes in the branch, and we're ready to merge everything back to trunk. In this section, I'll show you have that works with the clips. There are five specific steps involved with the process of merging back to trunk. First, you finish making changes to your files. Let me add one more file to the project, just so we have changes in the branch. I'm using the eclipse project from the previous section, where we pulled the changes from trunk in, and were pointing to the glazed donut branch. Right click the com.example.donut package and choose "import".
Choose "general file system", and then "next", and for the directory, browse to your exercise files, zero four zero five, start subfolder, and click "OK". You should see a glazed donut file on the right hand side of the screen. Click the check mark, and click finish. Now you can see we have a new glazed donut file underneath the com.example.donut package. Step two is making the final commit.
Right click the project and choose team, commit. Enter a commit comment, and I'll type "final commit to glazed donut branch". And also make sure that all of your change files are selected at the bottom. Here you can see that I've got the cinnamon donut file that was pulled in from trunk, and also the glazed donut file I just added. Click "OK" and finish the commit.
Now, step three is to switch our working copy over to trunk. Right click the project again, and choose team, switch. Tell the SVN plugin to switch us to the trunk URL. I'll click "browse", "project donut", "trunk", and click "OK". And we want the head revision. Click "OK". And you can see that the project is now back to revision fifteen.
It was revision sixteen previously. Again, the revision numbers might be different for you. Don't worry, just keep in mind that the revision number actually changed because we went from the revision number in the branch to the revision number in the trunk. And, you'll also see that our new glazed donut file is gone. Just for reference, this is the technique you'll use any time you want to use start using a specific revision or branch in Subversion. You use the team switch command. This changes your entire local working copy to exactly the state all the files were in at a particular revision.
So, if you ever need to take a look at some else's branch, or go back in time to test an old version of code, or even grab something that has been deleted, this is how you do it. Just do a team switch, and you've got a snapshot in time. Anyway, now that we're working with trunk, we need to merge the branch changes into the trunk files. This is step four. Right click and choose the menu option team, merge. First, I'll show you what might be the wrong way to do it.
You'll be tempted to choose the same option we used before, when we were merging changes from trunk into the branch. Because, really, this is the same process in reverse, right? So, if you use the default URL option, and choose the branch URL- I'll choose project donut, branches, glazed donut recipe, and click "OK", and click the preview button, we'll see this. It shows that the new glazed donut file we wrote is fine, and that would get it added properly.
But, it shows there's a tree conflict with the cinnamon donut file. And that seems weird, because we got that file from trunk in the first place. If you remember, that file appeared when we were working in a branch, and we merged with trunk. So, how is that now a conflict? Well, the thing is, Subversion doesn't know where that file came from. All it knows is that we added a file called cinnamon donut, and that the trunk also has a file called cinnamon donut, and it considers that to be a conflict. That's the easiest way to think about it, anyway.
The whole concept of merge conflicts in this specific situation is kind of complex. Now, there are some ways you can work around this and force the merge. Subversion isn't so strict about merging that it doesn't have ways we can tell it what to do. And in fact, if you do the merge preview and you don't see any conflicts here, that's fine, go ahead and merge. Everything will work, and you've got nothing to worry about. But if you do get this specific kind of conflict, I want to show you what is probably the right way to merge the branch into trunk. I'll click OK to close the preview dialogue, and back at the merge dialogue, let's choose the re-integrate tab.
A re-integrate merge actually does the same kind of merge that the URL merge does, but it performs a few extra sanity checks before merging. Specifically in our case, it also ignores the kind of conflict we just saw, where the new file and branch is exactly the exact same file that we pulled from trunk. Starting with Subversion 1.8, the normal merge command will actually automatically try to do a re-integrate merge, so it doesn't need the extra re-integrate command. If you're using a new version of the SVN tools, and you don't have a re-integrate option here, that might be what's going on. In that case, just do a regular merge.
Even on newer SVN clients, though, if you have a re-integrate option, it still works, and I'd recommend using that if it's available, just to be sure. Let me browse to the branch, and I'll choose branches, glazed donut recipe, OK, then I'll click preview. This time, in the preview dialogue, you'll see the merge will happen properly, and there's no longer a problem with that cinnamon donut file we pulled from trunk before. Click OK to close the preview dialogue, and then click OK to do a merge.
I don't want to click to the synchronized view, so I'll click no here, and if we look at the SVN console, we can see that the merge successfully happened without errors, and that the glazed donut file is in our tree. Now, our local working copy has all the branch changes merged into trunk. Keep in mind that the merge changes so far have only been made to our local machine- nothing at all has changed on the server yet, as far as merging goes. If something doesn't look right, or you chose the wrong options, or someone tells you they're not quite done with that branch yet, that's fine.
You can completely start over at this point if you want. All you have to do is do another team switch, and then switch to trunk, and then start again. That's one of the really nice things about this sort of process. If you feel like you messed up halfway through, you've only been making changes locally, and the server still has all the files and revisions, so it's easy to punt and try again. In this case, I'm happy with how it all looks, and we can commit the changes to trunk. So, now for our fifth step. Right click the project again, and choose team, commit.
We'll write a comment, "merging glazed donut branch into trunk", and make sure that all of the files are selected, and click OK. All done! The commit was successful, and we have a new version in trunk, and your branch has been successfully merged. Congratulations.
- 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