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

gradha noreply at red-bean.com
Mon Aug 28 14:22:20 CDT 2006


Author: gradha
Date: Mon Aug 28 14:22:20 2006
New Revision: 2398

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

Log:
Book Spanish. Translated 11 paragraphs.

Modified: trunk/src/es/book/ch05.xml
==============================================================================
--- trunk/src/es/book/ch05.xml	(original)
+++ trunk/src/es/book/ch05.xml	Mon Aug 28 14:22:20 2006
@@ -2260,93 +2260,98 @@
         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
-        consider adding <command>hot-backup.py</command> to a program
-        scheduler (such as <command>cron</command> on Unix systems).
-        Or, if you prefer fine-grained backup solutions, you could
-        have your post-commit hook script call
-        <command>hot-backup.py</command> (see <xref
-        linkend="svn-ch-5-sect-2.1" />), which will then cause a new
-        backup of your repository to occur with every new revision
-        created.  Simply add the following to the
-        <filename>hooks/post-commit</filename> script in your live
-        repository directory:</para>
+      <para>Incluso si también dispone de una copia de seguridad
+        incremental, quizás quiera ejecutar también este programa
+        de manera habitual. Por ejemplo, podría considerar
+        añadir <command>hot-backup.py</command> a un programa de
+        planificación (como por ejemplo <command>cron</command>
+        en sistemas Unix). O, si prefiere soluciones de copias de
+        seguridad con alta granularidad, podría hacer que su gancho
+        post-commit llame <command>hot-backup.py</command> (vea <xref
+        linkend="svn-ch-5-sect-2.1" />), lo cual provocará una nueva copia
+        de seguridad de su repositorio con cada nueva versión. Simplemente
+        añada el script <filename>hooks/post-commit</filename> a su
+        directorio activo del repositorio:</para>
 
       <programlisting>
 (cd /path/to/hook/scripts; ./hot-backup.py ${REPOS} /path/to/backups &)
 </programlisting>
 
-      <para>The resulting backup is a fully functional Subversion
-        repository, able to be dropped in as a replacement for your
-        live repository should something go horribly wrong.</para>
-
-      <para>There are benefits to both types of backup methods.  The
-        easiest is by far the full backup, which will always result in
-        a perfect working replica of your repository.  This again
-        means that should something bad happen to your live
-        repository, you can restore from the backup with a simple
-        recursive directory copy.  Unfortunately, if you are
-        maintaining multiple backups of your repository, these full
-        copies will each eat up just as much disk space as your live
-        repository.</para>
-
-      <para>Incremental backups using the repository dump format are
-        excellent to have on hand if the database schema changes
-        between successive versions of Subversion itself.  Since a
-        full repository dump and load are generally required to
-        upgrade your repository to the new schema, it's very
-        convenient to already have half of that process (the dump
-        part) finished.  Unfortunately, the creation of—and
-        restoration from—incremental backups takes longer, as
-        each commit is effectively replayed into either the dumpfile
-        or the repository.</para>
-
-      <para>In either backup scenario, repository administrators need
-        to be aware of how modifications to unversioned revision
-        properties affect their backups.  Since these changes do not
-        themselves generate new revisions, they will not trigger
-        post-commit hooks, and may not even trigger the
-        pre-revprop-change and post-revprop-change hooks.
+      <para>La copia de seguridad resultante es un repositorio de
+        Subversion completamente funcional, capaz de reemplazas su
+        repositorio activo en caso de que algo vaya muy mal.</para>
+
+      <para>Ambos métodos de copias de seguridad son beneficiosos. La
+        copia de seguridad completa es de lejos la más sencilla,
+        la que siempre resultará ser una réplica de su repositorio
+        perfectamente funcional. Le recordamos que esto significa que si
+        algo malo le ocurre a su repositorio activo, puede recuperar
+        su copia de seguridad con un simple copiado recursivo de
+        directorios. Desafortunadamente, si está manteniendo múltiples
+        copias de seguridad de su repositorio, estas copias completas
+        acabarán ocupando la misma cantidad de espacio de disco que su
+        repositorio activo.</para>
+
+      <para>Las copias de seguridad incrementales usando el formato de
+        volcado del repositorio son excelentes para tener a mano si el
+        esquema de la base de datos cambia entre sucesivas versiones del
+        propio Subversion. Dado que para actualizar su repositorio al
+        nuevo esquema es necesario que haga un volcado y carga completa
+        del repositorio, es muy conveniente tener la mitad de ese
+        proceso (la parte del volcado) realizada.  Desafortunadamente,
+        la creación—y recuperación—de copias de seguridad
+        incrementales tarda mucho más, dado que cada revisión es
+        reproducida en el fichero de volcado o el repositorio.</para>
+
+      <para>En ambos escenarios, los administradores del repositorio
+        necesitan estar atentos a cómo las modificaciones de propiedades
+        de revisión no versionadas afectan a sus copias de seguridad. Dado
+        que estos cambios no generan por sí mismos nuevas revisiones,
+        no activarán ganchos post-commit, y quizás ni siquiera los
+        ganchos pre-revprop-change y post-revprop-change.
         <footnote>
