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

mperez noreply at red-bean.com
Sun May 21 19:31:10 CDT 2006


Author: mperez
Date: Sun May 21 19:31:10 2006
New Revision: 2161

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

Log:
Book Spanish. Chapter 2 revised against the english version.


Modified: trunk/src/es/book/ch02.xml
==============================================================================
--- trunk/src/es/book/ch02.xml	(original)
+++ trunk/src/es/book/ch02.xml	Sun May 21 19:31:10 2006
@@ -7,18 +7,18 @@
   <title>Conceptos Básicos</title>
 
   <simplesect>
-    <para>Este capítulo es una introducción corta y casual a Subversion.
-      Si es nuevo en el tema de control de versiones, este capítulo es
-      definitivamente para usted. Empezamos con una discusión de conceptos
-      generales en el control de versiones, avanzamos a las ideas específicas
-      detras de Subversion, y mostramos algunos ejemplos simples de Subversion
+    <para>Este capítulo es una introducción breve e informal a Subversion.
+      Si es nuevo en el tema del control de versiones, este capítulo es
+      definitivamente para usted. Empezaremos tratando los conceptos
+      generales en el control de versiones, seguiremos con las ideas específicas
+      detrás de Subversion, y mostraremos algunos ejemplos simples de Subversion
       en acción.</para>
     
-    <para>Aún cuando los ejemplos en este capítulo muestran a gente
-      compartiendo colecciones de código fuente de programas, tenga en mente
+    <para>Aunque los ejemplos de este capítulo muestran a gente
+      compartiendo colecciones de archivos de código fuente, tenga en mente
       que Subversion puede manejar cualquier tipo de colección de
-      archivos—no esta limitado a asistir a programadores de
-      computadores.</para>
+      archivos—no está limitado a asistir a programadores de
+      ordenadores.</para>
   </simplesect>
   
   
@@ -26,38 +26,39 @@
     <title>El Repositorio</title>  
     
     <para>Subversion es un sistema centralizado para compartir información.
-      En su núcleo esta un repositorio, el cual es un almacén central de datos.
-      El repositorio guarda información en forma de un 
-      <firstterm>árbol de archivos</firstterm>—una jerarquía típica
+      La parte principal de Subversion es el repositorio, el cual es un 
+      almacén central de datos.
+      El repositorio guarda información en forma de
+      <firstterm>árbol de archivos</firstterm>—una típica jerarquía
       de archivos y directorios. Cualquier número de <firstterm>clientes</firstterm>
-      se conectan al repositorio para luego leer o escribir a estos archivos.
-      Al escribir los datos, un cliente pone a disposición de otros la información;
-      Al leer datos, el cliente recibe información de otros.  
-      La figura <xref linkend="svn-ch-2-dia-1"/> ilustra esto.</para>
+      puede conectarse al repositorio y luego leer o escribir en esos archivos.
+      Al escribir datos, un cliente pone a disposición de otros la información;
+      al leer datos, el cliente recibe información de otros.  
+      La figura <xref linkend="svn-ch-2-dia-1"/> ilustra ésto.</para>
 
     <figure id="svn-ch-2-dia-1">
       <title>Un sistema cliente/servidor típico</title>
       <graphic fileref="images/ch02dia1.png"/>
     </figure>
     
-    <para>Entonces, por qué es esto interesante?. Hasta ahora, esto
-      suena como la definición de un típico servidor de archivos.
-      En efecto, el repositorio <emphasis>es</emphasis> una clase de
-      servidor de archivos, pero no es del tipo usual. Lo que hace 
+    <para>Entonces, ¿qué tiene ésto de interesante?. Hasta ahora, 
+      suena como la definición del típico servidor de archivos.
+      Y, de hecho, el repositorio <emphasis>es</emphasis> una especie de
+      servidor de archivos, pero no del tipo habitual. Lo que hace 
       especial al repositorio de Subversion es que <emphasis>recuerda
-      cada cambio</emphasis> jamás escrito en el: cada cambio a cada
-      archivo, e inclusive cambios al árbol de directorios mismo, tales
+      todos los cambios</emphasis> hechos sobre él: cada cambio a cada
+      archivo, e inclusive cambios al propio árbol de directorios, tales
       como la adición, borrado y reubicación de archivos y directorios.</para>
 
