Version Control with Subversion, 2nd Edition
by C. Michael Pilato, Ben Collins-Sussman, Brian W. Fitzpatrick
Using Branches
At this point, you should understand how each commit creates an entirely new filesystem tree (called a “revision”) in the repository. If you don’t, go back and read about revisions in Revisions.
For this chapter, we’ll go back to the same example from Chapter 1. Remember that you and your collaborator, Sally, are sharing a repository that contains two projects, paint and calc. Notice that in Figure 4-2, however, each project directory now contains subdirectories named trunk and branches. The reason for this will soon become clear.

Figure 4-2. Starting repository layout
As before, assume that Sally and you both have working copies of the “calc” project. Specifically, you each have a working copy of /calc/trunk. All the files for the project are in this subdirectory rather than in /calc itself, because your team has decided that /calc/trunk is where the “main line” of development is going to take place.
Let’s say that you’ve been given the task of implementing a large software feature. It will take a long time to write, and it will affect all the files in the project. The immediate problem is that you don’t want to interfere with Sally, who is in the process of fixing small bugs here and there. She’s depending on the fact that the latest version of the project (in /calc/trunk) is always usable. If you start committing your changes bit by bit, you’ll surely break things for ...