-          <para><command>svnadmin setlog</command> can be called in a
-            way that bypasses the hook interface altogether.</para>
-        </footnote>  
-        And since you can change revision properties without respect
-        to chronological order—you can change any revision's
-        properties at any time—an incremental backup of the
-        latest few revisions might not catch a property modification
-        to a revision that was included as part of a previous 
-        backup.</para>
-
-      <para>Generally speaking, only the truly paranoid would need to
-        backup their entire repository, say, every time a commit
-        occurred.  However, assuming that a given repository has some
-        other redundancy mechanism in place with relatively fine
-        granularity (like per-commit emails), a hot backup of the
-        database might be something that a repository administrator
-        would want to include as part of a system-wide nightly backup.
-        For most repositories, archived commit emails alone provide
-        sufficient redundancy as restoration sources, at least for the
-        most recent few commits.  But it's your data—protect it
-        as much as you'd like.</para>
-            
-      <para>Often, the best approach to repository backups is a
-        diversified one.  You can leverage combinations of full and
-        incremental backups, plus archives of commit emails.  The
-        Subversion developers, for example, back up the Subversion
-        source code repository after every new revision is created,
-        and keep an archive of all the commit and property change
-        notification emails.  Your solution might be similar, but
-        should be catered to your needs and that delicate balance of
-        convenience with paranoia.  And while all of this might not
-        save your hardware from the iron fist of Fate,
+          <para><command>svnadmin setlog</command> puede ser invocado
+            de un modo que evita por completo el mecanismo de
+            ganchos.</para>
+        </footnote>
+        Y dado que puede cambiar las propiedade de revisión sin respetar
+        su orden cronológico—puede cambiar cualquier propiedad
+        de revisión en cualquier momento—una copia de seguridad
+        incremental de las últimas pocas revisiones quizás no capture
+        la modificación de una propiedad de revisión que fue incluida
+        como parte de una copia de seguridad anterior.</para>
+
+      <para>Hablando de manera general, sólo los realmente paranóicos
+        necesitarían hacer una copia de seguridad de su repositorio
+        completo, digamos que, cada vez que se realiza un cambio. No
+        obstante, asumiendo que un repositorio determinado tiene
+        funcionando otros mecanismos de redundancia con relativa
+        granularidad (como correos electrónicos por modificación), una
+        copia de seguridad en caliente de la base de datos sería algo que
+        un administrador de repositorio querría incluir como parte de una
+        copia de seguridad de sistema nocturna. Para la mayoría de los
+        repositorios, los correos archivados con cambios son suficiente
+        fuente de redundancia, al menos para los últimos cambios. Pero
+        son sus datos—protéjalos tanto como desee.</para>
+
+      <para>A menudo, la mejor estrategia para realizar copias de seguridad es
+        aquella que diversifique. Puede aprovechar combinaciones de copias
+        de seguridad completas e incrementales, y adicionalmente archivos
+        de correo con los cambios. Los desarrolladores de Subversion,
+        por ejemplo, realizan una copia de seguridad del repositorio de
+        código fuente tras cada nueva revisión, y mantienen un archivo
+        de todas las notificaciones por correo electrónico de cambios y
+        modificaciones de propiedades.  Su solución podría ser similar,
+        pero debería estar orientada a las necesidades y ese delicado
+        balance entre la conveniencia y la paranoia.  Y aunque nada
+        de todo esto le ayude a salvar su hardware del puño de hierro
+        del Destino,
         <footnote>
