[svnbook commit] r2411 - in trunk/src/es: . book
gradha
noreply at red-bean.com
Sun Sep 10 06:36:33 CDT 2006
Author: gradha
Date: Sun Sep 10 06:36:33 2006
New Revision: 2411
Added:
trunk/src/es/book/ch05.xml.aspell_ignore (contents, props changed)
Modified:
trunk/src/es/.aspell_ignore
trunk/src/es/Makefile
trunk/src/es/book/ch02.xml.aspell_ignore
trunk/src/es/book/ch05.xml
trunk/src/es/glosario_traduccion
Log:
Book Spanish. Put ch05 under aspell control. Performed multiple
changes due to spell checking.
Modified: trunk/src/es/.aspell_ignore
==============================================================================
--- trunk/src/es/.aspell_ignore (original)
+++ trunk/src/es/.aspell_ignore Sun Sep 10 06:36:33 2006
@@ -58,6 +58,7 @@
creative
Creative
Cygwin
+datestamp
DAV
dbrouard
Debian
Modified: trunk/src/es/Makefile
==============================================================================
--- trunk/src/es/Makefile (original)
+++ trunk/src/es/Makefile Sun Sep 10 06:36:33 2006
@@ -6,7 +6,7 @@
include ../tools/Makefile.base
BOOK_ASPELL_FILES = appa appb book foreword ch00 ch01 ch02 ch03 ch04 \
- ch06 ch07 ch08 ch09
+ ch05 ch06 ch07 ch08 ch09
OTHER_ASPELL_FILES = COORDINADOR glosario_traduccion LEAME TODO TRABAJO
aspell_add_words:
Modified: trunk/src/es/book/ch02.xml.aspell_ignore
==============================================================================
--- trunk/src/es/book/ch02.xml.aspell_ignore (original)
+++ trunk/src/es/book/ch02.xml.aspell_ignore Sun Sep 10 06:36:33 2006
@@ -22,6 +22,7 @@
paint
pwd
revision
+sally
Sending
serialización
SSH
Modified: trunk/src/es/book/ch05.xml
==============================================================================
--- trunk/src/es/book/ch05.xml (original)
+++ trunk/src/es/book/ch05.xml Sun Sep 10 06:36:33 2006
@@ -51,9 +51,9 @@
¿Qué pinta tiene? ¿Cómo se siente? ¿Se toma el té caliente o helado,
dulce, y con limón? Como administrador, necesitará entender la
composición de un repositorio desde una perspectiva lógica—
- <!--TODO: deal-->dealing con cómo se representa la información
+ <!--TODO: deal-->entendiendo cómo se representa la información
dentro del repositorio—y desde una perspectiva <!--TODO:
- nuts-and-bolts-->—qué apariencia tiene y cómo actúa un
+ nuts-and-bolts-->práctica—qué apariencia tiene y cómo actúa un
repositorio con respecto a herramientas no pertenecientes a Subversion.
La siguiente sección se ocupa de algunos de estos conceptos básicos
a un nivel muy alto.</para>
@@ -76,7 +76,7 @@
( junto a cualquier cambio adicional que haya podido tener lugar
desde el comienzo del proceso de envío de datos),
y luego pide al repositorio que guarde ese árbol como la próxima
- <!--TODO: snapshot=fotografía -->fotograría en la secuencia.
+ <!--TODO: snapshot=fotografía -->fotografía en la secuencia.
Si el envío de datos no da error, la transacción se convierte
en una nueva revisión del árbol, y se le asigna un nuevo número de
revisión. Si el envío de datos fallara por alguna razón,
@@ -86,7 +86,7 @@
prepara un árbol de transacción temporal que <!--mirrors=copia?-->copia el estado
de la copia de trabajo. El repositorio compara entonces ese
árbol de transacción con el árbol de la revisión solicitada
- (normalmente la más reciente, o el árbol <quote>youngest</quote>), e
+ (normalmente la más reciente, o el árbol <quote>más joven</quote>), e
informa al cliente acerca de qué cambios son necesario para
convertir su copia local de trabajo en una réplica de ese árbol
de revisión. Tras completarse la actualización, se borra la transacción
@@ -98,8 +98,8 @@
entender que el tiempo de vida de una transacción es completamente
flexible. En el caso de actualizaciones, las transacciones con árboles
temporales que se destruyen inmediatamente. En el caso de <!--TODO commits-->
- commits, las transacciones son transformadas en revisiones
- permanentes ( o borradas si el <!--TODO--> falla ). En el
+ envíos al repositorio, las transacciones son transformadas en revisiones
+ permanentes ( o borradas si el envío falla ). En el
caso de un error, es posible que una transacción permanezca
accidentalmente suelta en el repositorio ( sin que afecte
en realidad a nada, pero ocupando espacio).</para>
@@ -110,7 +110,7 @@
cada transacción <!--TODO slated???--> que se convierta en
revisión permanezca en <!--TODO: stasis?? --> bastante después
de que el cliente termine de describir sus cambios al repositorio.
- Esto permitiría que cada nuevo <!--commit --> sea revisado
+ Esto permitiría que cada nuevo envío <!--commit --> sea revisado
por alguna otra persona, quizás un <!--manager-->director o
<!--TODO:engineering QA team-->, que pueda elegir entre promoverla
a una revisión, o cancelarla.</para>
@@ -122,32 +122,33 @@
<title>Propiedades no versionadas</title>
<para>Las transacciones y las revisiones en el repositorio
- subversion pueden tener propiedades adjuntas. Estas propiedades
- son mapeos genéricos clave-valor, y generalmente se usan
+ Subversion pueden tener propiedades adjuntas. Estas propiedades
+ son relaciones genéricas clave-valor, y generalmente se usan
para guardar información acerca del árbol al que están adjuntas.
Los nombres y valores de estas propiedades se guardan en el
sistema de ficheros del repositorio, junto con el resto de
los datos de tu árbol.</para>
<para>Las propiedades de revisiones y transacciones son útiles para
- asociar información con un árbol que no está estríctamente
+ asociar información con un árbol que no está estrictamente
relacionada con los ficheros y directorios de ese árbol—el
tipo de información que no es gestiona por las copias de trabajo
- de cliente. Por ejemplo, cuando una nueva transacción commit es
- creada en el repositorio, Subversion añade una propiedad a dicha
- transacción llamada <literal>svn:date</literal>— un
- datestamp <!--TODO: ¿traducir esto?--> que representa el momento
- en que la transacción se creó. En el momento que el proceso
- de commit termina, el árbol también ha recibido una propiedad
- para guardar el nombre del usuario que es autor de la revisión
+ de cliente. Por ejemplo, cuando una nueva transacción de
+ envío<!-- TODO commit --> es creada en el repositorio,
+ Subversion añade una propiedad a dicha transacción
+ llamada <literal>svn:date</literal>— una marca de
+ tiempo que representa el momento en que la transacción se
+ creó. En el momento que el proceso de envío <!-- TODO commit
+ -->termina, el árbol también ha recibido una propiedad para
+ guardar el nombre del usuario que es autor de la revisión
(<literal>svn:author</literal>) y una propiedad para guardar
- el mensaje de log <!--TODO: ¿traducir?--> adjunto a dicha
- revisión (<literal>svn:log</literal>).</para>
+ el mensaje de informe de cambios adjunto a dicha revisión
+ (<literal>svn:log</literal>).</para>
<para>Las propiedades de revisiones y transacciones son
<firstterm>propiedades no versionada</firstterm>—cuando
son modificadas, sus valores previos se descartan definitivamente.
- Asímismo, mientras los árboles de revisiones en sí son inmutables,
+ Así mismo, mientras los árboles de revisiones en sí son inmutables,
las propiedades adjuntas de dichos árboles no lo son. Puedes añadir,
borrar, y modificar propiedades de revisiones en cualquier momento
más adelante. Si envías al repositorio una nueva revisión y más tarde
@@ -160,12 +161,12 @@
<!-- ***************************************************************** -->
<sect2 id="svn-ch-5-sect-1.3">
- <title>Berkeley DB</title>
+ <title>Base de datos Berkeley</title>
<para>Los datos almacenados dentro de repositorios Subversion,
realmente se encuentran en una base de datos, más concretamente,
- un fichero de base de datos Berkley DB. Durante la fase inicial
- de diseño de Subversion, los desarrolladores decicieron usar
+ un fichero de base de datos Berkeley. Durante la fase inicial
+ de diseño de Subversion, los desarrolladores decidieron usar
una base de datos Berkeley por una serie de razones, como
su licencia open-source, soporte de transacciones, ser de confianza,
funcionamiento, simplicidad de su API, soporte de hilos, cursores,
@@ -173,8 +174,8 @@
<para>La base de datos Berkeley tiene un soporte real de transacciones
—probablemente es su característica más poderosa.
- Muchos procesos que accede a tus repositorios Subversion
- not tienen que preocuparse por <!--TODO: ¿clobbering? --> los
+ Muchos procesos que acceden a sus repositorios Subversion
+ no tienen que preocuparse por pisotear <!--TODO: ¿clobbering? --> los
datos de otros. El aislamiento provisto por el sistema de
transacciones es tal que por cada operación dada, el código
de repositorio Subversion tiene una vista estática de la base
@@ -196,9 +197,9 @@
de ser capaz de hacer copias completas y funcionales de tus
repositorios sin <!--TODO:downtime--> debería ser obvia.</para>
- <para>La base de datos Berkely también es un sistema de bases de
+ <para>La base de datos Berkeley también es un sistema de bases de
datos de mucha confianza. Subversion utiliza las utilidades
- de registro de las BD Berkeley, lo que significa
+ de registro de las bases de datos Berkeley, lo que significa
que la base datos primero escribe una descripción de cualquier
modificación que vaya a hacer en ficheros de registros, para luego
hace la propia modificación. Esto es para asegurar que si
@@ -208,22 +209,22 @@
corruptas—y repetir transacciones hasta que los datos estén
en un estado usable. Ver <xref linkend="svn-ch-5-sect-3.3"/>
si quieres más información acerca de los ficheros de registro
- de las BD Berkeley.</para>
+ de las bases de datos de Berkeley.</para>
<para>Pero toda rosa tiene su espina, así que tenemos que
- hablar sobre algunas conocidas limitaciones de la BD Berkeley.
- Primero, los entornos de BD Berkeley no son portables. No puedes
+ hablar sobre algunas conocidas limitaciones de la base de datos Berkeley.
+ Primero, los entornos de base de datos Berkeley no son portables. No puedes
copiar simplemente un repositorio Subversion que fue creado
en un sistema Unix a un sistema Windows y esperar que funcione.
- Mientras mucho del formato de base de datos de la BD Berkeley
- es independiente de la arquitectura, hay otros aspectos del
- entorno que no lo son.
- Segundo, Subversion usa BD Berkeley de una manera que no puede
+ A pesar de que la mayor parte del formato de base de datos
+ Berkeley es independiente de la arquitectura, hay otros
+ aspectos del entorno que no lo son.
+ Segundo, Subversion usa la base de datos Berkeley de una manera que no puede
funcionar en sistemas Windows 95/98—si necesita almacenar
un repositorio en una máquina Windows, <!--TODO stick-->utilice
Windows 2000 o Windows XP. Finalmente, no deberías mantener un
repositorio Subversion en una unidad compartida por red. Mientras
- las BD Berkeley prometen un comportamiento correcto en unidades
+ las bases de datos Berkeley prometen un comportamiento correcto en unidades
compartidas por red que cumplan un grupo particular de especificaciones,
casi ningún sistema de compartición conocido cumple con todas
esas especificaciones.</para>
@@ -257,12 +258,12 @@
<warning>
<para>No crees tu repositorio en una unidad de red compartida
—no <emphasis>puede</emphasis> existir un un sistema
- de ficheros remoto como NFS, AFS, o Windows SMB. La DB Berkeley
+ de ficheros remoto como NFS, AFS, o Windows SMB. La base de datos Berkeley
necesita que el sistema de ficheros subyacente implemente
estrictamente la semántica de bloqueo POSIX, y más importante,
la habilidad para mapear ficheros directamente <!--TODO into
process memory.--> Casi ningún sistema de ficheros de red
- tiene estas características. Si intentas usar una BD Berkeley
+ tiene estas características. Si intentas usar una base de datos Berkeley
en una unidad compartida de red, los resultados son impredecibles
—puede que veas errores misteriosos, o pueden pasar meses
hasta que descubras que la base de datos de tu repositorio está
@@ -323,7 +324,7 @@
<varlistentry>
<term>db</term>
<listitem>
- <para>El entorno principal de la BD Berkeley, lleno de tablas
+ <para>El entorno principal de la base de datos Berkeley, lleno de tablas
que <!--TODO:comprise--> el almacenamiento de datos para
el sistema de ficheros de Subversion ( donde todos tus
datos versionados residen.</para>
@@ -339,8 +340,8 @@
<varlistentry>
<term>hooks</term>
<listitem>
- <para>Un directorio lleno de <!--hook script templates-->
- ( y los mismos <!--TODO: hook scripts-->, una vez que hayas instalados
+ <para>Un directorio lleno de plantillas de ganchos
+ (y los mismos ganchos), una vez que hayas instalados
algunos.</para>
</listitem>
</varlistentry>
@@ -365,26 +366,26 @@
<quote>a mano</quote>. La herramienta <command>svnadmin</command>
debería ser suficiente para cualquier cambio necesarios en tu
repositorio, o puedes echar una ojeada a herramientas de terceros
- ( como la suite<!--TODO: suite-->de herramientas de la BD Berkeley )
+ ( como la suite<!--TODO: suite-->de herramientas de la base de datos Berkeley )
para <!--TODO: tweaking--> subsecciones relevantes del repositorio.
Sin embargo, hay algunas excepciones, y las veremos aquí.</para>
<!-- ***************************************************************** -->
<sect2 id="svn-ch-5-sect-2.1">
- <title>Hook Scripts</title>
+ <title>Scripts de enganche</title>
<!--TODO: párrafo complicado, revisar -->
- <para>Un <firstterm><!--TODO: hook-->hook</firstterm> es un programa
- <!--TODO: triggered --> por algún evento del repositorio, como la
+ <para>Un <firstterm>gancho</firstterm> es un programa
+ activado por algún evento del repositorio, como la
creación de una nueva revisión o la modificación de una propiedad
- no versionada. A cada hook se le da suficiente información para
+ no versionada. A cada gancho se le da suficiente información para
que sepa de qué evento se trata, cuál es su objetivo, y el nombre
de usuario de la persona que disparó el evento. Dependiendo de
- la salida del hook o de estado de su salida, el programa hook
+ la salida del gancho o de estado de su salida, el programa de enganche
puede continuar la acción, pararla, o suspenderla de alguna manera.</para>
<para>El subdirectorio <filename>hooks</filename> se rellena,
- por defecto, con plantillas para varios hooks de repositorio.</para>
+ por defecto, con plantillas para varios ganchos de repositorio.</para>
<screen>
$ ls repos/hooks/
@@ -393,50 +394,50 @@
pre-commit.tmpl
</screen>
- <para>Hay una plantilla por cada hook que implementa el repositorio
+ <para>Hay una plantilla por cada gancho que implementa el repositorio
Subversion, y examinando los contenidos de dichas plantillas
- de scripts, puede ver qué <!--TODO triggers><-->triggers ejecuta
+ de scripts, puede ver qué disparador ejecuta
cada script y qué datos se le pasan. También se encuentran
en muchas de estas plantillas ejemplos de cómo debería usar
dicho script, conjuntamente con otros programas provistos
por Subversion, para realizar tareas comunes y útiles. Para instalar
- realmente un hook funcional, sólo necesita colocar algún ejecutable
+ realmente un gancho funcional, sólo necesita colocar algún ejecutable
o script en el directorio <filename>repos/hooks</filename> que pueda
- ser ejecutado con el nombre del hook ( como <command>start-commit</command>
+ ser ejecutado con el nombre del gancho ( como <command>start-commit</command>
o <command>post-commit</command>).</para>
<para>En plataformas Unix, esto significa proveer un script o
programa (podría ser un shell script, un programa Python,
un binario C compilado, o cualquier otra cosa) llamado
- exactamente igual que el nombre del hook. Por supuesto,
+ exactamente igual que el nombre del gancho. Por supuesto,
los ficheros de plantillas están presentes para algo más
que sólo propósitos informativos—la manera más fácil de
- instalar un hook en plataformas Unix es simplemente copiar
+ instalar un gancho en plataformas Unix es simplemente copiar
el fichero de plantilla apropiado en un nuevo fichero sin la
extensión <literal>.tmpl</literal>, personalizando los contenidos
- del hook, y asegurándose de que el script sea ejecutable.
+ del gancho, y asegurándose de que el script sea ejecutable.
Windows, sin embargo, usa extensiones de fichero para determinar
si un programa es ejecutable o no, así que debería dar poner
- un programa cuyo nombre sea el nombre del hook, y cuya extensión
+ un programa cuyo nombre sea el nombre del gancho, y cuya extensión
sea una de las extensiones especiales reconocidas por Windows
como ficheros ejecutables, como <filename>.exe</filename> o
<filename>.com</filename> para programas, y <filename>.bat</filename>
para ficheros de scripts.</para>
- <para>Actualmente hay cinco hooks implementados por el
+ <para>Actualmente hay cinco ganchos implementados por el
repositorio Subversion:</para>
<variablelist>
<varlistentry>
<term><filename>start-commit</filename></term>
<listitem>
- <para>Se ejecuta antes de la transacción commit haya sido
+ <para>Se ejecuta antes de la transacción de envío haya sido
creada. Se usa normalmente para decidir si el usuario
tiene los privilegios suficientes. El repositorio pasa
dos argumentos a este programa: la ruta al repositorio,
- y el nombre de usuario que intenta realizar el commit.
+ y el nombre de usuario que intenta realizar el envío.
Si el programa devuelve algún valor distinto de cero, se
- paraliza el commit antes de haber creado la transacción.</para>
+ paraliza el envío antes de haber creado la transacción.</para>
</listitem>
</varlistentry>
@@ -444,16 +445,16 @@
<term><filename>pre-commit</filename></term>
<listitem>
<para>Se ejecuta cuando se completa la transacción, pero
- antes de ser enviados los datos al respositorio. Este hook
- se usa normalmente como protección contra commits que no se
- permiten debido a contenido o ubicación ( por ejemplo, tu
- sitio puede requerir que todos los commits a una rama
+ antes de ser enviados los datos al repositorio. Este gancho
+ se usa normalmente como protección contra envíos que no se
+ permiten debido a contenido o ubicación ( por ejemplo, su
+ sitio puede requerir que todos los cambios sobre una rama
determinada incluyan un número de ticket del seguimiento de
- fallos, o que el mensaje de log entrante no esté vacío).
+ fallos, o que el mensaje de informe de cambios entrante no esté vacío).
El repositorio pasa dos argumentos a este programa: la ruta
al repositorio, y el nombre de la transacción que va a sufrir
- el commmit. Si el programa devuelve una salida que no sea cero,
- el commit se aborta y la transacción se borra.</para>
+ el cambio. Si el programa devuelve una salida que no sea cero,
+ el envío se aborta y la transacción se borra.</para>
<para>La distribución Subversion incluye algunos scripts de
control de acceso ( ubicados en el directorio
@@ -474,7 +475,7 @@
<listitem>
<para>Esto se ejecuta después de que la transacción se haya
confirmado, y una nueva revisión haya sido creada. La mayoría
- de la gente usa este hook para enviar correos descriptivos
+ de la gente usa este gancho para enviar correos descriptivos
acerca de la confirmación o para hacer una copia de seguridad
del repositorio. El repositorio pasa dos argumentos a este
programa: la ruta al repositorio, y el número de la nueva
@@ -509,22 +510,22 @@
<listitem>
<para>Al no ser versionadas las propiedades de revisión de Subversion,
hacer modificaciones a una de ellas ( como por ejemplo,
- el mensaje de commit <literal>svn:log</literal> )
+ el mensaje de informe de cambios <literal>svn:log</literal> )
sobreescribirá el valor previo de esa propiedad para siempre.
Como hay datos aquí que potencialmente se pueden perder,
- Subversion provee este hook ( y su contrapartida,
+ Subversion provee este gancho ( y su contrapartida,
<filename>post-revprop-change</filename>) de tal manera
que los administradores de repositorios puedan mantener
con métodos externos si así lo desean, registros de los
cambios de dichas propiedades. Como precaución contra
- la pérdidad de datos de propiedades no versionadas,
+ la pérdida de datos de propiedades no versionadas,
no se permite a los clientes Subversion modificarlos
- del todo remotamente a no ser que este hook se implemente
+ del todo remotamente a no ser que este gancho se implemente
para su repositorio.</para>
- <para>Este hook se ejecuta justo antes de que una modificación
+ <para>Este gancho se ejecuta justo antes de que una modificación
de este tipo se haga en el repositorio. El repositorio pasa
- cuatro argumentos al hook: la ruta al repositorio, la revisión
+ cuatro argumentos al gancho: la ruta al repositorio, la revisión
en la cual la propiedad que se va a modificar existe,
el nombre autenticado de usuario de la persona que va a hacer
el cambio, y el nombre mismo de la propiedad.</para>
@@ -534,15 +535,15 @@
<varlistentry>
<term><filename>post-revprop-change</filename></term>
<listitem>
- <para>Como se ha mencionado antes, este hook es la contrapartida
- del hook <filename>pre-revprop-change</filename>. De hecho,
+ <para>Como se ha mencionado antes, este gancho es la contrapartida
+ del gancho <filename>pre-revprop-change</filename>. De hecho,
por paranoia, este script no se ejecutará a no ser que el
- hook <filename>pre-revprop-change</filename> exista.
- Cuando ambos están presentes, el hook <filename>post-revprop-change</filename>
+ gancho <filename>pre-revprop-change</filename> exista.
+ Cuando ambos están presentes, el gancho <filename>post-revprop-change</filename>
se ejecuta justo después de que una propiedad de revisión
haya sido modificad, y se usa típicamente para enviar un
correo electrónico con el nuevo valor de la propiedad
- cambiada. El repositorio pasa cuatro argumentos al hook:
+ cambiada. El repositorio pasa cuatro argumentos al gancho:
la ruta al repositorio, la revisión en la cual la propiedad
existe, el nombre autenticado de usuario de la persona
que va a hacer el cambio y el nombre mismo de la propiedad.</para>
@@ -560,32 +561,32 @@
</varlistentry>
</variablelist>
- <para>Subversión tratará de ejecutar los hooks como el mismo
- usuario que posee el proces que está accediendo al repositorio
+ <para>Subversión tratará de ejecutar los ganchos como el mismo
+ usuario que posee el proceso que está accediendo al repositorio
Subversion. En la mayoría de los casos, el repositorio se
accede a través del servidor HTTP Apache y mod_dav_svn, así que
este usuario es el mismo que el usuario con el que se ejecuta
- Apache. Los mismos hooks necesitarán ser configurados con permisos
+ Apache. Los mismos ganchos necesitarán ser configurados con permisos
a nivel de sistema operativo que les permitan ser ejecutados
por dicho usuario. Asimismo, esto significa que cualquier fichero
o programas ( incluyendo el repositorio mismo ) al que acceda
- directa o indirectamente el hook, será a través del mismo usuario.
+ directa o indirectamente el gancho, será a través del mismo usuario.
En otras palabras, esté alerta a problemas potenciales relacionados
- con permisos que impidan al hook realizar las tareas para las cuales
+ con permisos que impidan al gancho realizar las tareas para las cuales
lo haya escrito.</para>
</sect2>
<!-- ***************************************************************** -->
<sect2 id="svn-ch-5-sect-2.2">
- <title>Configuración de la Base de Datos Berkeley</title>
+ <title>Configuración de la base de datos Berkeley</title>
- <para>Un entorno de base de datos Berkekely es una encapsulación
+ <para>Un entorno de base de datos Berkeley es una encapsulación
de una o más bases de datos, ficheros de registro, ficheros
regionales y ficheros de configuración. El entorno de base de datos
- Berkely tiene su propio conjunto de valores de configuración
+ Berkeley tiene su propio conjunto de valores de configuración
por defecto para cosas como el número de bloqueos que se permite eliminar
- de una sóla vez, o el tamaño máximo de los ficheros de registro
+ de una sola vez, o el tamaño máximo de los ficheros de registro
<!--TODO: journaling-->, etc. El código del sistema de ficheros
de Subversion elige además valores por defecto para algunas
de las opciones de configuración de la base de datos Berkeley.
@@ -593,7 +594,7 @@
con su colección única de datos y patrones de acceso, podría
necesitar un grupo diferente de valores de configuración.</para>
- <para>La gente de Sleepycat ( los progamadores de la base de datos
+ <para>La gente de Sleepycat ( los programadores de la base de datos
Berkeley ) entienden que bases de datos diferentes, tienen
requerimientos específicos, de tal manera, que nos proveen
de un mecanismo para sobreescribir en tiempo de ejecución,
@@ -608,14 +609,14 @@
en <filename>repos/db/DB_CONFIG</filename>. Subversion crea
por sí mismo el fichero al mismo tiempo que el resto del repositorio.
El fichero inicialmente contiene algunas opciones por defecto,
- así como enlaces a la documentacion en línea de la BD Berkeley
+ así como enlaces a la documentación en línea de la base de datos Berkeley
de tal manera que pueda saber qué significan dichas opciones.
Por supuesto, es libre de añadir cualquiera de las opciones soportadas
- por la BD Berkeley a su fichero <filename>DB_CONFIG</filename>.
+ por la base de datos Berkeley a su fichero <filename>DB_CONFIG</filename>.
Tan sólo tenga cuidado porque mientras Subversion no trata de
leer o interpretar los contenidos del fichero, y no hace uso
de sus opciones de configuración, tendrá que evitar cualquier
- cambio en la configuración que pueda causar que la BD Berkeley
+ cambio en la configuración que pueda causar que la base de datos Berkeley
se comporte de una manera inesperada para el resto del código
de Subversion. Por otra parte, los cambios hechos en
<filename>DB_CONFIG</filename> no tendrán efecto hasta que
@@ -645,10 +646,10 @@
<title>Una caja de herramientas del Administrador</title>
<para>Subversion provee un conjunto de utilidades para crear
- inspecciononar, modificar y reparar sus repositorio.
+ inspeccionar, modificar y reparar sus repositorio.
Estudiemos más de cerca cada una de estas herramientas.
- Más tarde, examinaremos brevemente otras incluídas en la
- distribución de la BD Berkeley que añaden funcionalidades
+ Más tarde, examinaremos brevemente otras incluidas en la
+ distribución de la base de datos Berkeley que añaden funcionalidades
específicas al motor de base de datos de las que no disponen
las herramientas propias de Subversion.</para>
@@ -661,14 +662,14 @@
no intente en ningún momento cambiar el repositorio
—es una utilidad de <quote>sólo lectura</quote>.
<command>svnlook</command> es utilizada normalmente por
- los <!--TODO-->hooks del repositorio para informar acerca
+ los ganchos del repositorio para informar acerca
de los cambios que se van a realizar ( en el caso del
- hook <command>pre-commit</command> ) o que se acaban de
- hacer ( en el caso del hook <command>post-commit</command> )
+ gancho <command>pre-commit</command> ) o que se acaban de
+ hacer ( en el caso del gancho <command>post-commit</command> )
en el repositorio. Un administrador del repositorio puede
usar esta herramienta para diagnosis.</para>
- <para><command>svnlook</command> tiene una sintáxis muy simple:</para>
+ <para><command>svnlook</command> tiene una sintaxis muy simple:</para>
<screen>
$ svnlook help
@@ -718,7 +719,7 @@
19
</screen>
- <para>La salida de <command>svnlook</command> está diseñanda para que
+ <para>La salida de <command>svnlook</command> está diseñada para que
sea, a la vez, legible por humanos y por máquinas. Cojamos como ejemplo
la salida del subcomando <literal>info</literal>:</para>
@@ -759,7 +760,7 @@
tamaño del mensaje antes que el mismo mensaje. Esto permite a los
<!--TODO scripts--> y otros <!--TODO wrappers--> alrededor de este
comando, tomar decisiones inteligentes acerca del mensaje de registro,
- como cuánta memoria reserverle, o al menos, cuántos bytes saltarse
+ como cuánta memoria reservarle, o al menos, cuántos bytes saltarse
en el evento para que esta salida no sea el último bit de datos en
el flujo.</para>
@@ -925,7 +926,7 @@
<title>svnadmin</title>
<para>El programa <command>svnadmin</command> es el mejor amigo
- del administror del repositorio. Además de darle la posibilidad
+ del administrador del repositorio. Además de darle la posibilidad
de crear repositorios Subversion, le permite realizar
varias operaciones de mantenimiento en ellos. La sintaxis
de <command>svnadmin</command> es parecida a la de
@@ -961,11 +962,12 @@
<varlistentry>
<term><literal>deltify</literal></term>
<listitem>
- <para>Run over a specified revision range, performing
- predecessor deltification on the paths changed in
- those revisions. If no revisions are specified, this
- command will simply deltify the
- <literal>HEAD</literal> revision.</para>
+ <para>Recorre un rango de revisiones específico,
+ realizando la deltificación <!-- TODO delta delta
+ delta --> de predecesores en las rutas modificadas
+ de esas revisiones. Si no se especifica ninguna
+ revisión, este comando simplemente deltificará la
+ revisión <literal>HEAD</literal>.</para>
</listitem>
</varlistentry>
@@ -992,7 +994,7 @@
<term><literal>list-dblogs</literal></term>
<listitem>
<para>Lista las rutas a los ficheros de registro
- de la BD Berkeley asociados al repositorio. Esta lista
+ de la base de datos Berkeley asociados al repositorio. Esta lista
incluye todos los ficheros de registros—aquellos que
están todavía en uso por Subversion, así como los que no
lo están.</para>
@@ -1003,7 +1005,7 @@
<term><literal>list-unused-dblogs</literal></term>
<listitem>
<para>Lista las rutas de los ficheros de registro
- de la BD Berkeley asociados al repositrio, pero que han
+ de la base de datos Berkeley asociados al repositorio, pero que han
dejado de usarse. Puede borrar de forma segura estos ficheros
del entorno del repositorio y archivarlos para el caso de tener
que hacer una recuperación de algún evento catastrófico del repositorio.</para>
@@ -1014,7 +1016,7 @@
<term><literal>load</literal></term>
<listitem>
<para>Carga un grupo de revisiones en un repositorio
- desde un fluno de datos que utilice el mismo formato
+ desde un flujo de datos que utilice el mismo formato
portable de información que el generado por el subcomando
<literal>dump</literal>.</para>
</listitem>
@@ -1108,7 +1110,7 @@
del administrador, <command>svndumpfilter</command> tiene un producto
muy peculiar con una funcionalidad muy útil—la posibilidad de
modificar rápida y fácilmente esos datos de volcado actuando como un
- filtro basado en las rutas. Simplemente, di una lista de rutas que
+ filtro basado en las rutas. Simplemente, diga una lista de rutas que
quieres mantener, o una lista de rutas que no quieres mantener, luego,
dirige tu volcado a través de este filtro. El resultado será un volcado
modificado que contendrá sólo las rutas versionadas que ( explícita
@@ -1155,7 +1157,7 @@
proyecto o combinándolos, organizar todo el material dentro de su
repositorio. A veces, después de que las nuevas revisiones
comienzan a volar, te vuelves a pensar el modelo, y querrías hacer
- algunos cambios. Un cambiio común es la decisión de mover proyectos
+ algunos cambios. Un cambio común es la decisión de mover proyectos
que están compartiendo un sólo repositorio en un repositorio separado
para cada proyecto.</para>
@@ -1257,7 +1259,7 @@
<para>Ambos subcomandos de <command>svndumpfilter</command>
aceptan opciones para decidir cómo tratar las revisiones
<quote>vacías</quote>. Si una revisión dada sólo contenía
- cambios a rutas que fueron excluídas al filtrarlas, podría
+ cambios a rutas que fueron excluidas al filtrarlas, podría
ser considerada como no interesante o incluso ignorada.
Así que, para darle al usuario el control sobre qué hacer con
esas revisiones, <command>svndumpfilter</command> tiene las
@@ -1329,7 +1331,7 @@
que <command>svndumpfilter</command> esté excluyendo a alguna otra
que se esté incluyendo. Para conseguir que los datos volcados
sean autosuficientes, <command>svndumpfilter</command> todavía
- necesita enseñar la adición de la nueva ruta—incluyento los
+ necesita enseñar la adición de la nueva ruta—incluyendo los
contenidos de los ficheros creados por la copia—y no representar
dicha adición como una copia de una fuente que no existirá
en el flujo filtrado de los datos de volcado. Pero debido a que
@@ -1452,7 +1454,7 @@
de <command>svnlook</command>.</para>
<para>Una vez haya acabado de usar la línea de comando, puede
- salir de manera límpia usando el comando
+ salir de manera limpia usando el comando
<command>exit</command>. Alternativamente, puede mandar un
carácter de fin de línea—Control-D (aunque algunas
distribuciones de Python para Win32 usan en su lugar la
@@ -1461,7 +1463,7 @@
</sect3>
<sect3 id="svn-ch-5-sect-3.1.5">
- <title>Utilidades de la BD Berkeley</title>
+ <title>Utilidades de la base de datos Berkeley</title>
<para>Toda la estructura y datos versionados de su sistema
de ficheros viven en un conjunto de tablas de la
@@ -1486,7 +1488,7 @@
engloba los casos de uso habituales de la utilidad
<command>db_recover</command>.</para>
- <para>Aunque todavía hay algunas herramientas de la BD de
+ <para>Aunque todavía hay algunas herramientas de la base de datos
Berkeley que puede encontrar útiles. Los programas
<command>db_dump</command> y <command>db_load</command>
escriben y leen, respectivamente, un fichero de
@@ -1713,7 +1715,7 @@
completadas con éxito, etc— durante la toma de
decisiones. Finalmente, un administrador siempre puede
comunicarse con el autor de una transacción aparentemente
- muerta (via email, por ejemplo) para verificar que la
+ muerta (vía email, por ejemplo) para verificar que la
transacción está, de hecho, en un estado zombi.</para>
</sect2>
@@ -1819,7 +1821,7 @@
<note>
<para>Dado que todos los datos del repositorio Subversion
sujetos a la deltificación se almacenan en un único
- fichero de base de datos Berlekey, reducir el tamaño
+ fichero de base de datos Berkeley, reducir el tamaño
de los valores almacenados no reducirá necesariamente
el tamaño de éste fichero. La base de datos Berkeley no
obstante mantendrá un registro interno de áreas internas
@@ -1863,7 +1865,7 @@
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
+ El sistema de ficheros de Subversion tiene 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
@@ -1871,7 +1873,7 @@
<para>Ej: disco duro + enorme electroimán = desastre.</para>
</footnote>
pueden destruir de manera permanente el entorno de la base de
- datos. Un administrador de repositorio suficientemente paranóico
+ datos. Un administrador de repositorio suficientemente paranoico
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>
@@ -1883,7 +1885,7 @@
<listitem>
<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
+ también significa tener que desconectar el servidor HTTP
Apache.</para>
</listitem>
<listitem>
@@ -1913,7 +1915,7 @@
</listitem>
</orderedlist>
- <para>Este prodecimiento corrige casi todos los casos de bloqueos
+ <para>Este procedimiento 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
@@ -1931,7 +1933,7 @@
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
+ Subversion mantener la integridad de los datos es una prioridad
extremadamente alta.</para>
</sect2>
@@ -1951,7 +1953,7 @@
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
+ <para>La razón más común 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
@@ -1967,11 +1969,11 @@
ficheros de volcado.</para>
</listitem>
<listitem>
- <para>Actualicese a la nueva versión de Subversion.</para>
+ <para>Actualícese a la nueva versión de Subversion.</para>
</listitem>
<listitem>
<para>Mueva sus viejos repositorios a otra parte, y
- crée nuevos repositorios vacíos en su lugar usando su
+ cree nuevos repositorios vacíos en su lugar usando su
<emphasis>nuevo</emphasis> <command>svnadmin</command>.</para>
</listitem>
<listitem>
@@ -1992,7 +1994,7 @@
<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
+ de Subversion 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
@@ -2086,7 +2088,7 @@
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
+ <para>Por defecto, Subversion 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
@@ -2102,7 +2104,7 @@
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
+ Entonces mostrará la primera revisión exactamente 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
@@ -2138,7 +2140,7 @@
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
+ del tiempo en caso de un fallo de sistema o algún otro evento
catastrófico.</para>
<para>El formato de volcado también puede ser usado para fusionar
@@ -2157,7 +2159,7 @@
$
</screen>
- <para>Entonces, crée nuevos directorios en el repositorio que
+ <para>Entonces, cree nuevos directorios en el repositorio que
encapsularán los contenidos de cada uno de los tres repositorios
anteriores:</para>
@@ -2193,10 +2195,10 @@
recuerda al formato RFC-822, el mismo tipo de formato usado
para la mayor parte del correo electrónico.</para>
</footnote>
- debería ser relativamente sencillo describir un conjungo genérico
+ debería ser relativamente sencillo describir un conjunto 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
+ De hecho, la utilidad <command>cvs2svn.py</command> (vea
<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
@@ -2237,7 +2239,7 @@
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
+ Berkeley 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
@@ -2311,14 +2313,14 @@
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
+ Y dado que puede cambiar las propiedades 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
+ <para>Hablando de manera general, sólo los realmente paranoicos
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
@@ -2395,7 +2397,7 @@
<para>Hay múltiples beneficios en el uso de un único repositorio
- para múltiples projectos, siendo el más obvio evitar duplicar el
+ para múltiples proyectos, siendo el más obvio evitar duplicar el
trabajo de mantenimiento. Tener un único repositorio significa
que sólo hay un conjunto de scripts de enganche, un elemento del
que hacer rutinariamente copias de seguridad, un único volcado y
@@ -2417,7 +2419,7 @@
<para>También puede diseñar una solución híbrida. Por ejemplo,
los proyectos pueden ser agrupados en función de las relaciones
que tengan entre ellos. Quizás tenga varios repositorios con un
- puñado de projectos en cada uno. De ese modo, los proyectos más
+ puñado de proyectos en cada uno. De ese modo, los proyectos más
propensos a compartir sus datos pueden hacerlo de manera sencilla, y
a medida que se añaden revisiones al repositorio, al menos los
desarrolladores del mismo saben que están relacionadas remotamente
@@ -2431,7 +2433,7 @@
recomienda que elija una ubicación en el repositorio para cada
<firstterm>raíz de proyecto</firstterm>— el directorio
<quote>superior</quote> que contiene todos los datos relacionados
- con el mismo—y crée tres nuevos subdirectorios en esa
+ con el mismo—y cree tres nuevos subdirectorios en esa
raíz: <filename>trunk</filename>, que sería el directorio
bajo el cual se lleva el desarrollo principal del proyecto;
<filename>branches</filename>, que sería el directorio que
@@ -2463,7 +2465,7 @@
proyecto en su repositorio. Si sólo tiene un proyecto por
repositorio, el lugar lógico para poner la raíz de cada proyecto
es en la raíz del repositorio respectivo. Si tiene múltiples
- proyectos, quizás desée organizarlos en grupos dentro del
+ proyectos, quizás desee organizarlos en grupos dentro del
repositorio, quizás ubicando proyectos con fines similares o
código compartido en el mismo subdirectorio, o quizás simplemente
prefiera agruparlos alfabéticamente. Tal esquema podría tener
@@ -2554,7 +2556,7 @@
</screen>
<para>Una vez tenga la estructura de su esquema en lugar, puede
- comenzar a importar los del projecto en su repositorio, si
+ comenzar a importar los del proyecto en su repositorio, si
es que tales datos existen. De nuevo, hay varios métodos
para hacer esto. Puede usar el comando <command>svn
import</command>. Podría obtener una copia de trabajo local
Modified: trunk/src/es/glosario_traduccion
==============================================================================
--- trunk/src/es/glosario_traduccion (original)
+++ trunk/src/es/glosario_traduccion Sun Sep 10 06:36:33 2006
@@ -77,7 +77,7 @@
usar ruta si el contexto de la frase así lo favorece, en caso
contrario probar con camino o trayectoria.
-timestamp -> marca de tiempo, fecha y hora
+timestamp, datestamp -> marca de tiempo, fecha y hora
Esa traducción viene del ORCA. No obstante en muchos casos es
más claro traducirla como "fecha de fichero" o "fecha" a secas.
Ejemplo: ...will show the modification timestamp. -> mostrará
More information about the svnbook-dev
mailing list