
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
50
|
Chapter 4: Branching and Merging
There are a number of problems with this, though. First, it’s not very safe. Most peo-
ple like to save their work to the repository frequently, should something bad acci-
dentally 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. Finally, when you’re finished
with all your changes, you might find it very difficult to remerge 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 inter-
fering with others, yet you can still ...