[svnbook] r4166 committed - * en/book/ch04-branching-and-merging.xml...

svnbook at googlecode.com svnbook at googlecode.com
Mon Nov 7 11:58:20 CST 2011


Revision: 4166
Author:   ptburba at gmail.com
Date:     Mon Nov  7 09:57:26 2011
Log:      * en/book/ch04-branching-and-merging.xml
   Passive voice cleanup.

http://code.google.com/p/svnbook/source/detail?r=4166

Modified:
  /trunk/en/book/ch04-branching-and-merging.xml

=======================================
--- /trunk/en/book/ch04-branching-and-merging.xml	Mon Nov  7 08:25:42 2011
+++ /trunk/en/book/ch04-branching-and-merging.xml	Mon Nov  7 09:57:26 2011
@@ -149,7 +149,7 @@
          your project tree in the repository using the <command>svn
          copy</command> command.  Since your project's source code is
          rooted in the <filename>/calc/trunk</filename> directory, it's
-        that directory that you'll be copying.  Where should the new
+        that directory that you'll copy.  Where should the new
          copy live?  Wherever you wish.  The repository location in
          which branches are stashed is left by Subversion as a matter
          of project policy.  Finally, your branch will need a name to
@@ -163,7 +163,7 @@
          (the <filename>/calc/branches</filename> directory in our
          scenario).  Lacking inspiration, you settle
          on <literal>my-calc-branch</literal> as the name you wish to
-        give your branch.  This means that you'll be creating a new
+        give your branch.  This means that you'll create a new
          directory, <filename>/calc/branches/my-calc-branch</filename>,
          which begins its life as a copy
          of <filename>/calc/trunk</filename>.</para>
@@ -467,7 +467,7 @@
        Subversion client and server are running Subversion 1.5 (or
        later).  If either client or server is older than version 1.5,
        things are more complicated: the system won't track changes
-      automatically, and you'll have to use painful manual methods to
+      automatically, forcing you to use painful manual methods to
        achieve similar results.  That is, you'll always need to use the
        detailed merge syntax to specify specific ranges of revisions to
        replicate (see
@@ -482,7 +482,7 @@
        <title>Changesets</title>

        <para>Before we proceed further, we should warn you that there's
-        going to be a lot of discussion of <quote>changes</quote> in
+        a lot of discussion of <quote>changes</quote> in
          the pages ahead.  A lot of people experienced with version
          control systems use the terms <quote>change</quote>
          and <quote>changeset</quote> interchangeably, and we should
@@ -615,8 +615,8 @@
          modified; the <command>svn diff</command> will show that
          its <literal>svn:mergeinfo</literal> property has been either
          created or modified.  This is important merge-related metadata
-        that you should <emphasis>not</emphasis> touch, since it will
-        be needed by future <command>svn merge</command> commands.
+        that you should <emphasis>not</emphasis> touch, since it is
+        needed by future <command>svn merge</command> commands.
          (We'll learn more about this metadata later in the
          chapter.)</para>

@@ -754,9 +754,9 @@
  </screen>
        </informalexample>

-      <para>Subversion knows which trunk changes you've already
+      <para>Subversion knows which trunk changes you previously
          replicated to your branch, so it carefully replicates only
-        those changes you don't yet have.  Once again, you'll have to
+        those changes you don't yet have.  And once again, you need
          build, test, and <command>svn commit</command> the local
          modifications to your branch.</para>

@@ -1099,9 +1099,9 @@
            <command>svn proplist --recursive</command> when dealing with
            large amounts of subtree mergeinfo, see
            <xref  
linkend="svn.branchemerge.basicmerging.stayinsync.subtree"/>
-          . The formatted output produced by using the
+          . The formatted output produced by the
            <option>--verbose</option> option with either of these
-          subcommands can be very helpful in these cases.</para>
+          subcommands is often very helpful in these cases.</para>
        </tip>

        <para>The <literal>svn:mergeinfo</literal> property is
@@ -1131,7 +1131,7 @@
          track of what was merged.</para>

        <para>Subversion also provides a subcommand, <command>svn
-        mergeinfo</command>, which can be helpful in seeing not only
+        mergeinfo</command>, which is helpful in seeing not only
          which changesets a directory has absorbed, but also which
          changesets it's still eligible to receive.  This gives a sort
          of preview of which changes a subsequent <command>svn
@@ -1164,9 +1164,9 @@
        </informalexample>

        <para>The <command>svn mergeinfo</command> command requires
-        a <quote>source</quote> URL (where the changes would be coming
+        a <quote>source</quote> URL (where the changes would come
          from), and takes an optional <quote>target</quote> URL (where
-        the changes would be merged to).  If no target URL is given,
+        the changes would merge to).  If no target URL is given,
          it assumes that the current working directory is the
          target.  In the prior example, because we're querying our
          branch working copy, the command assumes we're interested in
@@ -1350,7 +1350,7 @@
            --depth=empty  
<replaceable>/path/to/merge/target</replaceable></userinput>
            to see only the changes to the immediate target of your
            merge.  If your merge target was a directory, only property
-          differences will be displayed.  This is a handy way to see
+          differences are displayed.  This is a handy way to see
            the changes to the
            <literal>svn:mergeinfo</literal> property recorded by the
            merge operation, which will remind you about what you've
@@ -1360,8 +1360,8 @@
        <para>Of course, the best way to preview a merge operation is to
          just do it!  Remember, running <command>svn merge</command>
          isn't an inherently risky thing (unless you've made local
-        modifications to your working copy—but we've already
-        stressed that you shouldn't be merging into such an
+        modifications to your working copy—but we already
+        stressed that you shouldn't merge into such an
          environment).  If you don't like the results of the merge,
          simply run <userinput>svn revert . -R</userinput> to revert
          the changes from your working copy and retry the command with
