[svnbook commit] r2397 - trunk/src/es/book

gradha noreply at red-bean.com
Thu Aug 24 16:08:06 CDT 2006


Author: gradha
Date: Thu Aug 24 16:08:05 2006
New Revision: 2397

Modified:
   trunk/src/es/book/ch05.xml

Log:
Book Spanish. Translated 37 paragraphs.

Modified: trunk/src/es/book/ch05.xml
==============================================================================
--- trunk/src/es/book/ch05.xml	(original)
+++ trunk/src/es/book/ch05.xml	Thu Aug 24 16:08:05 2006
@@ -1854,146 +1854,153 @@
         bloqueo antes de que se les permita continuar accediendo
         a esa sección de la base de datos.</para>
 
-      <para>In the course of using your Subversion repository, fatal
-        errors (such as running out of disk space or available memory)
-        or interruptions can prevent a process from having the chance to
-        remove the locks it has placed in the database.  The result is
-        that the back-end database system gets <quote>wedged</quote>.
-        When this happens, any attempts to access the repository hang
-        indefinitely (since each new accessor is waiting for a lock to
-        go away—which isn't going to happen).</para>
-
-      <para>First, if this happens to your repository, don't panic.
-        Subversion's filesystem takes advantage of database
-        transactions and checkpoints and pre-write journaling to
-        ensure that only the most catastrophic of events
+      <para>A lo largo del uso de su repositorio Subversion, los errores
+        fatales (como quedarse sin espacio en disco duro o sin memoria)
+        o las interrupciones pueden evitar que un proceso tenga la
+        oportunidad de eliminar los bloqueos que inició sobre la base
+        de datos. El resultado es que el motor de la base de datos del
+        sistema se <quote>wedged</quote><!-- TODO buscar término para
+        esto -->.  Cuando esto ocurre, cualquier intento de acceso al
+        repositorio se bloqueará de manera indefinida (dado que cada nuevo
+        cliente estará esperando a que los bloqueos desaparezcan—lo
+        cual no va a ocurrir).</para>
+
+      <para>Primero, si esto ocurre en su repositorio, no se preocupe.
+        El sistema de ficheros de Subversio ntiene la ventaja de
+        usar transacciones, puntos de control y ficheros de registro
+        pre-escritura para asegurarse de que sólo los eventos más
+        catastróficos
         <footnote>
-          <para>E.g.: hard drive + huge electromagnet = disaster.</para>
+          <para>Ej: disco duro + enorme electroimán = desastre.</para>
         </footnote>
-        can permanently destroy a database environment.  A
-        sufficiently paranoid repository administrator will be making
-        off-site backups of the repository data in some fashion, but
-        don't call your system administrator to restore a backup tape
-        just yet.</para>
-
-      <para>Secondly, use the following recipe to attempt to
-        <quote>unwedge</quote> your repository:</para>
-   
+        pueden destruir de manera permanente el entorno de la base de
+        datos. Un administrador de repositorio suficientemente paranóico
+        estará haciendo copias de seguridad del repositorio en otra
+        máquina separada de alguna manera, pero todavía no es el momento
+        de llamarle para que realice la restauración de una cinta.</para>
+
+      <para>En segundo lugar, use la siguiente receta para intentar
+        <quote>unwedge</quote> su repositorio:</para>
+
       <orderedlist>
         <listitem>
-          <para>Make sure that there are no processes accessing (or
-            attempting to access) the repository.  For networked
-            repositories, this means shutting down the Apache HTTP
-            Server, too.</para>
+          <para>Asegúrese de que no hay procesos accediendo (o intentando
+            acceder) al repositorio.  Para repositorios en red, esto
+            también sigifica tener que desconectar el servidor HTTP
+            Apache.</para>
         </listitem>
-        <listitem> 
-          <para>Become the user who owns and manages the repository.
-            This is important, as recovering a repository while
-            running as the wrong user can tweak the permissions of the
-            repository's files in such a way that your repository will
-            still be inaccessible even after it is 
+        <listitem>
+          <para>Conviértase en el usuario que posee y gestiona el
+            repositorio.  Esto es importante, dado que recuperar el
+            repositorio poseyendo el usuario erróneo puede alterar
+            los permisos de los ficheros del repositorio de tal
+            modo que será inaccesible incluso después de haberlo
             <quote>unwedged</quote>.</para>
         </listitem>
         <listitem>
-          <para>Run the command <command>svnadmin recover
-            /path/to/repos</command>.  You should see output like
-            this:</para>
-              
+          <para>Ejecute el comando <command>svnadmin recover
+            /ruta/al/repositorio</command>. Debería ver algo como
+            esto:</para>
+
           <screen>
 Please wait; recovering the repository may take some time...
 
 Recovery completed.
 The latest repos revision is 19.
 </screen>
-          <para>This command may take many minutes to complete.</para>
+          <para>Este comando puede tardar muchos minutos en completar
+            su tarea.</para>
         </listitem>
         <listitem>
-          <para>Restart the Subversion server.</para>
+          <para>Rearranque el servidor Subversion.</para>
         </listitem>
       </orderedlist>
-            
-      <para>This procedure fixes almost every case of repository
-        lock-up.  Make sure that you run this command as the user that
-        owns and manages the database, not just as
-        <literal>root</literal>.  Part of the recovery process might
-        involve recreating from scratch various database files (shared
-        memory regions, for example).  Recovering as
-        <literal>root</literal> will create those files such that they
-        are owned by <literal>root</literal>, which means that even
-        after you restore connectivity to your repository, regular
-        users will be unable to access it.</para>
-
-      <para>If the previous procedure, for some reason, does not
-        successfully unwedge your repository, you should do two
-        things.  First, move your broken repository out of the way and
-        restore your latest backup of it.  Then, send an email to the
-        Subversion user list (at
-        <email>users at subversion.tigris.org</email>) describing your
-        problem in detail.  Data integrity is an extremely high
-        priority to the Subversion developers.</para>
+
+      <para>Este prodecimiento corrige casi todos los casos de bloqueos
+        del repositorio. Asegúrese de ejecutar este comando como el
+        usuario a quien le pertenece la base de datos y la gestiona,
+        no basta con ser <literal>root</literal>.  Parte del proceso de
+        recuperación puede conllevar la regeneración de varios ficheros de
+        bases de datos (por ejemplo, regiones de memoria compartidas). Al
+        realizar la recuperación como <literal>root</literal>, éstos
+        ficheros tendrán sus permisos, lo cual significa que incluso
+        cuando recupere la conexión con el repositorio, los usuarios
+        normales no serán capaces de acceder a él.</para>
+
+      <para>Si el procedimiento anterior, por alguna razón, no consigue
+        desbloquear su repositorio, debería hacer dos cosas. En primer
+        lugar, mueva su repositorio estropeado a otro lugar y recupere
+        la última copia de seguridad que tenga del mismo. Entonces,
+        envíe un correo electrónico a la lista de usuarios de Subversion
+        (en <email>users at subversion.tigris.org</email>) describiendo
+        su problema con todo detalle. Para los desarrolladores de
+        SUbversion mantener la integridad de los datos es una prioridad
+        extremadamente alta.</para>
 
     </sect2>
 
     <!-- ***************************************************************** -->
     <sect2 id="svn-ch-5-sect-3.5">
-      <title>Migrating a Repository</title>
-    
-      <para>A Subversion filesystem has its data spread throughout
-        various database tables in a fashion generally understood by
-        (and of interest to) only the Subversion developers
-        themselves.  However, circumstances may arise that call for
-        all, or some subset, of that data to be collected into a
-        single, portable, flat file format.  Subversion provides such
-        a mechanism, implemented in a pair of
-        <command>svnadmin</command> subcommands:
-        <literal>dump</literal> and <literal>load</literal>.</para>
-
-      <para>The most common reason to dump and load a Subversion
-        repository is due to changes in Subversion itself.  As
-        Subversion matures, there are times when certain changes made
-        to the back-end database schema cause Subversion to be
-        incompatible with previous versions of the repository.  The
-        recommended course of action when you are upgrading across one
-        of those compatibility boundaries is a relatively simple
-        process:</para>
-  
+      <title>Migrando un repositorio</title>
+
+      <para>Un sistema de ficheros de Subversion almacena sus datos
+        repartidos por varias tablas de bases de datos de una forma
+        generalmente comprensible (y sólo de interés) para los propios
+        desarrolladores de Subversion. No obstante, pueden darse
+        las circunstancias adecuadas que requieran que todos los datos,
+        o un subconjunto de los mismos, sean recopilados en un fichero
+        único, portable, y de formato simple. Subversion proporciona
+        tal mecanismo implementado como la pareja de subcomandos
+        de <command>svnadmin</command>: <literal>dump</literal> y
+        <literal>load</literal>.</para>
+
+      <para>La razón más comun para volcar y recargar un repositorio
+        de Subversion es por cambios en el propio Subversion. A medida
+        que Subversion madura, hay momentos en los que hace falta
+        realizar cambios al esquema del motor de la base de datos que
+        hacen a Subversion incompatible con versiones anteriores de su
+        repositorio. La acción recomendada para actualizarse atravesando
+        una de estas barreras de incompatiblidad es relativamente
+        simple:</para>
+
       <orderedlist>
         <listitem>
-          <para>Using your <emphasis>current</emphasis> version of
-            <command>svnadmin</command>, dump your repositories to
-            dump files.</para>
+          <para>Usando su <emphasis>actual</emphasis> versión de
+            <command>svnadmin</command>, vuelque su repositorio a
+            ficheros de volcado.</para>
         </listitem>
         <listitem>
-          <para>Upgrade to the new version of Subversion.</para>
+          <para>Actualicese a la nueva versión de Subversion.</para>
         </listitem>
         <listitem>
-          <para>Move your old repositories out of the way, and create
-            new empty ones in their place using your
-            <emphasis>new</emphasis> <command>svnadmin</command>.</para>
+          <para>Mueva sus viejos repositorios a otra parte, y
+            crée nuevos repositorios vacíos en su lugar usando su
+            <emphasis>nuevo</emphasis> <command>svnadmin</command>.</para>
         </listitem>
         <listitem>
-          <para>Again using your <emphasis>new</emphasis>
-            <command>svnadmin</command>, load your dump files into
-            their respective, just-created repositories.</para>
+          <para>Otra vez con su <command>svnadmin</command>
+            <emphasis>nuevo</emphasis>, cargue sus ficheros de volcado
+            en sus repositorios recién creados respectivamente.</para>
         </listitem>
         <listitem>
-          <para>Finally, be sure to copy any customizations from your
-            old repositories to the new ones, including
-            <filename>DB_CONFIG</filename> files and hook scripts.
-            You'll want to pay attention to the release notes for the
-            new release of Subversion to see if any changes since your
-            last upgrade affect those hooks or configuration
-            options.</para>
+          <para>Finalmente, asegúrese de copiar en los nuevos repositorios
+            cualquier personalización realizada en los antiguos,
+            incluyendo los ficheros <filename>DB_CONFIG</filename> y los
+            ficheros de ganchos. Le recomendamos que preste atención a las
+            notas de lanzamiento de la nueva versión de Subversion para
+            comprobar si algún cambio desde su última actualización afecta
+            a esos ficheros de ganchos u opciones de configuración.</para>
         </listitem>
       </orderedlist>
 
-      <para><command>svnadmin dump</command> will output a range of
-        repository revisions that are formatted using Subversion's
-        custom filesystem dump format.  The dump format is printed to
-        the standard output stream, while informative messages are
-        printed to the standard error stream.  This allows you to
-        redirect the output stream to a file while watching the status
-        output in your terminal window.  For example:</para>
+      <para><command>svnadmin dump</command> generará en su salida un
+        rango de revisiones del repositorio usando el formato propio
+        de Subvesion para volcar el sistema de ficheros.  El volcado
+        formateado será enviado al flujo estándar de salida, mientras
+        que los mensajes informativos son enviados al flujo estándar de
+        errores. Esto le permite redirigir el flujo de salida estándar
+        a un fichero mientras observa el estado del volcado en su
+        terminal. Por ejemplo:</para>
 
       <screen>
 $ svnlook youngest myrepos
@@ -2007,21 +2014,21 @@
 * Dumped revision 26.
 </screen>
 
-      <para>At the end of the process, you will have a single file
-        (<filename>dumpfile</filename> in the previous example) that
-        contains all the data stored in your repository in the
-        requested range of revisions.  Note that <command>svnadmin
-        dump</command> is reading revision trees from the repository
-        just like any other <quote>reader</quote> process would
-        (<command>svn checkout</command>, for example.)  So it's safe
-        to run this command at any time.</para>
-
-      <para>The other subcommand in the pair, <command>svnadmin
-        load</command>, parses the standard input stream as a
-        Subversion repository dump file, and effectively replays those
-        dumped revisions into the target repository for that
-        operation.  It also gives informative feedback, this time
-        using the standard output stream:</para>
+      <para>Al final del proceso tendrá un único fichero
+        (<filename>dumpfile</filename> según el ejemplo anterior)
+        que contendrá todos los datos almacenados en su repositorio
+        en el rango de revisiones especificado. Tenga en cuenta que
+        <command>svnadmin dump</command> lee los árboles de versiones del
+        repositorio igual que cualquier otro proceso <quote>lector</quote>
+        (por ejemplo, <command>svn checkout</command>). Así que es seguro
+        ejecutar este comando en cualquier momento.</para>
+
+      <para>El otro subcomando de la pareja, <command>svnadmin
+        load</command>, procesa el flujo estándar de entrada como un
+        fichero de volcado de repositorio de Subversion, y reproduce de
+        manera efectiva esas revisiones volcadas en el repositorio destino
+        durante la operación. También proporciona mensajes informativos,
+        esta vez usando el flujo de salida estándar:</para>
 
       <screen>
 $ svnadmin load newrepos < dumpfile
@@ -2052,60 +2059,58 @@
 
 </screen>
 
-      <para>Note that because <command>svnadmin</command> uses
-        standard input and output streams for the repository dump and
-        load process, people who are feeling especially saucy can try
-        things like this (perhaps even using different versions of
-        <command>svnadmin</command> on each side of the pipe):</para>
-  
+      <para>Dado que <command>svnadmin</command> usa la los flujos
+        estándar de entrada y salida para el volcado de repositorio y el
+        proceso de carga, las personas que se sientan atrevidas pueden
+        probar algo como ésto (quizás usando diferentes versiones de
+        <command>svnadmin</command> en cada lado de la tubería):</para>
+
       <screen>
 $ svnadmin create newrepos
 $ svnadmin dump myrepos | svnadmin load newrepos
 </screen>
 
-      <para>We mentioned previously that <command>svnadmin
-        dump</command> outputs a range of revisions.  Use the
-        <option>--revision</option> option to specify a single
-        revision to dump, or a range of revisions.  If you omit this
-        option, all the existing repository revisions will be
-        dumped.</para>
+      <para>Hemos mencionado anteriormente que <command>svnadmin
+        dump</command> genera un rango de revisiones. Use la opción
+        <option>--revision</option> para indicar que quiere volcar una
+        revisión concreta, o un rango. Si omite esta opción, todas las
+        revisiones existentes del repositorio serán volcadas.</para>
 
       <screen>
 $ svnadmin dump myrepos --revision 23 > rev-23.dumpfile
 $ svnadmin dump myrepos --revision 100:200 > revs-100-200.dumpfile
 </screen>
 
-      <para>As Subversion dumps each new revision, it outputs only
-        enough information to allow a future loader to re-create that
-        revision based on the previous one.  In other words, for any
-        given revision in the dump file, only the items that were
-        changed in that revision will appear in the dump.  The only
-        exception to this rule is the first revision that is dumped
-        with the current <command>svnadmin dump</command>
-        command.</para>
-
-      <para>By default, Subversion will not express the first dumped
-        revision as merely differences to be applied to the previous
-        revision.  For one thing, there is no previous revision in the
-        dump file!  And secondly, Subversion cannot know the state of
-        the repository into which the dump data will be loaded (if it
-        ever, in fact, occurs).  To ensure that the output of each
-        execution of <command>svnadmin dump</command> is
-        self-sufficient, the first dumped revision is by default a
-        full representation of every directory, file, and property in
-        that revision of the repository.</para>
-
-      <para>However, you can change this default behavior.  If you add
-        the <option>--incremental</option> option when you dump your
-        repository, <command>svnadmin</command> will compare the first
-        dumped revision against the previous revision in the
-        repository, the same way it treats every other revision that
-        gets dumped.  It will then output the first revision exactly
-        as it does the rest of the revisions in the dump
-        range—mentioning only the changes that occurred in that
-        revision.  The benefit of this is that you can create several
-        small dump files that can be loaded in succession, instead of
-        one large one, like so:</para>
+      <para>A medida que Subversion vuelca cada revisión nueva, muestra
+        la información justa para permitir a un cargador futuro recrear
+        esa revisión basándose en la anterior. En otras palabras,
+        para cualquier revisión dada en el fichero de volcado, sólo
+        aparecerán los elementos que cambiaron en ella. La única
+        excepción a esta regla es la primera revisión volcada por el
+        comando <command>svnadmin dump</command> actual.</para>
+
+      <para>Por defecto, Subverion no expresará la primera revisión
+        volcada como las meras diferencias aplicables sobre la revisión
+        anterior.  Para empezar, ¡es que no hay revisión anterior
+        alguna en el fichero de volcado! Y en segundo lugar, Subversion
+        no puede saber el estado del repositorio en el cual los datos
+        volcados serán cargados (si este hecho llega a producirse). Para
+        asegurarse de que la salida de cada ejecución de <command>svnadmin
+        dump</command> es autosuficiente, la primera revisión volcada
+        es por defecto una representación completa de cada directorio,
+        fichero, y propiedad en esa revisión del repositorio.</para>
+
+      <para>No obstante, puede cambiar este comportamiento por defecto. Si
+        añade la opción <option>--incremental</option> cuando vuelque su
+        repositorio, <command>svnadmin</command> comparará la primera
+        versión volcada del repositorio contra la revisión anterior del
+        repositorio, igual que trata cualquier otra revisión volcada.
+        Entonces mostrará la primera revisión exáctamente igual que el
+        resto de las revisiones del rango de volcado—mencionando
+        únicamente los cambios ocurridos en esa revisión. El beneficio
+        de esto es que puede crear varios ficheros de volcado menores
+        que pueden ser cargados secuencialmente, en lugar de un único
+        fichero grande, siguiendo estos pasos:</para>
 
       <screen>
 $ svnadmin dump myrepos --revision 0:1000 > dumpfile1
@@ -2113,47 +2118,51 @@
 $ svnadmin dump myrepos --revision 2001:3000 --incremental > dumpfile3
 </screen>
 
-      <para>These dump files could be loaded into a new repository with
-        the following command sequence:</para>
+      <para>Estos ficheros de volcado podrían ser cargados en un nuevo
+        repositorio usando la siguiente secuencia de comandos:</para>
 
       <screen>
 $ svnadmin load newrepos < dumpfile1
 $ svnadmin load newrepos < dumpfile2
+
 $ svnadmin load newrepos < dumpfile3
 </screen>
 
-      <para>Another neat trick you can perform with this
-        <option>--incremental</option> option involves appending to an
-        existing dump file a new range of dumped revisions.  For
-        example, you might have a <literal>post-commit</literal> hook
-        that simply appends the repository dump of the single revision
-        that triggered the hook.  Or you might have a script that runs
-        nightly to append dump file data for all the revisions that
-        were added to the repository since the last time the script
-        ran.  Used like this, <command>svnadmin</command>'s
-        <literal>dump</literal> and <literal>load</literal> commands
-        can be a valuable means by which to backup changes to your
-        repository over time in case of a system crash or some other
-        catastrophic event.</para>
-
-      <para>The dump format can also be used to merge the contents of
-        several different repositories into a single repository.  By
-        using the <option>--parent-dir</option> option of <command>svnadmin
-        load</command>, you can specify a new virtual root directory
-        for the load process.  That means if you have dumpfiles for
-        three repositories, say <filename>calc-dumpfile</filename>,
-        <filename>cal-dumpfile</filename>, and
-        <filename>ss-dumpfile</filename>, you can first create a new
-        repository to hold them all:</para>
+      <para>Otro truco interesante que puede realizar con la opción
+        <option>--incremental</option> consiste en añadir a un
+        fichero de volcado existente un nuevo rango de revisiones
+        volcadas. Por ejemplo, digamos que tiene un gancho
+        <literal>post-commit</literal> que simplemente añade el volcado
+        del repositorio de la versión única que despertó la ejecución
+        del gancho. O quizás tenga un script que se ejecute por las
+        noches para añadir los datos del fichero de volcado de todas
+        las revisiones que fueron añadidas al repositorio desde la
+        última vez que fue ejecutado el script. Usados de este modo,
+        los comandos <command>svnadmin</command> <literal>dump</literal>
+        y <literal>load</literal> pueden ser valiosos aliados para
+        realizar copias de seguridad de su repositorio a lo largo
+        del tiempo en caso de un fallo de sistema o algún otro eveno
+        catastrófico.</para>
+
+      <para>El formato de volcado también puede ser usado para fusionar
+        los contenidos de varios repositorios diferentes en uno
+        único.  Al usar la opción <option>--parent-dir</option>
+        de <command>svnadmin load</command>, puede especificar
+        un nuevo directorio virtual para el proceso de carga. Lo
+        cual significa que si tiene ficheros de volcados para tres
+        repositorios, digamos <filename>calc-dumpfile</filename>,
+        <filename>cal-dumpfile</filename>, y
+        <filename>ss-dumpfile</filename>, puede crear primero un nuevo
+        repositorio para almacenarlos todos:</para>
 
       <screen>
 $ svnadmin create /path/to/projects
 $
 </screen>
 
-      <para>Then, make new directories in the repository which will
-        encapsulate the contents of each of the three previous
-        repositories:</para>
+      <para>Entonces, crée nuevos directorios en el repositorio que
+        encapsularán los contenidos de cada uno de los tres repositorios
+        anteriores:</para>
 
       <screen>
 $ svn mkdir -m "Initial project roots" \
@@ -2164,8 +2173,8 @@
 $ 
 </screen>
 
-      <para>Lastly, load the individual dumpfiles into their
-        respective locations in the new repository:</para>
+      <para>Por último, cargue los ficheros de volcado individuales en
+        sus ubicaciones respectivas del nuevo repositorio:</para>
 
       <screen>
 $ svnadmin load /path/to/projects --parent-dir calc < calc-dumpfile
@@ -2177,72 +2186,79 @@
 $
 </screen>
 
-      <para>We'll mention one final way to use the Subversion
-        repository dump format—conversion from a different
-        storage mechanism or version control system altogether.
-        Because the dump file format is, for the most part,
-        human-readable,
+      <para>Mencionaremos un último uso del formato de volcado de
+        repositorio de Subversion—conversión desde un formato de
+        almacenamiento diferente o sistema de control de versiones.
+        Dado que el fichero de volcado es, en su mayor parte, legible
+        por un humano,
         <footnote>
-          <para>The Subversion repository dump format resembles
-            an RFC-822 format, the same type of format used for most
-            email.</para>
+          <para>El formato de volcado de repositorio de Subversion
+            recuerda al formato RFC-822, el mismo tipo de formato usado
+            para la mayor parte del correo electrónico.</para>
         </footnote>
-        it should be relatively easy to describe generic sets of
-        changes—each of which should be treated as a new
-        revision—using this file format.  In fact, the
-        <command>cvs2svn.py</command> utility (see <xref
-        linkend="svn-ap-a-sect-11"/>) uses the dump format to represent the
-        contents of a CVS repository so that those contents can be
-        moved in a Subversion repository.</para>
+        debería ser relativamente sencillo describir un conjungo genérico
+        de cambios—cada uno de ellos debería ser descrito como
+        una nueva revisión—usando este formato de fichero.
+        De hecho, la ultilidad <command>cvs2svn.py</command> (véa
+        <xref linkend="svn-ap-a-sect-11"/>) usa el formato de volcado
+        para representar el contenido de un repositorio CVS para
+        que sus contenidos pueden ser trasladados a un repositorio
+        Subversion.</para>
 
     </sect2>
 
     <!-- ***************************************************************** -->
     <sect2 id="svn-ch-5-sect-3.6">
-      <title>Repository Backup</title>
+      <title>Copias de seguridad del repositorio</title>
 
-      <para>Despite numerous advances in technology since the birth of
-        the modern computer, one thing unfortunately rings true with
-        crystalline clarity—sometimes, things go very, very
-        awry.  Power outages, network connectivity dropouts, corrupt
-        RAM and crashed hard drives are but a taste of the evil that
-        Fate is poised to unleash on even the most conscientious
-        administrator.  And so we arrive at a very important
-        topic—how to make backup copies of your repository
-        data.</para>
-
-      <para>There are generally two types of backup methods available
-        for Subversion repository administrators—incremental and
-        full.  We discussed in an earlier section of this chapter how
-        to use <command>svnadmin dump --incremental</command> to
-        perform an incremental backup (see <xref
-        linkend="svn-ch-5-sect-3.5"/>).  Essentially, the idea is to
-        only backup at a given time the changes to the repository
-        since the last time you made a backup.</para>
-
-      <para>A full backup of the repository is quite literally a
-        duplication of the entire repository directory (which includes
-        the Berkeley database environment).  Now, unless you
-        temporarily disable all other access to your repository,
-        simply doing a recursive directory copy runs the risk of
-        generating a faulty backup, since someone might be currently
-        writing to the database.</para>
-
-      <para>Fortunately, Sleepycat's Berkeley DB documents describe a
-        certain order in which database files can be copied that will
-        guarantee a valid backup copy.  And better still, you don't
-        have to implement that algorithm yourself, because the
-        Subversion development team has already done so.  The
-        <command>hot-backup.py</command> script is found in the
-        <filename>tools/backup/</filename> directory of the Subversion
-        source distribution.  Given a repository path and a backup
-        location, <command>hot-backup.py</command>—which is
-        really just a more intelligent wrapper around the
-        <command>svnadmin hotcopy</command> command—will perform
-        the necessary steps for backing up your live
-        repository—without requiring that you bar public
-        repository access at all—and then will clean out the
-        dead Berkeley log files from your live repository.</para>
+      <para>A pesar de numerosos avances tecnológicos desde el nacimiento
+        de la computadora moderna, hay una cosa que se entiende con
+        cristalina claridad—a veces, las cosas van muy, pero
+        que muy mal. Pérdidas de corriente, fallos de conectividad en
+        la red, RAM corrupta y discos duros estropeados son un mero
+        avance del mal que el Destino puede desatar sobre incluso el
+        administrador más concienzudo.  Y por lo tanto, llegamos a un
+        tema muy importante—cómo hacer copias de seguridad de los
+        datos de su repositorio.</para>
+
+      <para>En general hay dos tipos de métodos de copia de seguridad
+        disponibles para los administradores de repositorios de
+        Subversion—incrementales y completos. Hemos discutido en
+        una sección anterior de este capítulo cómo usar <command>svnadmin
+        dump --incremental</command> para realizar copias de seguridad
+        incrementales (vea <xref linkend="svn-ch-5-sect-3.5"/>).
+        Esencialmente, la idea es realizar en un momento dado copias de
+        seguridad de los cambios realizados desde la última vez que se
+        hizo la copia de seguridad anterior.</para>
+
+      <para>Una copia de seguridad completa del repositorio es casi una
+        copia literal del directorio que contiene todo el repositorio (lo
+        cual incluye el entorno de la base de datos Berkeley). Ahora, a no
+        ser que desactive temporalmente todo el acceso a su repositorio,
+        ejecutar un simple copiado recursivo del directorio conlleva
+        el riesgo de generar una copia de seguridad errónea, dado que
+        alguien podría estar modificando la base de datos.</para>
+
+      <para>Afortunadamente, los documentos de la base de datos
+        Berkeley DB de Sleepycat describen un orden concreto
+        en el cual se pueden copiar los ficheros de la base de
+        datos de tal modo que se garantice una copia de seguridad
+        válida. Y aun mejor, usted no necesita implementar
+        ese algoritmo por su cuenta, porque el equipo de
+        desarrolladores de Subversion ya lo ha hecho. El script
+        <command>hot-backup.py</command> que puede encontrar
+        en el directorio <filename>tools/backup/</filename>
+        de la distribución de código fuente de Subversion.
+        Usando como parámetros la ruta al repositorio
+        y a la ubicación de la copia de seguridad,
+        <command>hot-backup.py</command>—que realmente no
+        es más que un envoltorio más inteligente sobre el comando
+        <command>svnadmin hotcopy</command>— realizará los
+        pasos necesarios para realizar una copia de seguridad en
+        caliente del repositorio—sin necesitar en absoluto
+        tener que impedir el acceso al mismo—y después
+        borrará los ficheros de registro sin usar de Berkeley de
+        su repositorio activo actual.</para>
 
       <para>Even if you also have an incremental backup, you might want to run
         this program on a regular basis.  For example, you might




More information about the svnbook-dev mailing list