[svnbook commit] r2656 - trunk/src/en/book
sussman
noreply at red-bean.com
Mon Feb 5 23:10:12 CST 2007
Author: sussman
Date: Mon Feb 5 23:10:12 2007
New Revision: 2656
Modified:
trunk/src/en/book/ch-branching-and-merging.xml
Log:
* src/en/book/ch-branching-and-merging.xml: remove spurious whitespace.
Modified: trunk/src/en/book/ch-branching-and-merging.xml
==============================================================================
--- trunk/src/en/book/ch-branching-and-merging.xml (original)
+++ trunk/src/en/book/ch-branching-and-merging.xml Mon Feb 5 23:10:12 2007
@@ -61,12 +61,12 @@
your daily work.</para>
</sect1>
-
+
<!-- ================================================================= -->
<!-- ================================================================= -->
<!-- ================================================================= -->
<sect1 id="svn.branchmerge.using">
- <title>Using Branches</title>
+ <title>Using Branches</title>
<para>At this point, you should understand how each commit creates
an entire new filesystem tree (called a <quote>revision</quote>)
@@ -82,7 +82,7 @@
directory now contains subdirectories named
<filename>trunk</filename> and <filename>branches</filename>.
The reason for this will soon become clear.</para>
-
+
<figure id="svn.branchmerge.using.dia-1">
<title>Starting repository layout</title>
<graphic fileref="images/ch04dia2.png"/>
@@ -140,8 +140,8 @@
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.using.create">
- <title>Creating a Branch</title>
-
+ <title>Creating a Branch</title>
+
<para>Creating a branch is very simple—you make a copy of
the project in the repository using the <command>svn
copy</command> command. Subversion is not only able to copy
@@ -223,7 +223,7 @@
<filename>/calc/trunk</filename>. This is shown in <xref
linkend="svn.branchmerge.using.create.dia-1"/>. Notice that the second method,
however, performs an <emphasis>immediate</emphasis> commit.
- <footnote>
+ <footnote>
<para>Subversion does not support
cross-repository copying. When using URLs with <command>svn
copy</command> or <command>svn move</command>, you can only
@@ -233,15 +233,15 @@
check out a large mirror of the repository. In fact, this
technique doesn't even require you to have a working copy at
all.</para>
-
+
<figure id="svn.branchmerge.using.create.dia-1">
<title>Repository with new copy</title>
<graphic fileref="images/ch04dia3.png"/>
</figure>
-
+
<sidebar>
<title>Cheap Copies</title>
-
+
<para>Subversion's repository has a special design. When you
copy a directory, you don't need to worry about the
repository growing huge—Subversion doesn't actually
@@ -254,7 +254,7 @@
changes—the rest of the files continue to exist as
links to the original files in the original
directory.</para>
-
+
<para>This is why you'll often hear Subversion users talk
about <quote>cheap copies</quote>. It doesn't matter how
large the directory is—it takes a very tiny, constant
@@ -274,7 +274,7 @@
</sidebar>
</sect2>
-
+
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.using.work">
<title>Working with Your Branch</title>
@@ -476,19 +476,19 @@
that by the time you're finished with your branch, it may be
near-impossible to merge your changes back into the trunk
without a huge number of conflicts.</para>
-
+
<para>Instead, you and Sally might continue to share changes as
you work. It's up to you to decide which changes are worth
sharing; Subversion gives you the ability to selectively
<quote>copy</quote> changes between branches. And when you're
completely finished with your branch, your entire set of branch
changes can be copied back into the trunk.</para>
-
+
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.copychanges.specific">
<title>Copying Specific Changes</title>
-
+
<para>In the previous section, we mentioned that both you and
Sally made changes to <filename>integer.c</filename> on
@@ -533,34 +533,34 @@
high = high << 8; /* interpret MSB correctly */
- total = low + high; /* add them togethe for correct total */
+ total = low + high; /* add them together for correct total */
-
+
info->extra_header = (unsigned char *) my_malloc(total);
fread(info->extra_header, total, 1, gzfile);
@@ -241,7 +241,7 @@
Store the offset with ftell() ! */
-
+
if ((info->data_offset = ftell(gzfile))== -1) {
- printf("error: ftell() retturned -1.\n");
+ printf("error: ftell() returned -1.\n");
exit(1);
}
-
+
@@ -249,7 +249,7 @@
printf("I believe start of compressed data is %u\n", info->data_offset);
#endif
-
+
- /* Set postion eight bytes from the end of the file. */
+ /* Set position eight bytes from the end of the file. */
-
+
if (fseek(gzfile, -8, SEEK_END)) {
printf("error: fseek() returned non-zero\n");
</screen>
-
+
<para>The <command>svn merge</command> command is almost exactly
the same. Instead of printing the differences to your
terminal, however, it applies them directly to your working
copy as <emphasis>local modifications</emphasis>:</para>
-
+
<screen>
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
U integer.c
@@ -648,7 +648,7 @@
them to your working copy.</para>
</sidebar>
-
+
<para>A word of warning: while <command>svn diff</command> and
<command>svn merge</command> are very similar in concept, they
do have different syntax in many cases. Be sure to read about
@@ -678,12 +678,12 @@
by the same name) exists in your current working directory,
<command>svn merge</command> assumes the second case and tries
to apply the changes to a local file with the same name.</para>
-
+
<para>If you want changes applied somewhere else, you'll
need to say so. For example, if you're sitting in the parent
directory of your working copy, you'll have to specify the
target directory to receive the changes:</para>
-
+
<screen>
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
U my-calc-branch/integer.c
@@ -731,7 +731,7 @@
<listitem><para>A working copy to accept the differences as
local changes (often called the <firstterm>target</firstterm>
of the merge).</para></listitem>
-
+
</orderedlist>
<para>Once these three arguments are specified, the two trees
@@ -748,11 +748,11 @@
specify the three necessary arguments rather flexibly. Here
are some examples:</para>
- <screen>
+ <screen>
$ svn merge http://svn.example.com/repos/branch1@150 \
http://svn.example.com/repos/branch2@212 \
my-working-copy
-
+
$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
$ svn merge -r 100:200 http://svn.example.com/repos/trunk
@@ -768,7 +768,7 @@
</sect2>
-
+
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.copychanges.bestprac">
<title>Best Practices for Merging</title>
@@ -817,15 +817,15 @@
technique in action.</para>
</sect3>
-
+
<sect3 id="svn.branchmerge.copychanges.bestprac.preview">
<title>Previewing Merges</title>
-
+
<para>Because merging only results in local modifications,
it's not usually a high-risk operation. If you get the
merge wrong the first time, simply <command>svn
revert</command> the changes and try again.</para>
-
+
<para>It's possible, however, that your working copy might
already have local modifications. The changes applied by a
merge will be mixed with your pre-existing ones, and running
@@ -947,7 +947,7 @@
merge.</para>
</sect3>
-
+
<sect3 id="svn.branchmerge.copychanges.bestprac.ancestry">
<title>Noticing or Ignoring Ancestry</title>
@@ -1095,7 +1095,7 @@
$
</screen>
-
+
<para>As expected, the final revision printed by this command
is the revision in which <filename>my-calc-branch</filename>
was created by copying.</para>
@@ -1160,7 +1160,7 @@
------------------------------------------------------------------------
…
</screen>
-
+
<para>Aha! Since all branch-changes that happened between
revisions 341 and 405 were previously merged to the trunk as
revision 406, you now know that you want to merge only the
@@ -1239,7 +1239,7 @@
change, we're asking <command>svn merge</command> to apply
changeset #303 to our working copy
<emphasis>backwards</emphasis>.</para>
-
+
<sidebar>
<title>Subversion and Changesets</title>
@@ -1380,14 +1380,15 @@
<para>That was the hard part—the research. Now that you
know what you want to restore, you have two different
choices.</para>
-
+
<para>One option is to use <command>svn merge</command> to apply
revision 808 <quote>in reverse</quote>. (We've already
- discussed how to undo changes, see <xref
- linkend="svn.branchmerge.commonuses.undo"/>.) This would have the effect of
- re-adding <filename>real.c</filename> as a local modification.
- The file would be scheduled for addition, and after a commit,
- the file would again exist in <literal>HEAD</literal>.</para>
+ discussed how to undo changes, see
+ <xref linkend="svn.branchmerge.commonuses.undo"/>.) This
+ would have the effect of re-adding <filename>real.c</filename>
+ as a local modification. The file would be scheduled for
+ addition, and after a commit, the file would again exist
+ in <literal>HEAD</literal>.</para>
<para>In this particular example, however, this is probably not
the best strategy. Reverse-applying revision 808 would not
@@ -1450,10 +1451,10 @@
Subversion; they're applicable to any version control system.
Still, it may help to see them described in Subversion
terms.</para>
-
+
<sect3 id="svn.branchmerge.commonuses.patterns.release">
<title>Release Branches</title>
-
+
<para>Most software has a typical lifecycle: code, test,
release, repeat. There are two problems with this process.
First, developers need to keep writing new features while
@@ -1501,7 +1502,7 @@
process stops. The branch is <quote>frozen</quote> for
final testing right before a release.</para>
</listitem>
-
+
<listitem>
<para><emphasis>The branch is tagged and released.</emphasis>
@@ -1538,7 +1539,7 @@
<sect3 id="svn.branchmerge.commonuses.patterns.feature">
<title>Feature Branches</title>
-
+
<para>A <firstterm>feature branch</firstterm> is the sort of
branch that's been the dominant example in this chapter, the
one you've been working on while Sally continues to work on
@@ -1592,10 +1593,13 @@
merge the last week's worth of trunk changes to the branch.
Take care when doing this; the merging needs to be
hand-tracked to avoid the problem of repeated merges (as
- described in <xref linkend="svn.branchmerge.copychanges.bestprac.track"/>). You'll
- need to write careful log messages detailing exactly which
- revision ranges have been merged already (as
- demonstrated in <xref linkend="svn.branchmerge.commonuses.wholebr"/>). It
+ described in
+ <xref
+ linkend="svn.branchmerge.copychanges.bestprac.track"/>).
+ You'll need to write careful log messages detailing exactly
+ which revision ranges have been merged already (as
+ demonstrated in
+ <xref linkend="svn.branchmerge.commonuses.wholebr"/>). It
may sound intimidating, but it's actually pretty easy to
do.</para>
@@ -1704,7 +1708,7 @@
working copy to mirror the branch.</para>
</listitem>
</orderedlist>
-
+
<para>In other words, if a user knows that the branch-work only
needs to happen on a specific subdirectory, they use
<command>svn switch</command> to move only that subdirectory to
@@ -1717,7 +1721,7 @@
working copy</quote>—not only can working copies contain a
mixture of working revisions, but a mixture of repository
locations as well.</para>
-
+
<para>If your working copy contains a number of switched subtrees
from different repository locations, it continues to function as
normal. When you update, you'll receive patches to each subtree
@@ -1736,10 +1740,10 @@
See the <command>svn switch</command> section in <xref
linkend="svn.ref"/> for more information and an example.</para>
</footnote></para>
-
+
<sidebar>
<title>Switches and Updates</title>
-
+
<para>Have you noticed that the output of <command>svn
switch</command> and <command>svn update</command> look the
same? The <literal>switch</literal> command is actually a
@@ -1752,7 +1756,7 @@
switch</command> and <command>svn update</command> is that the
<literal>update</literal> command always compares two identical
paths.</para>
-
+
<para>That is, if your working copy is a mirror of
<filename>/calc/trunk</filename>, then <command>svn
update</command> will automatically compare your working copy
@@ -1866,15 +1870,15 @@
This is version control, after all.</para>
</sect2>
-
+
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.tags.mkcomplex">
<title>Creating a Complex Tag</title>
-
+
<para>Sometimes you may want your <quote>snapshot</quote> to be
more complicated than a single directory at a single
revision.</para>
-
+
<para>For example, pretend your project is much larger than our
<filename>calc</filename> example: suppose it contains a
number of subdirectories and many more files. In the course
@@ -1944,7 +1948,7 @@
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.maint.layout">
<title>Repository Layout</title>
-
+
<para>There are some standard, recommended ways to organize a
repository. Most people create a <filename>trunk</filename>
directory to hold the <quote>main line</quote> of development,
@@ -1995,9 +1999,9 @@
longer exists, and the user will be forced to <command>svn
switch</command> to the new location.
</para>
-
+
</sect2>
-
+
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.maint.lifetime">
<title>Data Lifetimes</title>
@@ -2093,7 +2097,7 @@
This scenario plays itself out all the time—anywhere that
the information generated by one group of people has a direct
effect on that which is generated by another group.</para>
-
+
<para>For example, software developers might be working on an
application which makes use of a third-party library.
Subversion has just such a relationship with the Apache Portable
@@ -2192,7 +2196,7 @@
-m 'importing initial 1.0 vendor drop'
…
</screen>
-
+
<para>We now have the current version of the libcomplex source
code in <filename>/vendor/libcomplex/current</filename>. Now,
we tag that version (see <xref linkend="svn.branchmerge.tags" />)
@@ -2202,7 +2206,7 @@
<filename>calc</filename> project directory. It is in this
copied version of the vendor data that we will make our
customizations.</para>
-
+
<screen>
$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \
http://svn.example.com/repos/vendor/libcomplex/1.0 \
@@ -2236,7 +2240,7 @@
approach the problem from the other direction, applying the
changes made to libcomplex between versions 1.0 and 1.1 to our
modified copy of it.</para>
-
+
<para>To perform this upgrade, we checkout a copy of our vendor
branch, and replace the code in the
<filename>current</filename> directory with the new libcomplex
@@ -2462,7 +2466,7 @@
</chapter>
<!--
-local variables:
+local variables:
sgml-parent-document: ("book.xml" "chapter")
end:
-->
More information about the svnbook-dev
mailing list