@@ -1495,7 +1495,7 @@
          two-dimensional coordinate system.  The first coordinate is a
          particular revision tree, and the second coordinate is a path
          within that tree.  So every version of your file or directory
-        can be defined by a specific coordinate pair.  (Remember the
+        is defined by a specific coordinate pair.  (Remember the
          <quote>peg revision</quote>
          syntax—foo.c at 224—mentioned back in
          <xref linkend="svn.advanced.pegrevs"/>.)</para>
@@ -1766,8 +1766,8 @@

        <warning>
          <para>Did you notice how, in the last example, the merge
-          invocation caused two distinct ranges of merges to be
-          applied?  The <command>svn merge</command> command applied
+          invocation merged two distinct ranges?
+          The <command>svn merge</command> command applied
            two independent patches to your working copy to skip over
            changeset 355, which your branch already contained.  There's
            nothing inherently wrong with this, except that it has the
@@ -1910,14 +1910,14 @@

        <para>The first syntax lays out all three arguments explicitly,
          naming each tree in the form <emphasis>URL at REV</emphasis> and
-        naming the working copy target.  The second syntax can be used
+        naming the working copy target.  The second syntax is used
          as a shorthand for situations when you're comparing two
          different revisions of the same URL.  The last syntax shows
          how the working copy argument is optional; if omitted, it
          defaults to the current directory.</para>

        <para>While the first example shows the <quote>full</quote>
-        syntax of <command>svn merge</command>, it needs to be used
+        syntax of <command>svn merge</command>, use it
          very carefully;  it can result in merges which do not record
          any <literal>svn:mergeinfo</literal> metadata at all.  The
          next section talks a bit more about this.</para>
@@ -1939,9 +1939,9 @@
            <term>Merging unrelated sources</term>
            <listitem>
              <para>If you ask <command>svn merge</command> to compare
-              two URLs that aren't related to each other, a patch will
-              still be generated and applied to your working copy, but
-              no merging metadata will be created.  There's no common
+              two URLs that aren't related to each other, a patch is
+              still generated and applied to your working copy, but
+              no merging metadata is created.  There's no common
                history between the two sources, and
                future <quote>smart</quote> merges depend on that common
                history.</para>
@@ -1954,7 +1954,7 @@
              <para>While it's possible to run a command such
                as <userinput>svn merge -r 100:200
                 
<replaceable>http://svn.foreignproject.com/repos/trunk</replaceable></userinput>,
-              the resultant patch will also lack any historical merge
+              the resultant patch also lacks any historical merge
                metadata.  At the time of this writing, Subversion has no
                way of representing different repository URLs within
                the <literal>svn:mergeinfo</literal> property.</para>
@@ -2167,9 +2167,9 @@
        <title>Blocking Changes</title>

        <para>Sometimes there's a particular changeset that you don't
-        want to be automatically merged.  For example, perhaps your
+        want automatically merged.  For example, perhaps your
          team's policy is to do new development work on
-        <filename>/trunk</filename>, but to be more conservative about
+        <filename>/trunk</filename>, but is more conservative about
          backporting changes to a stable branch you use for releasing
          to the public.  On one extreme, you can manually cherrypick
          single changesets from the trunk to the branch—just the
@@ -2212,7 +2212,7 @@

        <para>Since Subversion 1.7, <option>--record-only</option>
          merges are transitive.  This means that, in addition to recording
-        mergeinfo describing the merge to be blocked, any
+        mergeinfo describing the blocked revision(s), any
          <literal>svn:mergeinfo</literal> property differences in the
          merge source are also applied.  For example, let's say we want to
          block the 'frazzle' feature from ever being merged from
@@ -2338,7 +2338,7 @@

        <para>So what can be done about this? We need to make sure that
          Subversion does not try to merge revision <emphasis>X</emphasis>
-        into the branch. This can be done using the
+        into the branch. This is done using the
          <option>--record-only</option> merge option, which was introduced
          in <xref linkend="svn.branchmerge.advanced.blockchanges"/>.</para>

@@ -2887,8 +2887,8 @@
      <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
-      as appropriate.  When you commit, your local changes will still
-      be applied as a single, atomic change to the repository.</para>
+      as appropriate.  When you commit, your local changes are still
+      applied as a single, atomic change to the repository.</para>

      <para>Note that while it's okay for your working copy to reflect a
        mixture of repository locations, these locations must all be
@@ -2957,8 +2957,8 @@
        <para>Have you ever found yourself making some complex edits (in
          your <filename>/trunk</filename> working copy) and suddenly
          realized, <quote>Hey, these changes ought to be in their own
-        branch?</quote> A great technique to do this can be summarized
-        in two steps:</para>
+        branch?</quote> There is a great two step technique to do
+        this:</para>

        <informalexample>
          <screen>
@@ -3070,7 +3070,7 @@
      <sect2 id="svn.branchmerge.tags.mkcomplex">
        <title>Creating a Complex Tag</title>

-      <para>Sometimes you may want your <quote>snapshot</quote> to be
+      <para>Sometimes you may want a <quote>snapshot</quote> that is
          more complicated than a single directory at a single
          revision.</para>

@@ -3206,15 +3206,15 @@
          you don't like the way things are organized in the repository,
          just juggle the directories around.</para>

-      <para>Remember, though, that while moving directories may be
-        easy to do, you need to be considerate of your users as well.
-        Your juggling can be disorienting to users with existing
+      <para>Remember, though, that while moving directories is
+        easy to do, you need to be considerate of other users as well.
+        Your juggling can disorient users with existing
          working copies.  If a user has a working copy of a particular
-        repository directory, your <command>svn move</command>
-        operation might remove the path from the latest revision.
-        When the user next runs <command>svn update</command>, she will
-        be told that her working copy represents a path that no
-        longer exists, and the user will be forced to <command>svn
+        repository directory and your <command>svn move</command>
+        subcommand removes the path from the latest revision, then
+        when the user next runs <command>svn update</command>, she is
+        told that her working copy represents a path that no
+        longer exists.  She is then forced to <command>svn
          switch</command> to the new location.</para>

      </sect2>
@@ -3246,7 +3246,7 @@
          <literal>HEAD</literal> revision, no longer distracting
          anyone.  If you use <command>svn checkout</command>,
          <command>svn switch</command>, or <command>svn list</command>
-        to examine an earlier revision, you'll still be able to see
+        to examine an earlier revision, you can still see
          your old branch.</para>

        <para>If browsing your deleted directory isn't enough, you can
@@ -3459,12 +3459,12 @@
          changes to the branch.  Make up a policy: once a week, merge
          the last week's worth of trunk changes to the branch.</para>

-      <para>At some point, you'll be ready to merge the
-        <quote>synchronized</quote> feature branch back to the trunk.
-        To do this, begin by doing a final merge of the latest trunk
+      <para>When you are eventually ready to merge the
+        <quote>synchronized</quote> feature branch back to the trunk,
+        begin by doing a final merge of the latest trunk
          changes to the branch.  When that's done, the latest versions
-        of branch and trunk will be absolutely identical except for
-        your branch changes.  You would then merge back with
+        of branch and trunk are absolutely identical except for
+        your branch changes.  You then merge back with
          the <option>--reintegrate</option> option:</para>

        <informalexample>




More information about the svnbook-dev mailing list