At this point, you should understand how each commit creates an entire new filesystem tree (called a “revision”) in the repository. If you don't, go back and read about revisions in “修订版本”一节.
对于本章节，我们会回到第 1 章 基本概念的同一个例子，还记得你和你的合作者Sally分享一个包含两个项目的版本库，paint和calc。注意图 4.2 “开始规划版本库”，然而，现在每个项目的都有一个trunk和branches子目录，它们存在的理由很快就会清晰起来。
像以前一样，假定Sally和你都有“calc”项目的一份拷贝，更准确地说，你有一份/calc/trunk的工作拷贝，这个项目的所有的文件在这个子目录里，而不是在/calc下，因为你的小组决定使用/calc/trunk作为开发使用的“主线”。
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
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 Sally (and other team members as well).
One strategy is to crawl into a hole: you and Sally can stop
sharing information for a week or two. That is, start gutting
and reorganizing all the files in your working copy, but don't
commit or update until you're completely finished with the task.
There are a number of problems with this, though. First, it's
not very safe. Most people like to save their work to the
repository frequently, should something bad accidentally happen
to their working copy. Second, it's not very flexible. If you
do your work on different computers (perhaps you have a working
copy of /calc/trunk on two different
machines), you'll need to manually copy your changes back and
forth or just do all the work on a single computer. By that
same token, it's difficult to share your changes-in-progress
with anyone else. A common software development “best
practice” is to allow your peers to review your work as
you go. If nobody sees your intermediate commits, you lose
potential feedback and may end up going down the wrong path for
weeks before another person on your team notices. Finally, when
you're finished with all your changes, you might find it very
difficult to re-merge your final work with the rest of the
company's main body of code. Sally (or others) may have made
many other changes in the repository that are difficult to
incorporate into your working copy—especially if you
run svn update after weeks of
isolation.
The better solution is to create your own branch, or line of development, in the repository. This allows you to save your half-broken work frequently without interfering with others, yet you can still selectively share information with your collaborators. You'll see exactly how this works as we go.
建立分支非常的简单—使用svn copy命令给你的工程做个拷贝，Subversion不仅可以拷贝单个文件，也可以拷贝整个目录，在目前情况下，你希望作/calc/trunk的拷贝，新的拷贝应该在哪里？在你希望的任何地方—它只是在于项目的政策，我们假设你们项目的政策是在/calc/branches建立分支，并且你希望把你的分支叫做my-calc-branch，你希望建立一个新的目录/calc/branches/my-calc-branch，作为/calc/trunk的拷贝开始它的生命周期。
You may already have seen svn copy used to copy one file to another within a working copy. But it can also be used to do a “remote” copy entirely within the repository. Just copy one URL to another:
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Creating a private branch of /calc/trunk."
Committed revision 341.
This command causes a near-instantaneous commit in the
repository, creating a new directory in revision 341. The new
directory is a copy of /calc/trunk. This
is shown in
图 4.3 “版本库与复制”.
[19]
While it's also possible to create a branch by
using svn copy to duplicate a directory
within the working copy, this technique isn't recommended. It
can be quite slow, in fact! Copying a directory on the
client side is a linear-time operation, in that it actually
has to duplicate every file and subdirectory on local disk.
Copying a directory on the server, however, is a constant-time
operation, and it's the way most people create
branches.
现在你已经在项目里建立分支了，你可以取出一个新的工作拷贝来开始使用：
$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch A my-calc-branch/Makefile A my-calc-branch/integer.c A my-calc-branch/button.c Checked out revision 341.
There's nothing special about this working copy; it simply
mirrors a different directory in the repository. When you
commit changes, however, Sally won't see them when she
updates, because her working copy is of
/calc/trunk. (Be sure to read “使用分支”一节 later in this chapter: the
svn switch command is an alternate way of
creating a working copy of a branch.)
我们假定本周就要过去了，如下的提交发生：
你修改了
/calc/branches/my-calc-branch/button.c，生成修订版本342。你修改了
/calc/branches/my-calc-branch/integer.c，生成修订版本343。Sally修改了
/calc/trunk/integer.c，生成了修订版本344。
There are now two independent lines of development (shown
in 图 4.4 “一个文件的分支历史”) happening on
integer.c.
当你看到integer.c的改变时，你会发现很有趣：
$ pwd /home/user/my-calc-branch $ svn log -v integer.c ------------------------------------------------------------------------ r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines Changed paths: M /calc/branches/my-calc-branch/integer.c * integer.c: frozzled the wazjub. ------------------------------------------------------------------------ r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines Changed paths: A /calc/branches/my-calc-branch (from /calc/trunk:340) Creating a private branch of /calc/trunk. ------------------------------------------------------------------------ r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines Changed paths: M /calc/trunk/integer.c * integer.c: changed a docstring. ------------------------------------------------------------------------ r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines Changed paths: A /calc/trunk/integer.c * integer.c: adding this file to the project. ------------------------------------------------------------------------
注意，Subversion追踪分支上的integer.c的历史，包括所有的操作，甚至追踪到拷贝之前。这表示了建立分支也是历史中的一次事件，因为在拷贝整个/calc/trunk/时已经拷贝了一份integer.c。现在看Sally在她的工作拷贝运行同样的命令：
$ pwd /home/sally/calc $ svn log -v integer.c ------------------------------------------------------------------------ r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines Changed paths: M /calc/trunk/integer.c * integer.c: fix a bunch of spelling errors. ------------------------------------------------------------------------ r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines Changed paths: M /calc/trunk/integer.c * integer.c: changed a docstring. ------------------------------------------------------------------------ r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines Changed paths: A /calc/trunk/integer.c * integer.c: adding this file to the project. ------------------------------------------------------------------------
Sally sees her own revision 344 change, but not the change you made in revision 343. As far as Subversion is concerned, these two commits affected different files in different repository locations. However, Subversion does show that the two files share a common history. Before the branch copy was made in revision 341, the files used to be the same file. That's why you and Sally both see the changes made in revisions 303 and 98.
There are two important lessons that you should remember from this section. First, Subversion has no internal concept of a branch—it knows only how to make copies. When you copy a directory, the resulting directory is only a “branch” because you attach that meaning to it. You may think of the directory differently, or treat it differently, but to Subversion it's just an ordinary directory that happens to carry some extra historical information.
Second, because of this copy mechanism, Subversion's
branches exist as normal filesystem
directories in the repository. This is different
from other version control systems, where branches are
typically defined by adding
extra-dimensional “labels” to collections of
files. The location of your branch directory doesn't matter
to Subversion. Most teams follow a convention of putting all
branches into a /branches directory, but
you're free to invent any policy you wish.