[svnbook commit] r2003 - trunk/src/pt_BR/book

ccidral svnbook-dev at red-bean.com
Wed Feb 15 09:35:13 CST 2006


Author: ccidral
Date: Wed Feb 15 09:35:02 2006
New Revision: 2003

Modified:
   trunk/src/pt_BR/book/ch02.xml
   trunk/src/pt_BR/book/ch03.xml
   trunk/src/pt_BR/book/ch05.xml
   trunk/src/pt_BR/book/ch07.xml
   trunk/src/pt_BR/book/ch08.xml

Log:
Merge updates from en up to 2002.


Modified: trunk/src/pt_BR/book/ch02.xml
==============================================================================
--- trunk/src/pt_BR/book/ch02.xml	(original)
+++ trunk/src/pt_BR/book/ch02.xml	Wed Feb 15 09:35:02 2006
@@ -83,19 +83,20 @@
         repository.</para>
 
       <para>Consider the scenario shown in <xref
-        linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>.  Suppose we have two co-workers,
-        Harry and Sally.  They each decide to edit the same repository
-        file at the same time.  If Harry saves his changes to the
-        repository first, then it's possible that (a few moments
-        later) Sally could accidentally overwrite them with her own
-        new version of the file.  While Harry's version of the file
-        won't be lost forever (because the system remembers every
-        change), any changes Harry made <emphasis>won't</emphasis> be
-        present in Sally's newer version of the file, because she
-        never saw Harry's changes to begin with.  Harry's work is
-        still effectively lost—or at least missing from the
-        latest version of the file—and probably by accident.
-        This is definitely a situation we want to avoid!</para>
+        linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>.
+        Suppose we have two co-workers, Harry and Sally.  They each
+        decide to edit the same repository file at the same time.  If
+        Harry saves his changes to the repository first, then it's
+        possible that (a few moments later) Sally could accidentally
+        overwrite them with her own new version of the file.  While
+        Harry's version of the file won't be lost forever (because the
+        system remembers every change), any changes Harry made
+        <emphasis>won't</emphasis> be present in Sally's newer version
+        of the file, because she never saw Harry's changes to begin
+        with.  Harry's work is still effectively lost—or at
+        least missing from the latest version of the file—and
+        probably by accident.  This is definitely a situation we want
+        to avoid!</para>
 
       <figure id="svn.basic.vsn-models.problem-sharing.dia-1">
         <title>The problem to avoid</title>
@@ -109,19 +110,19 @@
       <title>The Lock-Modify-Unlock Solution</title>
       
       <para>Many version control systems use a
-        <firstterm>lock-modify-unlock</firstterm> model to address
-        this problem.  In such a system, the repository allows only
-        one person to change a file at a time.  First Harry must
-        <quote>lock</quote> the file before he can begin making
-        changes to it.  Locking a file is a lot like borrowing a book
-        from the library; if Harry has locked a file, then Sally
-        cannot make any changes to it.  If she tries to lock the file,
-        the repository will deny the request.  All she can do is read
-        the file, and wait for Harry to finish his changes and release
-        his lock.  After Harry unlocks the file, his turn is over, and
-        now Sally can take her turn by locking and editing.  <xref
-        linkend="svn.basic.vsn-models.lock-unlock.dia-1"/> demonstrates this simple
-        solution.</para>
+        <firstterm>lock-modify-unlock</firstterm> model to address the
+        problem of many authors clobbering each other's work.  In this
+        model, the repository allows only one person to change a file
+        at a time.  This exclusivity policy is managed using locks.
+        Harry must <quote>lock</quote> a file before he can begin
+        making changes to it.  If Harry has locked a file, then Sally
+        cannot also lock it, and therefore cannot make any changes to
+        that file.  All she can do is read the file, and wait for
+        Harry to finish his changes and release his lock.  After Harry
+        unlocks the file, Sally can take her turn by locking and
+        editing the file.  <xref
+        linkend="svn.basic.vsn-models.lock-unlock.dia-1"/>
+        demonstrates this simple solution.</para>
       
       <figure id="svn.basic.vsn-models.lock-unlock.dia-1">
         <title>The lock-modify-unlock solution</title>

Modified: trunk/src/pt_BR/book/ch03.xml
==============================================================================
--- trunk/src/pt_BR/book/ch03.xml	(original)
+++ trunk/src/pt_BR/book/ch03.xml	Wed Feb 15 09:35:02 2006
@@ -128,32 +128,35 @@
         <varlistentry>
           <term>HEAD</term>
           <listitem>
-            <para>The latest revision in the repository.</para>
+            <para>The latest (or <quote>youngest</quote>) revision in
+              the repository.</para>
           </listitem>
         </varlistentry>
         
         <varlistentry>
           <term>BASE</term>
           <listitem>
-            <para>The <quote>pristine</quote> revision of an item in a
-              working copy.</para>
+            <para>The revision number of an item in a working copy.
+              If the item has been locally modified, the <quote>BASE
+              version</quote> refers to the way the item appears
+              without those local modifications.</para>
           </listitem>
         </varlistentry>
         
         <varlistentry>
           <term>COMMITTED</term>
           <listitem>
