The last major piece of functionality we need to explore is branching and merging. In SVN, it's done much like tagging. We create the branch from the common parent directory, the one containing the trunk, tags and branches by using svn copy. So let's go back up to the parent directory, make sure we're in the right place, there we can see branches, tags, and trunk, and then we'll execute the following command, svn copy trunk branches\b1, our branches are going to be called b1.
Once again, you can see this is pending, it hasn't actually been created yet. So we do a commit again and create branch b1. Scroll off to the top of the screen, once again log more. There we see it, created branch b1 that's revision 6. Now you notice that SVN doesn't make a distinction between your branches and the trunk in terms of its revision numbers.
All updates go to the same list of revisions, each with its own revision number. This is because the revision number represents revision of the entire repository, not just of a single file. So, to work with the branch we have to go into branches b1 and make an update. So in this branch we'll add a method called feature1, No more available space, Look to the cloud, Your hard drive is full. All right, and then we'll save this.
Now if we ask SVN for the status, you can see that we've modified file f1.c and the branches b1 directory. If we switch back to the trunk directory and ask SVN status, you can see it shows no changes, so it's keeping these independently. So now we'll switch back to the branch, and we commit.
And then I'll update, and there is a shortcut for SVN updates, just svn up. And there we can see Branch b1: Added feature 1. You might note that I put the words branch b1 in front of the commit message. That's because subversion doesn't track for you which branch changes are made in, so therefore a convention that's often used is include the branch name in the update message. So, let's quit this and talk about merging.
If you want to continue to work in a branch for an extended period or time, you want to do a forward integration from the trunk from time to time. That time varies based on how active the trunk changes are if somebody is actually working there. Usually, you do that weekly. You do that so that your branch doesn't get too far out of date with changes in other areas of software that you're not working on. But in our case, the trunk is just fine so we're going to do just a reverse integration from our branch and merge our changes from the branch into the trunk. So first, we're going to go look at the log to see which range of changes are correspond to our branch.
So in our case, you can see we created our branch at revision 6, now we added our update at revision 7. So first we have to get back to the root directory of our project and then we're going to use the svn merge Command, so we tell it to merge all the versions we have done in the branch. So svn merge -r6:7 branches\b1 trunk. As before note that this does not actually record those changes in the repository, we still have to check those in.
But now you can see instead of M for modified, it has U for updated and from merging, and it shows you that it's merging and recorded a merge info for that. So now we're going to say svn ci Merged changes from branch\b1 into trunk, and there we can see revision 8 we have merged changes form branches b1 into trunk. And our new feature is now in the trunk, and we can prove that by going into the trunk and typing out f1.c.
And you can see that we have both our original change and the feature. Okay, that's the basics of branching and merging. Obviously, you can get a lot more complicated than that, and you can find yourself in situations where there are conflicts, and you'll have to manage them manually using differencing tools. But it just shows you it's not hard to do branches, and it's not difficult to merge the changes back together if you properly coordinate what it is you're doing. Typically, there is going to be two different kinds of branches. You're going to do either a fix branch or a feature branch.
What we did here was a feature branch, but sometimes you might just take the current state of your product, make a branch in order to a fix, and then merge that fix back into the product while someone else continues on working on the main branch to do future things. All right, we're done with subversion in the command-line, let's move on to taking a look at subversion in shell integration using TortoiseSVN.
- Comparing centralized vs. distributed systems
- Saving changes and tracking history
- Using revert or rollback
- Working with the GUI tools
- Using IDE and shell integration
- Installing different systems
- Creating a repository
- Tagging code
- Branching and merging code
- Selecting a software version control system that's right for you