-    <para>Cuando un cliente lee datos del repositorio, normalmente ve
-      sólo la ultima versión del árbol de archivos. Pero el cliente
-      también tiene la habilidad de ver estados <emphasis>previos</emphasis>
+    <para>Cuando un cliente lee datos del repositorio, normalmente sólo ve
+      la ultima versión del árbol de archivos. Sin embargo, el cliente
+      también tiene la posibilidad de ver estados <emphasis>previos</emphasis>
       del sistema de archivos. Por ejemplo, un cliente puede hacer
       consultas históricas como, <quote>¿Qué contenía este directorio 
-      el miércoles pasado?</quote> Este es el tipo de pregunta esencial
-      en cualquier <firstterm>sistema de control de versiones</firstterm>:
-      sistemas que estan diseñados para registrar y seguir cambios en
-      datos a través del tiempo.
+      el miércoles pasado?</quote> Esta es la clase de preguntas que resulta
+      esencial en cualquier <firstterm>sistema de control de versiones</firstterm>:
+      sistemas que están diseñados para registrar y seguir los cambios en
+      los datos a través del tiempo.
     </para>
 
   </sect1>
@@ -66,33 +67,33 @@
     <title>Modelos de Versionamiento</title>
 
     <para>La misión principal de un sistema de control de versiones
-      es permitir la edición colaborativa de datos y el compartir los mismos.
-      Sin embargo, diversos sistemas utilizan estrategias distintas para
-      lograr esto.</para>
+      es permitir la edición colaborativa y la compartición de los datos.
+      Sin embargo, existen diferentes sistemas que utilizan diferentes 
+      estrategias para alcanzar este objetivo.</para>
     
     <sect2 id="svn-ch-2-sect-2.1">
       <title>El Problema de Compartir Archivos</title>
       
       <para>Todos los sistemas de control de versiones tienen que resolver
-        un problema fundamental: ¿Cómo permitira el sistema a los usuarios
-        el compartir información, pero prevendrá el que accidentalmente se 
-        pisen mutuamente los callos? Es muy sencillo para los usuarios el
-        accidentalmente sobreescribir los cambios de los demás en el
+        un problema fundamental: ¿Cómo permitirá el sistema a los usuarios
+        el compartir información, pero al mismo tiempo impedirá que se pisen 
+        los callos mutuamente de forma accidental? Es muy sencillo para los 
+        usuarios el sobreescribir accidentalmente los cambios de los demás en el
         repositorio.</para>
 
       <para>Considere el escenario mostrado en <xref linkend="svn-ch-2-dia-2"/>.
-        Supóngase que tenemos dos colaboradores, Harry y Sally. Cada uno de
+        Suponga que tenemos dos colaboradores, Harry y Sally. Cada uno de
         ellos decide editar el mismo archivo del repositorio al mismo tiempo.
