[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