[svnbook commit] r3115 - trunk/src/en/book

sussman noreply at red-bean.com
Wed Jun 11 14:30:44 CDT 2008


Author: sussman
Date: Wed Jun 11 14:30:44 2008
New Revision: 3115

Log:
* ch04-branching-and-merging.xml:  some suggestions from Daniel Shahaf <d.s at daniel.shahaf.co.il>.

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	Wed Jun 11 14:30:44 2008
@@ -2152,7 +2152,7 @@
     <para>However, people often want to give more human-friendly names
       to tags, such as <literal>release-1.0</literal>.  And they want
       to make snapshots of smaller subdirectories of the filesystem.
-      After all, it's not so easy to remember that release-1.0 of a
+      After all, it's not so easy to remember that release 1.0 of a
       piece of software is a particular subdirectory of revision
       4822.</para>
 
@@ -2178,11 +2178,11 @@
         it doesn't, you can create it using <command>svn
         mkdir</command>.)  After the copy completes, the new
         <filename>release-1.0</filename> directory is forever a
-        snapshot of how the project looked in the
-        <literal>HEAD</literal> revision at the time you made the
-        copy.  Of course you might want to be more precise about
-        exactly which revision you copy, in case somebody else may
-        have committed changes to the project when you weren't
+        snapshot of how the <filename>/trunk</filename> directory
+        looked in the <literal>HEAD</literal> revision at the time you
+        made the copy.  Of course you might want to be more precise
+        about exactly which revision you copy, in case somebody else
+        may have committed changes to the project when you weren't
         looking.  So if you know that revision 901 of
         <filename>/calc/trunk</filename> is exactly the snapshot you
         want, you can specify it by passing <option>-r 901</option> to
@@ -2231,12 +2231,13 @@
         copy that is designed to have specific features and bug fixes.
         You can accomplish this by selectively backdating files or
         directories to particular revisions (using <command>svn update
-        -r</command> liberally) or by switching files and directories
-        to particular branches (making use of <command>svn
-        switch</command>).  When you're done, your working copy is a
-        hodgepodge of repository locations from different revisions.
-        But after testing, you know it's the precise combination of
-        data you need.</para>
+        -r</command> liberally), by switching files and directories to
+        particular branches (making use of <command>svn
+        switch</command>), or even just by making a bunch of local
+        changes.  When you're done, your working copy is a hodgepodge
+        of repository locations from different revisions.  But after
+        testing, you know it's the precise combination of data you
+        need to tag.</para>
 
       <para>Time to make a snapshot.  Copying one URL to another won't
         work here.  In this case, you want to make a snapshot of your
@@ -2250,7 +2251,9 @@
 $ ls
 my-working-copy/
 
-$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag
+$ svn copy my-working-copy \
+           http://svn.example.com/repos/calc/tags/mytag \
+           -m "Tag my existing working copy state."
 
 Committed revision 940.
 </screen>
@@ -2258,16 +2261,16 @@
       <para>Now there is a new directory in the repository,
         <filename>/calc/tags/mytag</filename>, which is an exact
         snapshot of your working copy—mixed revisions, URLs,
-        and all.</para>
+        local changes and all.</para>
 
       <para>Other users have found interesting uses for this feature.
         Sometimes there are situations where you have a bunch of local
         changes made to your working copy, and you'd like a
         collaborator to see them.  Instead of running <command>svn
         diff</command> and sending a patch file (which won't capture
-        tree changes, symlink changes, or changes in properties), you can
-        instead use <command>svn copy</command> to <quote>upload</quote>
-        your working copy to a private area of the repository.  Your
+        directory, symlink, or property changes), you can instead
+        use <command>svn copy</command> to <quote>upload</quote> your
+        working copy to a private area of the repository.  Your
         collaborator can then either check out a verbatim copy of your
         working copy or use <command>svn merge</command> to receive
         your exact changes.</para>




More information about the svnbook-dev mailing list