-        Si Harry guarda sus cambios al repositorio primero, es posible
-        entonces que (unos momentos mas tarde) Sally accidentalmente
-        los sobreescriba con su propia nueva versión del archivo. Si bien es
-        cierto que la versión de Harry no esta perdida para siempre (porque el
+        Si Harry guarda sus cambios en el repositorio en primer lugar, es 
+        posible que (unos momentos más tarde) Sally los sobreescriba 
+        accidentalmente con su propia versión del archivo. Si bien es
+        cierto que la versión de Harry no se ha perdido para siempre (porque el
         sistema recuerda cada cambio), cualquier cambio que Harry haya hecho
-        <emphasis>no</emphasis> estará presente en la nueva versión de Sally
-        del archivo porque ella nunca los cambios de Harry en primer lugar. El
-        trabajo de Harry si está efectivamente perdido—o al menos
-        ausente de la última versión del archivo—y probablemente por
-        accidente. Esta es definitivamente una situación que queremos evitar!</para>
+        <emphasis>no</emphasis> estará presente en la versión más reciente de Sally
+        porque, para empezar, ella nunca vio los cambios de Harry. El
+        trabajo de Harry sigue efectivamente perdido—o al menos
+        ausente en la última versión del archivo—y probablemente por
+        accidente. ¡Esta es definitivamente una situación que queremos evitar!</para>
 
       <figure id="svn-ch-2-dia-2">
         <title>El problema a evitar</title>
@@ -106,17 +107,17 @@
       
       <para>Muchos sistemas de control de versiones utilizan un modelo de
         <firstterm>bloqueo-modificación-desbloqueo</firstterm> para atacar
-        este problema. En un sistema como este, el repositorio permite que
-        solo una persona cambie un archivo a la vez. Harry debe
-        primero <quote>bloquear</quote> el archivo para luego empezar a
-        hacerle cambios. Bloquear un archivo se parece mucho pedir prestado un
+        este problema. En un sistema como éste, el repositorio sólo permite
+        a una persona modificar un archivo al mismo tiempo. Harry debe
+        <quote>bloquear</quote> primero el archivo para luego empezar a
+        hacerle cambios. Bloquear un archivo se parece mucho a pedir prestado un
         libro de la biblioteca; si Harry ha bloqueado el archivo, entonces
-        Sally no puede hacerle cambios. So ella intenta bloquear el archivo,
-        el repositorio rechazara la petición. Todo lo que puede hacer es leer
-        el archivo y esperar que Harry termine sus cambios y deshaga su
-        bloqueo. Luego que Harry desbloquea el archivo, su turno termina y
-        ahora Sally puede aprovechar su turno bloqueando y editando. La figura
-        <xref linkend="svn-ch-2-dia-3"/> demuestra esta simple solución.</para>
+        Sally no puede hacerle cambios. Por consiguiente, si ella intenta bloquear 
+        el archivo, el repositorio rechazará la petición. Todo lo que puede hacer 
+        es leer el archivo y esperar a que Harry termine sus cambios y deshaga el
+        bloqueo. Tras desbloquear Harry el archivo, Sally puede aprovechar su turno
+        bloqueando y editando el archivo. La figura
+        <xref linkend="svn-ch-2-dia-3"/> demuestra esta sencilla solución.</para>
       
       <figure id="svn-ch-2-dia-3">
         <title>La solucion bloqueo-modificación-desbloqueo</title>
@@ -132,38 +133,38 @@
             <emphasis>Bloquear puede causar problemas administrativos.</emphasis>
 
 
-            En ocasiones Harry bloqueara un archivo y lo olvidará. Mientras
-            tanto, como Sally esta aun esperando para editar el archivo, sus
-            manos estan atadas. Y luego Harry se va de vacaciones. Ahora Sally
+            En ocasiones Harry bloqueará un archivo y se olvidará de él. Mientras
+            tanto, como Sally está aún esperando para editar el archivo, sus
+            manos están atadas. Y luego Harry se va de vacaciones. Ahora Sally
             debe conseguir que un administrador deshaga el bloqueo de Harry.
             La situación termina causando muchas demoras innecesarias y
-            perdida de tiempo.
+            pérdida de tiempo.
             </para></listitem>
         
         <listitem><para>
-            <emphasis>Bloquear puede causar serialización innecesaria.</emphasis>
+            <emphasis>Bloquear puede causar una serialización innecesaria.</emphasis>
 
-            Qué sucede si Harry esta editando el inicio de un archivo de texto
+            ¿Qué sucede si Harry está editando el inicio de un archivo de texto
             y Sally simplemente quiere editar el final del mismo archivo?
-            Estos cambios no traslapan en absoluto. Ellos podrían editar el
-            archivo simultaneamente y no resultaría en gran daño, asumiendo
-            que los cambios fueran correctamente mezclados. No hay necesidad
-            de que tomen turnos en esta situación.
+            Estos cambios no se solapan en absoluto. Ambos podrían editar el
+            archivo simultáneamente sin grandes perjuicios, suponiendo
+            que los cambios se combinaran correctamente. No hay necesidad
+            de turnarse en esta situación.
             </para></listitem>
     
         <listitem><para>
             <emphasis>Bloquear puede causar una falsa sensación de seguridad.</emphasis>
 
-            Digamos que Harry bloquea y edita el archivo A, mientras que
-            Sally simultaneamente bloquea y edita el archivo B. Pero suponga
+            Imaginemos que Harry bloquea y edita el archivo A, mientras que
+            Sally bloquea y edita el archivo B al mismo tiempo. Pero suponga
             que A y B dependen uno del otro y que los cambios hechos a cada
-            uno son semánticamente incompatibles. Súbitamente A y B ya no
-            funcionan juntos. El sistema de bloqueo fue impotente para
-            prevenir el problema—sin embargo de algun modo ha provisto
-            una falsa sensación de seguridad. Es facil para Harry y Sally
-            imaginar que al bloquear archivos, cada uno esta empezando una
-            tarea segura y aislada, lo cual los inhibe de discutir sus cambios
-            incompatibles desde temprano.
+            uno de ellos son semánticamente incompatibles. Súbitamente A y B ya no
+            funcionan juntos. El sistema de bloqueo se mostró ineficaz a la hora de
+            evitar el problema—sin embargo, y de algún modo, ofreció
+            una falsa sensación de seguridad. Es fácil para Harry y Sally
+            imaginar que al bloquear archivos, cada uno está empezando una
+            tarea segura y aislada, lo cual les inhibe de discutir sus cambios
+            incompatibles desde un principio.
             </para></listitem>
       </itemizedlist>
 
@@ -173,31 +174,32 @@
       <title>La solución Copiar-Modificar-Mezclar</title>
       
       <para>Subversion, CVS y otros sistemas de control de versiones
-        utilizan un modelo tipo
-        <firstterm>copiar-modificar-mezclar</firstterm> como una alternativa
-        al bloqueo. En este modelo, el cliente de cada usuario contacta al
+        utilizan un modelo del tipo
+        <firstterm>copiar-modificar-mezclar</firstterm> como alternativa
+        al bloqueo. En este modelo, el cliente de cada usuario se conecta al
         repositorio del proyecto y crea una <firstterm>copia de
-          trabajo</firstterm> personal—una reflexión local de los
-        archivos y directorios del repositorio. Los usuarios trabajan entonces
-        en paralelo, modificando sus copias privadas. Finalmente, las copias
-        privadas son mezcladas juntas en una nueva versión final. El sistema
-        de control de versiones a menudo ayuda con la mezcla, pero al final un
-        ser humano es responsable de hacer que suceda correctamente.
+          trabajo</firstterm> personal—una réplica local de los
+        archivos y directorios del repositorio. Los usuarios pueden entonces
+        trabajar en paralelo, modificando sus copias privadas. Finalmente, todas
+        las copias privadas se combinan (o mezclan) en una nueva versión final. 
+        El sistema de control de versiones a menudo ayuda con la mezcla, pero en 
+        última instancia es un ser humano el responsable de hacer que ésto suceda 
+        correctamente.
       </para>
       
       <para>He aquí un ejemplo. Digamos que Harry y Sally crean sendas copias
-        de trabajo del mismo proyecto, copiadas del repositorio. Ellos
-        trabajan concurrentemente y hacen cambios un mismo archivo A en sus
-        copias. Sally guarda sus cambios al repositorio primero. Cuando Harry
-        intenta guardar sus cambios mas tarde, el repositorio le informa que
-        su archivo A esta <firstterm>desactualizado</firstterm>. En otras
-        palabras, que el archivo A en el repositorio ha cambiado de algún modo
-        desde que lo copio por última vez. Luego Harry le dice a su cliente
+        de trabajo del mismo proyecto, extraídas del repositorio. Ambos
+        trabajan concurrentemente y hacen cambios a un mismo archivo A dentro de 
+        sus copias. Sally guarda sus cambios en el repositorio primero. Cuando Harry
+        intenta guardar sus cambios más tarde, el repositorio le informa de que
+        su archivo A está <firstterm>desactualizado</firstterm>. En otras
+        palabras, que el archivo A en el repositorio ha sufrido algún cambio
+        desde que lo copió por última vez. Por tanto, Harry le pide a su cliente
         que <firstterm>mezcle</firstterm> cualquier cambio nuevo del
         repositorio con su copia de trabajo del archivo A. Es probable que los
-        cambios de Sally no traslapan con los suyos; así que una vez que tenga
+        cambios de Sally no se solapen con los suyos; así que una vez que tiene
         ambos juegos de cambios integrados, Harry guarda su copia de trabajo
-        en el repositorio. Las figuras <xref
+        de nuevo en el repositorio. Las figuras <xref
         linkend="svn-ch-2-dia-4"/> y <xref linkend="svn-ch-2-dia-5"/>
         muestran este proceso.</para>
 
@@ -211,37 +213,37 @@
         <graphic fileref="images/ch02dia5.png"/>
       </figure>
 
-      <para>¿Pero que tal si los cambios de Sally <emphasis>sí</emphasis>
-        traslapan con los de Harry? ¿Entonces qué? Esta situación se conoce
-        como <firstterm>conflicto</firstterm> y usualmente no es un gran
-        problema. Cuando Harry le pide a su cliente que mezcle los últimos
+      <para>¿Pero qué ocurre si los cambios de Sally <emphasis>sí</emphasis>
+        se solapan con los de Harry? ¿Entonces qué? Esta situación se conoce
+        como <firstterm>conflicto</firstterm> y no suele suponer un gran problema. 
+        Cuando Harry le pide a su cliente que mezcle los últimos
         cambios del repositorio en su copia de trabajo, su copia del archivo A
-        es marcada de algún modo indicando que está en estado de conflicto: él
-        podrá ver ambos sets de cambios conflictivos y manualmente escoger
-        entre ellos. Nótese que el programa no puede autmáticamente resolver
-        conflictos; sólo los humanos son capaces de entender y realizar las
-        decisiones inteligentes necesarias. Una vez que Harry ha resuelto
-        manualmente los cambios traslapados—posiblemente luego de
-        discutirlo con Sally—él podra guardar con seguridad el archivo
+        se marca de algún modo para indicar que está en estado de conflicto: 
+        Harry podrá ver ambos conjuntos de cambios conflictivos y escoger manualmente
+        entre ellos. Observe que el programa no puede resolver automáticamente
+        los conflictos; sólo los humanos son capaces de entender y tomar las
+        decisiones inteligentes oportunas. Una vez que Harry ha resuelto
+        manualmente los cambios solapados—posiblemente después de
+        discutirlos con Sally—ya podrá guardar con seguridad el archivo
         mezclado en el repositorio.</para>
 
       <para>La solución copiar-modificar-mezclar puede sonar un tanto caótica,
         pero en la práctica funciona extremadamente bien. Los usuarios pueden
-        trabajar en paralelo, nunca esperandose el uno al otro. Cuando
+        trabajar en paralelo, sin tener que esperarse el uno al otro. Cuando
         trabajan en los mismos archivos, sucede que la mayoría de sus cambios
-        concurrentes no se traslapan en absoluto; los conflictos son poco
+        concurrentes no se solapan en absoluto; los conflictos son poco
         frecuentes. El tiempo que toma resolver los conflictos es mucho menor
-        al tiempo perdido por un sistema de bloqueos.</para>
+        que el tiempo perdido por un sistema de bloqueos.</para>
 
-      <para>Al final, todo se centra en un factor crítico: la comunicación
+      <para>Al final, todo desemboca en un factor crítico: la comunicación
         entre los usuarios. Cuando los usuarios se comunican pobremente, los
         conflictos tanto sintácticos como semánticos aumentan. Ningún sistema
         puede forzar a los usuarios a comunicarse perfectamente, y ningún
-        sistema puede detectar conflictos semánticos. Por consiguiente no
-        tiene sentido el dejarse adormecer por la falsa promesa de que un
-        sistema de bloqueos va de alguna manera a prevenir los conflictos; en
-        la práctica, el bloqueo parece inhibir la productividad mas que
-        nada.</para>
+        sistema puede detectar conflictos semánticos. Por consiguiente, no
+        tiene sentido dejarse adormecer por la falsa promesa de que un
+        sistema de bloqueos evitará de algún modo los conflictos; en
+        la práctica, el bloqueo parece inhibir la productividad más que otra cosa.
+        </para>
       
     </sect2>
     
@@ -251,52 +253,52 @@
   <sect1 id="svn-ch-2-sect-3">
     <title>Subversion en Acción</title>
     
-    <para>Es tiempo de movernos de lo abstracto a lo concreto. En esta sección
-      mostraremos ejemplos reales de Subversion siendo utilizado.</para>
+    <para>Es hora de movernos de lo abstracto a lo concreto. En esta sección
+      mostraremos ejemplos reales de Subversion en la práctica.</para>
 
     <sect2 id="svn-ch-2-sect-3.1">
       <title>Copias de Trabajo</title>
       
-      <para>Ya ha leído acerca de copias de trabajo; ahora demostraremos como
-        el cliente de Subversion las crea y utiliza.</para>
+      <para>Ya ha leído acerca de las copias de trabajo; ahora demostraremos 
+        cómo las crea y las usa el cliente de Subversion.</para>
       
       <para>Una copia de trabajo de Subversion es un árbol de directorios
-        ordinario en su sistema de archivos local, conteniendo una colección
+        corriente de su sistema de archivos local, conteniendo una colección
         de archivos. Usted puede editar estos archivos del modo que prefiera y
-        si se trata de archivos de código fuente, usted puede compilar su
-        programa con ellos de la manera usual. Su copia de trabajo es su área
-        de trabajo privada: Subversion nunca incorporará los cambios de otra
-        gente, o pondrá a disposición de otros sus cambios hasta que usted le
-        indique explícitamente que lo haga.</para>
-
-      <para>Luego de que haya hecho algunos cambios a los archivos en su copia
-        de trabajo y verificado que trabajan correctamente, Subversion provee
-        comandos para <quote>publicar</quote> sus cambios para las demás
-        personas trabajando con usted en su proyecto (guardándolos en el
-        repositorio). Si las demás personas publican sus propios cambios,
-        Subversion provee comandos para mezclar estos cambios en su directorio
-        de trabajo (leyéndolos del repositorio).</para>
+        si se trata de archivos de código fuente, podrá compilar su
+        programa a partir de ellos de la manera habitual. Su copia de trabajo 
+        es su área de trabajo privada: Subversion nunca incorporará los cambios 
+        de otra gente o pondrá a disposición de otros sus cambios hasta que 
+        usted le indique explícitamente que lo haga.</para>
+
+      <para>Tras hacer algunos cambios a los archivos en su copia
+        de trabajo y verificar que funcionan correctamente, Subversion le
+        proporciona comandos para <quote>publicar</quote> sus cambios al
+        resto de personas que trabajan con usted en su proyecto 
+        (escribiendo en el repositorio). Si las demás personas publican sus 
+        propios cambios, Subversion le proporciona comandos para mezclar 
+        estos cambios en su directorio de trabajo (leyendo del repositorio).</para>
 
       <para>Una copia de trabajo también contiene algunos archivos extra,
         creados y mantenidos por Subversion para ayudarle a ejecutar estos
         comandos. En particular, cada directorio de su copia de trabajo
         contiene un subdirectorio llamado <filename>.svn</filename>, también
         conocido como el <firstterm>directorio administrativo</firstterm> de
-        la copia de trabajo. Los archivos en cada directorio administrativo le
+        la copia de trabajo. Los archivos en cada directorio administrativo 
         ayudan a Subversion a reconocer qué archivos contienen cambios no
         publicados y qué archivos estan desactualizados con respecto al
-        trabajo de otros.</para>
+        trabajo hecho por los demás.</para>
       
-      <para>Un repositorio típico de Subversion a menudo contiene los archivos
-        (o el código fuente) de varios proyectos; usualmente cada proyecto es
+      <para>Un repositorio típico de Subversion contiene a menudo los archivos
+        (o el código fuente) de varios proyectos; normalmente, cada proyecto es
         un subdirectorio en el árbol del sistema de archivos del repositorio.
-        En este arreglo, la copia de trabajo de un usuario usualmente
-        corresponderá a un sub-árbol particular del repositorio.</para>
+        En esta disposición, la copia de trabajo de un usuario se corresponde 
+        habitualmente con un subárbol particular del repositorio.</para>
       
-      <para>Por ejemplo, supónga que usted tiene un repositorio que contiene
+      <para>Por ejemplo, suponga que usted tiene un repositorio que contiene
         dos proyectos de software, <literal>paint</literal> y
-        <literal>calc</literal>. Cada proyecto vive en su propio subdirectorio
-        en la raíz, tal como se muestra en <xref
+        <literal>calc</literal>. Cada proyecto reside en su propio subdirectorio
+        dentro del directorio raíz, tal como se muestra en <xref
         linkend="svn-ch-2-dia-6"/>.</para>
 
       <figure id="svn-ch-2-dia-6">
@@ -306,13 +308,13 @@
       
       <!--TODO: buscar un mejor termino en castellano para explicar 'check
       out'-->
-      <para>Para conseguir una copia de trabajo, usted debe primero ejecutar
-        un <firstterm>check out</firstterm> de algún sub-árbol del
-        repositorio. (El término en inglés puede sonar como que tiene algo que
-        ver con bloquear o reservar recursos, pero esto no sucede; simplemente
-        le crea una copia privada del proyecto). Por ejemplo, si usted hace un
-        check out de <filename>/calc</filename>, obtendrá una copia de
-        trabajo como esta:</para>
+      <para>Para conseguir una copia de trabajo, debe ejecutar primero
+        un <firstterm>check out</firstterm> de algún subárbol del
+        repositorio. (El término inglés <quote>check out</quote> puede sonar como 
+        si tuviera algo que ver con bloquear o reservar recursos, pero no es así; 
+        tan sólo crea una copia privada del proyecto para usted). Por ejemplo, si 
+        usted hace un check out de <filename>/calc</filename>, obtendrá una copia de
+        trabajo como ésta:</para>
 
 <screen>
 $ svn checkout http://svn.example.com/repos/calc
@@ -326,21 +328,21 @@
 </screen>
 
 
-      <para>La lista de letras A indica que Subversion esta agregando un
-        número de ítems a su copia de trabajo. Usted ahora tiene una copia
+      <para>La lista de letras A indica que Subversion está añadiendo una
+        serie de elementos a su copia de trabajo. Usted ahora tiene una copia
         personal del directorio <filename>/calc</filename> del repositorio,
-        con una entrada adicional—<filename>.svn</filename>—la
-        cual contiene la información extra que Subversion necesita, como se
+        con una entrada adicional—<filename>.svn</filename>—que
+        contiene la información extra que Subversion necesita, tal y como se
         mencionó anteriormente.</para>
 
       <sidebar id="svn-ch-2-sidebar-1">
         <title>URLs del Repositorio</title>
 
         <para>A los repositorios de Subversion se puede acceder a través de
-          diferentes métodos—en el disco local, o través de varios
-          protocolos de red. Sin embargo, una ubicación de repositorio siempre
-          es un URL. La tabla 2-1 describe como los diversos esquemas de URL
-          se conectan con los distintos métodos de acceso.</para>
+          diferentes métodos—en el disco local, o a través de varios
+          protocolos de red. Sin embargo, la ubicación de un repositorio es siempre
+          un URL. La tabla 2-1 describe la correspondencia entre los diferentes 
+          esquemas de URL y los métodos de acceso disponibles.</para>
 
         <table id="svn-ch-2-table-1">
           <title>URLs de Acceso al Repositorio</title>
@@ -348,7 +350,7 @@
             <thead>
               <row>
                 <entry>Esquema</entry>
-                <entry>Método de Acceso</entry>
+                <entry>Método de acceso</entry>
               </row>
             </thead>
             <tbody>
@@ -358,7 +360,7 @@
               </row>
               <row>
                 <entry><literal>http://</literal></entry>
-                <entry>acceso via el protocolo WebDAV a un servidor
+                <entry>acceso vía protocolo WebDAV a un servidor
                   Apache que entiende de Subversion</entry>
               </row>
               <row>
@@ -368,13 +370,13 @@
               </row>
               <row>
                 <entry><literal>svn://</literal></entry>
-                <entry>acceso via un protocolo personalizado a un servidor
+                <entry>acceso vía un protocolo personalizado a un servidor
                   <literal>svnserve</literal>.</entry>
               </row>
               <row>
                 <entry><literal>svn+ssh://</literal></entry>
                 <entry>igual que <literal>svn://</literal>, pero a través de 
-                  un túnel de SSH.</entry>
+                  un túnel SSH.</entry>
               </row>
             </tbody>
           </tgroup>
@@ -382,11 +384,11 @@
  
         <para>En general, los URLs de Subversion utilizan la sintaxis
           estándar, permitiendo la especificación de nombres de servidores 
-          y números de puerto como parte del URL. Recuerde que el método
+          y números de puertos como parte del URL. Recuerde que el método
           de acceso <literal>file:</literal> es válido sólo para ubicaciones
-          en el mismo servidor donde corre el cliente—de hecho, se
-          requiere por convención que la porción del URL con el nombre del 
-          servidor este ausente o sea <literal>localhost</literal>:</para>
+          en el mismo servidor donde se ejecuta el cliente—de hecho, se
+          requiere por convención que la parte del URL con el nombre del 
+          servidor esté ausente o sea <literal>localhost</literal>:</para>
 
         <screen>
 $ svn checkout file:///ruta/a/repositorio
@@ -399,7 +401,7 @@
           plataformas Windows necesitarán usar una sintaxis
           <quote>estándar</quote> extraoficial para acceder  a repositorios
           que están en la misma máquina, pero en una unidad de disco distinta
-          de la que el cliente este utilizando en el momento. Cualquiera de
+          de la que el cliente esté utilizando en el momento. Cualquiera de
           las dos siguientes sintaxis para rutas de URL funcionarán siendo
           <literal>X</literal> la unidad donde reside el repositorio:</para>
 
@@ -410,11 +412,11 @@
 …
 </screen>
  
-        <para>En la segunda sintaxis, es necesario encerrar el URL en comillas
-          para que la barra vertical no sea interpretada como un pipe.</para>
+        <para>En la segunda sintaxis, es necesario encerrar el URL entre comillas
+          para que la barra vertical no sea interpretada como una tubería.</para>
 
-        <para>Nótese que un URL usa diagonales ordinarias aún cuando la forma
-          de ruta nativa (no para URLs), en Windows utiliza diagonales
+        <para>Nótese que un URL usa barras de separación ordinarias aún cuando 
+          la forma de ruta nativa (no para URLs) en Windows utiliza barras
           invertidas.</para>
 
       </sidebar>
@@ -423,10 +425,10 @@
       'check in' -->
       <para>Suponga que hace cambios a <filename>button.c</filename>. Puesto
         que el directorio <filename>.svn</filename> recuerda la fecha de
-        modificación y contenido original del archivo, Subversion puede darse
-        cuenta que ha cambiado el mismo. Sin embargo, Subversion no hace
-        públicos sus cambios hasta que se lo mande explícitamente. El acto de
-        publicar sus cambios es comúnmente conocido como 
+        modificación del archivo y su contenido original, Subversion es capaz de 
+        darse cuenta de que el archivo ha cambiado. Sin embargo, Subversion no hará
+        públicos sus cambios hasta que usted no le diga explícitamente que lo haga. 
+        El acto de publicar sus cambios es conocido comúnmente como 
         <firstterm>consignar</firstterm> (o <firstterm>registrar</firstterm>)
         los cambios al repositorio.</para>
 
@@ -441,22 +443,22 @@
 </screen>
 
       <para>Ahora sus cambios a <filename>button.c</filename> han sido
-        consignados al repositorio; si otro usuario baja una copia de trabajo
-        de <filename>/calc</filename>, él verá sus cambios en la última
+        consignados al repositorio; si otro usuario obtiene una copia de trabajo
+        de <filename>/calc</filename>, podrá ver sus cambios en la última
         versión del archivo.</para>
 
-      <para>Suponga que tiene un colaborador, Sally, quien "descargo" una
+      <para>Suponga que tiene un colaborador, Sally, quien obtuvo una
         copia de trabajo de <filename>/calc</filename> al mismo tiempo
-        que usted lo hizo.  Cuando usted envía su cambio de 
+        que usted. Cuando usted envía sus cambios sobre
         <filename>button.c</filename>, la copia de trabajo de Sally se deja
         sin cambios; Subversion solo modifica las copias de trabajo a
         petición del usuario.</para>
 
-      <para>Para tener su proyecto actualizado, Sally puede pedirle a
-        Subversion <firstterm>actualizar</firstterm> su copia de trabajo,
-        usando el comando <command>update</command> de Subversion.
-        Esto incorporará los cambios de usted en la copia de trabajo de Sally, así
-        como los otros que hayan sido consignados desde que ella envió sus cambios.</para>
+      <para>Para tener su proyecto actualizado, Sally puede pedir a
+        Subversion que proceda a <firstterm>actualizar</firstterm> su copia de 
+        trabajo, usando para ello el comando <command>update</command> de Subversion.
+        Ésto incorporará los cambios hechos por usted en la copia de trabajo de Sally, 
+        así como otros cambios consignados desde que ella hizo el check out.</para>
 
 <screen>
 $ pwd
@@ -470,12 +472,12 @@
 </screen>
 
       <para>La salida del comando <command>svn update</command>
-        indica que Subversion actualizo el contenido de
-        <filename>button.c</filename>.  Nota que Sally no necesito
-        especificar que archivos actualizar; Subversion usa la información
-        en el directorio <filename>.svn</filename>, e 
-        información adicional en el repositorio, para decidir que archivos necesitan
-        ser traídos y actualizados.</para>
+        indica que Subversion actualizó el contenido de
+        <filename>button.c</filename>. Observe que Sally no necesitó
+        especificar qué archivos actualizar; Subversion usa la información
+        del directorio <filename>.svn</filename>, junto con 
+        información adicional del repositorio, para decidir qué archivos 
+        necesitan una actualización.</para>
       
     </sect2>
     




More information about the svnbook-dev mailing list