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

cmpilato noreply at red-bean.com
Fri Jan 5 09:39:36 CST 2007


Author: cmpilato
Date: Fri Jan  5 09:39:36 2007
New Revision: 2614

Modified:
   trunk/src/en/book/ch-advanced-topics.xml

Log:
* src/en/book/ch-advanced-topics.xml
  Move the history of content type recognition into a sidebar; rename
  Selective Versioning to Ignoring Unversioned Items (despite my lack
  of enthusiasm for the title); make some other minor tweaks based on
  Fitz's review.


Modified: trunk/src/en/book/ch-advanced-topics.xml
==============================================================================
--- trunk/src/en/book/ch-advanced-topics.xml	(original)
+++ trunk/src/en/book/ch-advanced-topics.xml	Fri Jan  5 09:39:36 2007
@@ -850,67 +850,76 @@
     <sect2 id="svn.advanced.props.special.mime-type">
       <title>File Content Type</title>
       
-      <para>Software programs on most modern operating systems make
-        assumptions about the type and format of the contents of a
-        file by the file's name, specifically its file extension.  For
-        example, files whose names end in <filename>.txt</filename>
-        are generally assumed to be human-readable, able to be
-        understood by simple perusal rather than requiring complex
-        processing to decipher.  Files whose names end in
-        <filename>.png</filename>, on the other hand, are assumed to
-        be of the Portable Network Graphics type—not
-        human-readable at all, and sensible only when interpreted by
-        software which understands the PNG format and can render the
-        information in that format as a raster image.</para>
-
-      <para>Unfortunately, some of those extensions have changed
-        meanings over time.  When personal computers first appeared, a
-        file named <filename>README.DOC</filename> would have almost
-        certainly been a plaintext file, just like today's
-        <filename>.txt</filename> files.  But by the mid-1990's,
-        you could almost bet that a file of that name would not be a
-        plaintext file at all, but instead a Microsoft Word document
-        with a proprietary, non-human-readable format.  But this
-        change didn't occur overnight—there was certainly a
-        period of confusion for computer users over what exactly they
-        had in hand when they saw a <filename>.DOC</filename> file.
-        <footnote>
-          <para>You think that was rough?  During that same era,
-            WordPerfect also used <filename>.DOC</filename> for their
-            proprietary file format's preferred extension!</para>
-        </footnote>
-      </para>
+      <para>Subversion joins the ranks of the many applications which
+        recognize and make use of Multipurpose Internet Mail
+        Extensions (MIME) content types.  Besides being a
+        general-purpose storage location for a file's content type,
+        the value of the <literal>svn:mime-type</literal> file
+        property determines some behavioral characteristics of
+        Subversion itself.</para>
 
