A great Subversion reference, don't perform SVN admin without it.

---

Product Description

This book covers the theory behind version control and how it can help developers become more efficient, work better as a team, and keep on top of software complexity. Version control, done well, is your "undo" button for the project: nothing is final, and mistakes are easily rolled back.

This book describes Subversion 1.3, the latest and hottest open source version control system, using a recipe-based approach that will get you up and running quickly and correctly. Learn how to use Subversion the right way-the pragmatic way.

With this book, you can:

• Keep all project assets safe--not just source code--and never run the risk of losing a great idea
• Know how to undo bad decisions--even directories and symlinks are versioned
• Learn how to share code safely, and work in parallel for maximum efficiency
• Install Subversion and organize, administer and backup your repository
• Share code over a network with Apache, svnserve, or ssh
• Create and manage releases, code branches, merges and bug fixes
• Manage 3rd party code safely
• Use all the latest Subversion 1.3 features including locking and path-based security, and much more!

Now there's no excuse not to use professional-grade version control.

---

Product Details

• Amazon Sales Rank: #58699 in Books
• Published on: 2006-05-31
• Original language: English
• Number of items: 1
• Binding: Paperback
• 256 pages

From the Publisher
This book is a recipe-based approach to using Subversion that will get you up and running quickly---and correctly. All projects need version control: it's a foundational piece of any project's infrastructure. Yet half of all project teams in the U.S. don't use any version control at all. Many others don't use it well, and end up experiencing time-consuming problems.

Version Control, done well, is your "undo" button for the project: nothing is final, and mistakes are easily rolled back.

This book describes Subversion 1.3, the latest and hottest Open Source version control system.

Learn how to use Subversion the right way---the pragmatic way.

About the Author
Mike Mason is a consultant with ThoughtWorks, developing enterprise applications for Global 1000 companies. As a developer, coach, and Agile/XP proponent, he relies on version control best practices to get the job done. Mike has extensive experience of leading version control systems, including Subversion, CVS and Perforce.

Excerpted from Pragmatic Version Control Using Subversion by Mike Mason. Copyright © 2005. Reprinted by permission. All rights reserved.
Chapter 8 Using Tags and Branches

Day-to-day use of Subversion is pretty simple: you update from your repository, edit files, and save the changes back after you’ve tested. However, many developers are put off by tags and branches. Perhaps they’ve worked previously in teams that abused branches and where a diagram of the repository structure would have looked like a bowl of spaghetti rather than a controlled, linear development. Or perhaps they worked in a team where merges between branches were delayed and delayed, so when they did finally occur, it was a nightmare resolving the conflicts. Or perhaps it’s just the incredible flexibility that branches offer; with so much choice, it’s hard to know what to do.

In reality, tags and branches can (and should) be simple to use. The trick is to use them in the correct circumstances. In this chapter we present two scenarios where we believe branches should be used by teams: generating releases and giving developers a place to experiment.

Beyond these two circumstances, we suggest you think hard before adding branches to a repository. Excessive branching can quickly render any project’s repository unusable.

Before we go into the specific recipes, we need to discuss tags and branches in general.

8.1 Tags and Branches

Your Subversion repository probably contains a lot of information. Apart from the sheer number of source files that comprise a typical project, Subversion also stores every revision of each file. Adding time as a dimension to locating information in your repository means the complexity just explodes—how can we possibly keep track of it all? A tag is a symbolic name for a set of files, each with a particular revision number. You can think of a tag as making a slice through your repository and labeling everything inside, as shown in Figure 8.1.

Tags are really useful for keeping track of important events in the life cycle of your project. Instead of having to remember that you built a release for your customer using revision 16 of Calendar.java, revision 23 of Schedule.java, and revision 12 of contacts.dat, you can use a tag to remember this for you. Since a Subversion revision number is also a slice through the repository, you might think we could just use revision numbers or maybe the date we checked the code out in order to build a release. This could work, but tags can also be made from a mixed revision working copy—a set of files you’ve checked out that doesn’t correspond to a single repository revision number. This might be needed if you want to pick and choose which versions of project components should be packaged together during a release.

To create a tag in Subversion, copy your code (typically from the trunk) in the tags directory for your project. Subversion handles this copy process very efficiently, making the copy instantly and requiring very little space to store it. The directory to which you copy the code is the symbolic name for the tag. The copy serves as a reference point, storing the files in your project as they were when the tag was created.

Directory copies in Subversion are just that—simple copies. By convention, you’ll never make changes to the code stored underneath tags, but there’s nothing actually stopping you from doing so. If you do check in changes to a tag directory, the tag effectively becomes a branch. Subversion won’t move it to your branches directory or anything clever like that, but the tag will no longer contain a fixed snapshot of your repository. This could be useful in certain cases—for example, you could set up a latest tag that always contains your most recently built (and tested) code.

