At the point that a project is ready for release, a common practice with Subversion/SVN is to "tag" the release in order to preserve an easy-to-find snapshot of the project if you need to locate it again in the future. This video talks about tagging branches and what to do with the release branch once you've copied the project to the tags folder.
- [Narrator] Your release has been tested, your bugs are fixed, and you're ready to go gold with your code. Now what? Usually the next step in the release process is to tag your release. In the Subversion project structure, we've talked a lot about branches and the trunk, but there's a third leg of the project tree we haven't talked much about, tags. In some ways a tag is just another branch. I mean, really, in SVN, everything is a branch. The trunk is a branch, if you think about it. Each project in a repository is kind of a branch.
In fact, at some philosophical level, every single commit you make is its own kind of branch, even if you're making to an existing branch. So yes, a tag is just a branch, but it's a branch with special meaning in Subversion. Normally you think of things in tags as snapshots. Again, every single commit is also a snapshot, but ignore that for a second. Tags are snapshots that are easy to find and well organized. In other words, you copy things to tags when they're important versions of your code that you might need to refer back to.
So, what defines an important version? Well, it's up to you, just like every part of your Subversion project structure is up to you, but for most people, at the very least, a finished released copy of your code is pretty special, and that deserves to be tagged. Right now we've got a code release ready to go out the door, so let's tag it. I'll assume that the project we currently have in Eclipse is the one we want to tag. It's all up to date, and it's the release branch that we want to save. In Eclipse Package Explorer, right click the project and choose Team, Tag.
You need to name the tag, just like how branches are automatically put in the branches folder, the subversive plug-in will automatically put tags in the tags folder of your current project, so you don't need to enter the full URL, you just need a tag name. So let's use a tag name of release-1.0.0. I'm specifically using the word release in the tag name because it's possible that you have non-release code in tags too. Maybe you tagged public betas or special customer builds or the last build every Friday afternoon too, I don't know.
Specifically calling it release helps with organization. Just like with everything else, you can use whatever naming standard you want. Now check the Start working in tag check box here, so we can switch to the tag in Eclipse when we're done. If you don't check the box, the tag is created normally, but the Eclipse working copy still points to whatever branch you were currently pointing at. A lot of times, you'll probably just want to create the tag and go do something else, and in this case, you can leave this box unchecked. You'll also see that some of the other options here are grayed out. Freeze SVN Externals is checked by default and grayed out so you can't uncheck it.
You can change this behavior in the SVN plug-in properties but it's really a good idea to have this box checked for tags, and you should probably leave that setting as is. Also, the Revision options are grayed out here because we're using the Use the working copy as is option when we create the tag. This is just like the branch if we change this to Use the repository version, then we can pick a specific revision to create the tag from. What's neat about this is, you can even create a tag based on something you don't have a working copy of, like if you're working on a branch, and your boss calls and says, "Hey, you tagged that release branch "like I asked you to yesterday, right?" And you totally forgot to because you were in the middle of a hundred other things.
That's no problem. You don't even have to change what you're working on. You can tag that branch from here even if you're working on a different branch right now. And of course there's the comment field because we're technically making a commit, and we need to make a commit comment. So I'll do that, "Tagging release 1.0.0," and after that we can click Okay to create the tag. Back in Eclipse, we can see the project is now pointing to the new tag, and the SVN console has all the information about what just happened.
Creating the tag was a copy operation, and then we did a switch to use the tag as our working directory. Now, even though the tag is just another branch, most Subversion tools will give you a warning if you try to change something in a tag. So, for example, let's say we changed the description of Glazed Donut here to Amazing Glazed Donut. I'll choose File and Save, and then I'll right click the project, and chose Team, and Commit to commit that change.
So we get a warning here. "You're going to modify the tag in the repository. "Do you want to continue?" Normally at this point you say, "Oh, I made a mistake. "Thank you, SVN, for saving me from my wretched ways," and you click No, and you switch to a branch, and you work like you're supposed to. However, Subversion doesn't force you to do the right thing here, and you can certainly click the Yes button and commit to the tag anyway. It's really no big deal if you do. I mean, this is a version control system, and we can always use the previous revision of the tag. But this gives you a warning just in case it's an accident.
One last thing I'll mention, kind of on a theoretical level. So, we have a trunk, and we made the release branch off the trunk. This had all the code we used for testing and prepping version 1.0.0 of our code. At the point that it's ready for release, we created a tag and we can save that version and admire it forever and easily refer back to it whenever we want. So what happens to the release branch at this point? We're kind of done with it, aren't we? Well, one option is to delete it. We used the branch, we were careful not to make any changes directly to it that weren't already in trunk, and now we've declared that it's finished.
When you're finished with a branch, you can delete it. Then, when you want to start working on release 1.0.1, you can create a new release branch and start the process over. Pretty straightforward, that's one option, and that's what a lot of people do. Well, another option is to keep the branch alive after you make the tag and continue using that release branch for future minor versions of your code. Ongoing development and bug fixes can happen in feature branches in the trunk, and your release manager can selectively pull changes into the release branch as needed, and ultimately release 1.0.1, 1.0.2, and so on.
Then, at the point when development on version 1.0 of your code stops and you start working on version 2.0, you'll probably create a new release branch for the family of versions. For a lot of software, new features only get added with new major versions, so this way you can sort of logically separate version 1.0 and version 2.0 in terms of you development work. That's another way to do it. As always, there's no one right way to manage your code in Subversion, and your team might have a totally different way of organizing code for releases. That's fine. However you do it, at least the concept of creating tags for final release versions is pretty standard and something you'll find with a lot of software projects.
So deal with the releases however you want. Just don't forget to tag them when they're done.
- 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