[svnbook commit] r2948 - trunk/src/en/book
sussman
noreply at red-bean.com
Mon Dec 17 23:34:38 CST 2007
Author: sussman
Date: Mon Dec 17 23:34:36 2007
New Revision: 2948
Log:
* ch04: clarify misstatement in vendor branching discussion, see issue #33.
Modified:
trunk/src/en/book/ch04-branching-and-merging.xml
Modified: trunk/src/en/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/src/en/book/ch04-branching-and-merging.xml (original)
+++ trunk/src/en/book/ch04-branching-and-merging.xml Mon Dec 17 23:34:36 2007
@@ -2525,7 +2525,7 @@
working copy directory (see <xref linkend="svn.advanced.externals" />).</para>
<para>But sometimes you want to maintain custom modifications to
- third-party data in your own version control system. Returning
+ third-party code in your own version control system. Returning
to the software development example, programmers might need to
make modifications to that third-party library for their own
purposes. These modifications might include new functionality
@@ -2540,9 +2540,9 @@
disjointed fashion, such as using patch files or full-fledged
alternate versions of files and directories. But these quickly
become maintenance headaches, requiring some mechanism by which
- to apply your custom changes to the third-party data, and
+ to apply your custom changes to the third-party code, and
necessitating regeneration of those changes with each successive
- version of the third-party data that you track.</para>
+ version of the third-party code that you track.</para>
<para>The solution to this problem is to use <firstterm>vendor
branches</firstterm>. A vendor branch is a directory tree in
@@ -2565,8 +2565,8 @@
<sect2 id="svn.advanced.vendorbr.general">
<title>General Vendor Branch Management Procedure</title>
- <para>Managing vendor branches generally works like this. You
- create a top-level directory (such as
+ <para>Managing vendor branches generally works like this: first,
+ you create a top-level directory (such as
<filename>/vendor</filename>) to hold the vendor branches.
Then you import the third party code into a subdirectory of
that top-level directory. You then copy that subdirectory
@@ -2579,8 +2579,8 @@
occur between your local changes and the upstream
changes.</para>
- <para>Perhaps an example will help to clarify this algorithm.
- We'll use a scenario where your development team is creating a
+ <para>An example will help to clarify this algorithm. We'll use
+ a scenario where your development team is creating a
calculator program that links against a third-party complex
number arithmetic library, libcomplex. We'll begin with the
initial creation of the vendor branch, and the import of the
@@ -2657,22 +2657,25 @@
<para>After replacing the 1.0 code with 1.1 code, <command>svn
status</command> will show files with local modifications as
- well as, perhaps, some unversioned or missing files. If we
- did what we were supposed to do, the unversioned files are
- only those new files introduced in the 1.1 release of
- libcomplex—we run <command>svn add</command> on those to
- get them under version control. The missing files are files
- that were in 1.0 but not in 1.1, and on those paths we run
- <command>svn delete</command>. Finally, once our
- <filename>current</filename> working copy contains only the
- libcomplex 1.1 code, we commit the changes we made to get it
- looking that way.</para>
+ well as, perhaps, some unversioned files. If we did what we
+ were supposed to do, the unversioned files are only those new
+ files introduced in the 1.1 release of libcomplex—we
+ run <command>svn add</command> on those to get them under
+ version control. If the 1.1 code no longer has certain files
+ that were in the 1.0 tree, it may be hard to notice them;
+ you'd have to compare the two trees with some external tool
+ and then <command>svn delete</command> any files present in
+ 1.0 but not in 1.1. (Although it might also be just fine to
+ let these same files live on in unused obscurity!) Finally,
+ once our <filename>current</filename> working copy contains
+ only the libcomplex 1.1 code, we commit the changes we made to
+ get it looking that way.</para>
<para>Our <filename>current</filename> branch now contains the
- new vendor drop. We tag the new version (in the same way we
- previously tagged the version 1.0 vendor drop), and then merge
- the differences between the tag of the previous version and
- the new current version into our main development
+ new vendor drop. We tag the new version as 1.1 (in the same
+ way we previously tagged the version 1.0 vendor drop), and
+ then merge the differences between the tag of the previous
+ version and the new current version into our main development
branch.</para>
<screen>
More information about the svnbook-dev
mailing list