-      <para>The popularity of computer networking cast still more
-        doubt on the mapping between a file's name and its content.
-        With information being served across networks and generated
-        dynamically by server-side scripts, there was often no real
-        file <foreignphrase>per se</foreignphrase> to speak of, and
-        therefore no file name.  Web servers, for example, needed some
-        other way to tell browsers what they were downloading so the
-        browser could do something intelligent with that information,
-        whether that was to display the data using a program
-        registered to handle that data type, or to prompt the user for
-        where on the client machine to store the downloaded
-        data.</para>
-
-      <para>Eventually, a standard emerged for, among other things,
-        describing the contents of a data stream.  In 1996, RFC2045
-        was published, the first of five RFCs describing Multipurpose
-        Internet Mail Extensions (MIME).  In it, this RFC describes
-        the concept of media types and subtypes, and recommends a
-        syntax for the representation of those types.  Today, MIME
-        media types—or, MIME types— are used almost
-        universally across e-mail applications, Web servers, and other
-        software as the <foreignphrase>de facto</foreignphrase>
-        mechanism for clearing up the file content confusion.</para>
-
-      <para>Subversion joins the ranks of applications which recognize
-        and make use of MIME types.  Besides being a general-purpose
-        storage location for a file's content type, the value of the
-        <literal>svn:mime-type</literal> file property determines some
-        behavioral characteristics of Subversion itself.</para>
+      <sidebar>
+        <title>Identifying File Types</titles>
+    
+        <para>Software programs on most modern operating systems make
+          assumptions about the type and format of the contents of a
+          file by the file's name, specifically its file extension.
+          For example, files whose names end in
+          <filename>.txt</filename> are generally assumed to be
+          human-readable, able to be understood by simple perusal
+          rather than requiring complex processing to decipher.  Files
+          whose names end in <filename>.png</filename>, on the other
+          hand, are assumed to be of the Portable Network Graphics
+          type—not human-readable at all, and sensible only when
+          interpreted by software which understands the PNG format and
+          can render the information in that format as a raster
+          image.</para>
+
+        <para>Unfortunately, some of those extensions have changed
+          meanings over time.  When personal computers first appeared,
+          a file named <filename>README.DOC</filename> would have
+          almost certainly been a plaintext file, just like today's
+          <filename>.txt</filename> files.  But by the mid-1990's, you
+          could almost bet that a file of that name would not be a
+          plaintext file at all, but instead a Microsoft Word document
+          with a proprietary, non-human-readable format.  But this
+          change didn't occur overnight—there was certainly a
+          period of confusion for computer users over what exactly
+          they had in hand when they saw a <filename>.DOC</filename>
+          file.
+          <footnote>
+            <para>You think that was rough?  During that same era,
+              WordPerfect also used <filename>.DOC</filename> for their
+              proprietary file format's preferred extension!</para>
+          </footnote>
+        </para>
+
+        <para>The popularity of computer networking cast still more
+          doubt on the mapping between a file's name and its content.
+          With information being served across networks and generated
+          dynamically by server-side scripts, there was often no real
+          file <foreignphrase>per se</foreignphrase> to speak of, and
+          therefore no file name.  Web servers, for example, needed
+          some other way to tell browsers what they were downloading
+          so the browser could do something intelligent with that
+          information, whether that was to display the data using a
+          program registered to handle that data type, or to prompt
+          the user for where on the client machine to store the
+          downloaded data.</para>
+
+        <para>Eventually, a standard emerged for, among other things,
+          describing the contents of a data stream.  In 1996, RFC2045
+          was published, the first of five RFCs describing MIME.  In
+          it, this RFC describes the concept of media types and
+          subtypes, and recommends a syntax for the representation of
+          those types.  Today, MIME media types—or, MIME
+          types— are used almost universally across e-mail
+          applications, Web servers, and other software as the
+          <foreignphrase>de facto</foreignphrase> mechanism for
+          clearing up the file content confusion.</para>
 
+      </sidebar>
+    
       <para>For example, one of the benefits that Subversion typically
         provides is contextual, line-based merging of changes received
         from the server during an update into your working file.  But
@@ -1107,7 +1116,7 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.advanced.props.special.ignore">
-    <title>Selective Versioning</title>
+    <title>Ignoring Unversioned Items</title>
 
     <para>In any given working copy there is a good chance that
       alongside all those versioned files and directories are other
@@ -1135,7 +1144,7 @@
       directories—its output can get quite noisy where many of
       these things exist.</para>
 
-    <para>So Subversion provides a pair of ways for telling it which
+    <para>So Subversion provides two ways for telling it which
       files you would prefer that it simply disregard.  One of the
       ways involves the use of Subversion's runtime configuration
       system (see <xref linkend="svn.advanced.confarea" />), and
@@ -1183,7 +1192,7 @@
       <para>Subversion's support for ignorable file patterns extends
         only to the one-time process of adding unversioned
         files and directories to version control.  Once an object is
-        under Subversion's watchkeep, the ignore pattern mechanisms no
+        under Subversion's control, the ignore pattern mechanisms no
         longer apply to it.  In other words, don't expect Subversion
         to avoid committing changes you've made to a versioned file
         simply because that file's name matches an ignore
@@ -1294,6 +1303,7 @@
 
     <screen>
 $ svn status --no-ignore
+ M     calc
  M     calc/button.c
 I      calc/calculator
 ?      calc/data.c
@@ -1780,7 +1790,7 @@
         can cause a repository to be <quote>wedged</quote>, as
         described in <xref linkend="svn.reposadmin.maint.recovery"/>.</para> 
 
-      <para>You can generally forget about these other sorts of lock,
+      <para>You can generally forget about these other kinds of locks
         until something goes wrong that requires you to care about
         them.  In this book, <quote>lock</quote> means the first sort
         unless the contrary is either clear from context or explicitly
@@ -2248,7 +2258,7 @@
         something is strange when she opens the file for editing.
         Many applications alert users immediately when a read-only
         file is opened for editing.  And nearly all applications would
-        at least prevert her from saving changes to the file.  This
+        at least prevent her from saving changes to the file.  This
         reminds her to lock the file before editing, whereby she
         discovers the pre-existing lock:</para>
 




More information about the svnbook-dev mailing list