-          <para>You know—the collective term for all of her
-            <quote>fickle fingers</quote>.</para>
+          <para>Ya sabe—el término genérico para sus 
+            <quote>erráticos dedos</quote>.</para>
         </footnote>
-        it should certainly help you recover from those trying 
-        times.</para>
+        ciertamente debería ayudarle a recuperarse tras uno de esos
+        momentos.</para>
 
     </sect2>
   </sect1>
@@ -2356,31 +2361,32 @@
   <!-- *** SECTION 6:  ADDING PROJECTS                                 *** -->
   <!-- ******************************************************************* -->
   <sect1 id="svn-ch-5-sect-6">
-    <title>Adding Projects</title>
+    <title>Añadiendo proyectos</title>
 
-    <para>Once your repository is created and configured, all that
-      remains is to begin using it.  If you have a collection of
-      existing data that is ready to be placed under version control,
-      you will more than likely want to use the <command>svn</command>
-      client program's <literal>import</literal> subcommand to
-      accomplish that.  Before doing this, though, you should
-      carefully consider your long-term plans for the repository.  In
-      this section, we will offer some advice on how to plan the
-      layout of your repository, and how to get your data arranged in
-      that layout.</para>
+    <para>Una vez haya creado y configurado su repositorio, todo lo que
+      queda es comenzar a usarlo. Si tiene una colección de datos
+      existentes listos para ser puestos bajo control de versiones, es
+      muy probable que desee usar el subcomando <literal>import</literal>
+      del programa cliente <command>svn</command>.  No obstante, antes
+      de hacer esto debería considerar con cuidado los planes a largo
+      plazo de su repositorio. En esta sección le ofreceremos algunos
+      consejos sobre la planificación del esquema de su repositorio,
+      y cómo reorganizar sus datos de acuerdo con éste.</para>
 
     <!-- ***************************************************************** -->
     <sect2 id="svn-ch-5-sect-6.1">
-      <title>Choosing a Repository Layout</title>
+      <title>Escogiendo el esquema de repositorio</title>
 
-      <para>While Subversion allows you to move around versioned files
-        and directories without any loss of information, doing so can
-        still disrupt the workflow of those who access the repository
-        often and come to expect things to be at certain locations.
-        Try to peer into the future a bit; plan ahead before placing
-        your data under version control.  By <quote>laying out</quote>
-        the contents of your repositories in an effective manner the
-        first time, you can prevent a load of future headaches.</para>
+      <para>Aunque Subversion le permite desplazar los ficheros y
+        directorios versionados sin pérdida de información de
+        cualquier tipo, al hacerlo puede entorpecer el flujo
+        de trabajo de aquellos quienes acceden al repositorio
+        con frecuencia y esperan encontrar algunas cosas en
+        ubicaciones determinadas.  Intente asomarse un poco al
+        futuro; planifique antes de poner sus datos bajo control
+        de versiones. Al <quote>organizar</quote> el contenido de
+        sus repositorios de una manera efectiva la primera vez,
+        podrá evitar un montón de futuros dolores de cabeza.</para>
 
       <para>There are a few things to consider when setting up
         Subversion repositories.  Let's assume that as repository




More information about the svnbook-dev mailing list