We first talked about branches in Section 2.7, Branches, on page 19, when we discussed how we can use them to handle releases in a version control system. A branch represents a fork in the history of the repository; the same file may have two or more sets of independent changes made to it, each set existing in a separate branch.

To create a branch in Subversion, you’ll copy your trunk code to a directory underneath branches for your project. The new directory names the branch, and initially just stores a Subversion "cheap copy" of the files as they were when the branch was made. When you check in a change to files on a branch, Subversion remembers the changes in parallel with changes made to the original on the trunk. Subversion also remembers that the two files have a common history.

Tags and Branches in Practice

Tags and branches have many possible uses. However, excessive tagging and branching can end up being remarkably confusing. So to keep things simple, we suggest that initially you use them for four different purposes:

Release Branches
We recommend putting each release of a project onto a separate branch. The directory used inside branches names the branch.

Releases
The release branch will contain one (and possibly more) releases: points at which the project is shipped. The release tags identify these points.

Bug Fixes
Bugs in the release are fixed on the release branch. If appropriate the fix is then merged into the trunck and other release branches. In cases where a bug is fixed in one commit, a Subversion revision number is enough to identify what changed and perform any merges. For more complicated bugs a branch is created for the bug fix and merged into the release branch and trunk when the fix is complete. Tags are created to mark the start and end of the bug fix in order to make merging easier.

---

Customer Reviews

Pragmatic best practices with version control!
At first this book seems unobtrusive next to some other 400+ page books on your bookshelf. However, don't overlook it... This book is really easy to read, has good theory coverage, is brimming with down to earth practical examples and has lots of best practices that one should be using.

The first 150 pages give the reader an in-depth introduction to Subversion and common place version control theory and mechanisms. The last 50 pages cover the appendix dealing with installation, security, migration from dated versioning systems such as CVS, third party tools and last but not least a command summary and set of recipes.

I took a complete day to read the book and try out the examples. Considering the price of the book and the time spent reading it, its return on investment is high. It certainly knocks the socks off some commercial products and training I've seen in the past.

Really, this is one book I certainly recommend for Architects, Software Engineers and SCM specialists even if you're not using Subversion!

All you need to start version control
No idea what the first edition was like, but as of version 1.3, if you're looking to get up and running with Subversion, this book is a must buy.

This takes you through setting up a repository and the various tasks you'd probably want to carry out, in a simple step-by-step manner. The slightly trickier proposition of setting up the subversion server is also covered, with both Apache and SSH variations, as well as the more basic svnserve.

Beyond the simple recipes, there is also some helpful advice on 'agile' use of repositories: guidelines on how to arrange a project and deal with things like 3rd party code, and the use of branching and tagging for dealing with bug fixes and releases.

Of the three Pragmatic Starter Kit books, this is the one that delivers the most value for money. There is more substantial information here than the Pragmatic Automation book, and unlike JUnit, there are not many up to date or comprehensive Subversion tutorials on the net for free. While the official Subversion book is freely available from the svn website, compiling all the information presented here is far more time consuming.

If you're looking to start version control with Subversion, then buy without hesitation.

Good as both tutorial and reference
This book is a handy tutorial and reference for Subversion.

It includes a very useful section that describes the differences between different version control systems. So, if you are moving from a version control system that always uses file locking, or if you are moving from a version control system that applies revision numbers to each file rather than to the repository as a whole, this section explains the differences you will find when moving to Subversion.

It explains all of the common tasks that you do when using a version control system, providing command summaries and examples for each. It also provides recommendations about how to organise your repository/directories and how/when to use branching and tags. It even goes so far as to recommend naming conventions for branches.

With sections on administering the repository, migrating to Subversion, third-party tools (including GUIs) that work with Subversion etc, this book covers almost everything you need to know. I still had a couple of questions outstanding when I finished the book, but those related to things that are very uncommon tasks, so easily missed out of a book of this size.

Note that the vast majority of this book uses the Subversion command-line, so for those people who don't like to move outside of a GUI the emphasis may not be quite what you want. However, the underlying principles are still things you need to know so I'd still recommend this book.

Some companies insist of their developers being "certified" in particular programming languages before being allowed to work on particular projects. On large projects it's inevitable that you will have developers of differing standards, so personally, I'd say it was even more important that the developers understood and used version control properly than be formally certified in a particular language. At least that way, there is some chance of monitoring and controlling the code that they produce, whatever the standard. If you cannot reliably and reproducibly produce a build based on code from version control, if you cannot relate source and documentation, if you cannot relate source and related test harnesses, if you cannot relate code to a released executable, what chance is there of anything working? Understanding version control is vital and this book is a good way of getting that understanding, particularly for those using Subversion.