[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