-            <para>The last revision in which an item changed before (or
-              at) <literal>BASE</literal>.</para>
+            <para>The most recent revision prior to, or equal to,
+              <literal>BASE</literal>, in which an item changed.</para>
           </listitem>
         </varlistentry>
         
         <varlistentry>
           <term>PREV</term>
           <listitem>
-            <para>The revision just <emphasis>before</emphasis> the last
-              revision in which an item changed.  (Technically,
-              <literal>COMMITTED</literal> - 1.)</para>
+            <para>The revision immediately <emphasis>before</emphasis>
+              the last revision in which an item changed.
+              (Technically, <literal>COMMITTED</literal> - 1.)</para>
           </listitem>
         </varlistentry>
         

Modified: trunk/src/pt_BR/book/ch05.xml
==============================================================================
--- trunk/src/pt_BR/book/ch05.xml	(original)
+++ trunk/src/pt_BR/book/ch05.xml	Wed Feb 15 09:35:02 2006
@@ -1961,7 +1961,7 @@
           data need to remain on the live site, which need to be
           backed up, and which can be safely removed.  This section is
           specific to Berkeley DB;  FSFS repositories have no extra
-          data that be cleaned up or reclaimed.</para>
+          data to be cleaned up or reclaimed.</para>
 
         <para>Until recently, the largest offender of disk space usage
           with respect to Subversion repositories was the log files to

Modified: trunk/src/pt_BR/book/ch07.xml
==============================================================================
--- trunk/src/pt_BR/book/ch07.xml	(original)
+++ trunk/src/pt_BR/book/ch07.xml	Wed Feb 15 09:35:02 2006
@@ -453,7 +453,7 @@
             <term><literal>store-auth-creds</literal></term>
             <listitem>
               <para>This setting is the same as
-                <literal>store-passwords</literal>, except that
+                <literal>store-passwords</literal>, except that it
                 enables or disables disk-caching of
                 <emphasis>all</emphasis> authentication information:
                 usernames, passwords, server certificates, and any
@@ -592,8 +592,8 @@
               <para>This variable sets the default character set
                 encoding for commit log messages.  It's a permanent
                 form of the <option>--encoding</option> option (see
-                <xref linkend="svn.ref.svn.sw"/>.)  The Subversion
-                repository stores log messages in UTF8, and assumes
+                <xref linkend="svn.ref.svn.sw"/>).  The Subversion
+                repository stores log messages in UTF-8, and assumes
                 that your log message is written using your operating
                 system's native locale.  You should specify a
                 different encoding if your commit messages are written
@@ -1998,7 +1998,7 @@
           This behavior is also semi-permanently tweakable, by setting
           <literal>no-unlock = yes</literal> in your run-time
           <filename>config</filename> file (see <xref
-          linkend="svn.advanced.confarea"/>.)</para>
+          linkend="svn.advanced.confarea"/>).</para>
 
       <para>Of course, locking a file doesn't oblige one to commit a
         change to it.  The lock can be released at any time with a

Modified: trunk/src/pt_BR/book/ch08.xml
==============================================================================
--- trunk/src/pt_BR/book/ch08.xml	(original)
+++ trunk/src/pt_BR/book/ch08.xml	Wed Feb 15 09:35:02 2006
@@ -1028,9 +1028,14 @@
                          % (os.path.basename(sys.argv[0])))
         sys.exit(1)
 
+    # Canonicalize (enough for Subversion, at least) the repository path.
+    repos_path = os.path.normpath(sys.argv[1])
+    if repos_path == '.': 
+        repos_path = ''
+
     # Call the app-wrapper, which takes care of APR initialization/shutdown
     # and the creation and cleanup of our top-level memory pool.
-    svn.core.run_app(crawl_youngest, os.path.normpath(sys.argv[1]))
+    svn.core.run_app(crawl_youngest, repos_path)
 </programlisting>
       </example>
 
@@ -1146,9 +1151,14 @@
     if len(args) != 1:
         usage_and_exit(2)
             
+    # Canonicalize (enough for Subversion, at least) the working copy path.
+    wc_path = os.path.normpath(args[0])
+    if wc_path == '.': 
+        wc_path = ''
+
     # Call the app-wrapper, which takes care of APR initialization/shutdown
     # and the creation and cleanup of our top-level memory pool.
-    svn.core.run_app(do_status, os.path.normpath(args[0]), verbose)
+    svn.core.run_app(do_status, wc_path, verbose)
 </programlisting>
       </example>
 
@@ -1156,7 +1166,7 @@
         the level of attention given to the core Subversion modules.
         However, there have been significant efforts towards creating
         functional bindings for Python, Perl, and Ruby.  To some extent,
-        the work done preparing the SWIG interface files for the these
+        the work done preparing the SWIG interface files for these
         languages is reusable in efforts to generate bindings for other
         languages supported by SWIG (which includes versions of C#,
         Guile, Java, MzScheme, OCaml, PHP, Tcl, and others).




More information about the svnbook-dev mailing list