[svnbook commit] r1606 - trunk/src/es/book
julot
svnbook-dev at red-bean.com
Sat Aug 13 20:49:00 CDT 2005
Author: julot
Date: Sat Aug 13 20:48:58 2005
New Revision: 1606
Modified:
trunk/src/es/book/appc.xml
trunk/src/es/book/ch05.xml
Log:
Book Spanish. About finish the first section of app C
Modified: trunk/src/es/book/appc.xml
==============================================================================
--- trunk/src/es/book/appc.xml (original)
+++ trunk/src/es/book/appc.xml Sat Aug 13 20:48:58 2005
@@ -132,16 +132,20 @@
<title>Extensiones DeltaV</title>
<para>
- Because RFC 2518 left out versioning concepts, another
- capable group was left with the responsibility of writing RFC
- 3253, which adds versioning to WebDAV. WebDAV/DeltaV clients
- and servers are often called just <quote>DeltaV</quote>
- clients and servers, since DeltaV implies the existence of
- basic WebDAV.</para>
-
- <para>DeltaV introduces a whole slew of new acronyms, but don't
- be intimidated. The ideas are fairly straightforward. Here
- are the new concepts and methods introduced in DeltaV:</para>
+ Dado que el RFC 2518 dejó por fuera concetos de versionado,
+ se dejó a otro grupo la responsabilidad de escribir el RFC 3253,
+ que añade el versionado a WebDAV. Los clientes y servidores de
+ WebDAV/DeltaV a menudo son llamados sólo clientes y servidores
+ <quote>DeltaV</quote>, ya que DeltaV implica la existencia de
+ WebDAV básico.
+ </para>
+
+ <para>
+ <!--TODO:a whole slew of new acronyms-->
+ DeltaV introduce una gran cantidad de acrónimos, pero no deje que
+ eso lo intimide. Las ideas son bastante directas. Aquí están los nuevos
+ conceptos y métodos presentados en DeltaV.
+ </para>
<variablelist>
@@ -209,9 +213,23 @@
</varlistentry>
<varlistentry>
- <term>Configurations</term>
+ <term>Configuraciones</term>
<listitem>
- <para>DeltaV allows you define flexible collections of
+ <para>
+ DeltaV le permite definir colecciones flexibles de VCRs llamadas
+ <quote>configuraciones</quote>, que no necesariamente corresponden
+ a directorios particulares. El contenido de cada VCR puede hacerse
+ apuntar a un VR específico usando el método
+ <literal>UPDATE</literal>. Una vez la configuración es perfecta,
+ el cliente puede crear un <quote>snapshot</quote> de toda la
+ configuración, llamado <quote>baseline</quote>. Los clientes usan
+ los métodos <literal>CHECKOUT</literal> y
+ <literal>CHECKIN</literal> para capturar estados específicos de
+ las configuraciones, de manera muy similar a cuando usan estos
+ métodos
+ <!--TODO:la ultima frase del párrafo-->
+
+ DeltaV allows you define flexible collections of
VCRs called <quote>configurations</quote>, which don't
necessarily respond to particular directories. Each VCR's
contents can be made to point to a specific VR using the
@@ -227,31 +245,36 @@
</varlistentry>
<varlistentry>
- <term>Extensibility</term>
+ <term>Extensibilidad</term>
<listitem>
- <para>DeltaV defines a new method,
- <literal>REPORT</literal>, which allows the client and
- server to perform customized data exchanges. The client
- sends a <literal>REPORT</literal> request with a
- properly-labeled XML body full of custom data; assuming
- the server understands the specific report-type, it
- responds with an equally custom XML body. This technique
- is very similar to XML-RPC.</para>
+ <para>
+ DeltaV define un nuevo método, <literal>REPORT</literal>, que
+ permite al clienet y al servidor llevar a cabo intercambios
+ personalizados de datos. El cliente envía una solicitud
+ <literal>REPORT</literal> con un cuerpo XML adecuadamente
+ etiquetado y lleno de datos personalizados; asumiendo que el
+ servidor entiende el tipo específico del reporte, responde con un
+ cuerpo XML igualmente personalizado. Esta técnica es muy similar a
+ XML-RPC.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Autoversioning</term>
+ <term>Autoversionado</term>
<listitem>
- <para>For many, this is the <quote>killer</quote> feature
- of DeltaV. If the DeltaV server supports this feature,
- then basic WebDAV clients (i.e. those unaware of
- versioning) can still write to the server, and the server
- will silently perform versioning anyway. In the simplest
- example, an ignorant <literal>PUT</literal> from a basic
- WebDAV client might be translated by the server as a
- <literal>CHECKOUT</literal>, <literal>PUT</literal>,
- <literal>CHECKIN</literal>.</para>
+ <para>
+ Para muchos, esta es la aplicación <quote>estrella</quote> de
+ DeltaV. Si el servidor DeltaV soporta esta característica,
+ entonces los clientes WebDAV básico (por ejemplo, aquellos que no
+ son compatibles con versionado) aún pueden escribir en el
+ servidor, y el servidor silenciosamente hará el versionado.
+ <!--TODO: perform versioning anyway-->
+ En el ejemplo más simple, un <literal>PUT</literal> ignorante de
+ parte de un cliente WebDAV básico puede ser traducido por el
+ servidor como un <literal>CHECKOUT</literal>,
+ <literal>PUT</literal>, <literal>CHECKIN</literal>.
+ </para>
</listitem>
</varlistentry>
Modified: trunk/src/es/book/ch05.xml
==============================================================================
--- trunk/src/es/book/ch05.xml (original)
+++ trunk/src/es/book/ch05.xml Sat Aug 13 20:48:58 2005
@@ -67,11 +67,11 @@
<para>Hablando conceptualmente, un repositorio Subversion es
una secuencia de árboles de directorios. Cada árbol es una
- <!--TODO:snapshot=¿fotografía?-->fotografía de cómo eran
- los ficheros y directorios versionados en tu repositorio en
- un momento determinado. Estas fotografías son generadas como
- resultado de operaciones de programas cliente, y son llamadas
- revisiones.</para>
+ <!--TODO:snapshot=¿fotografía?-->fotografía de cómo eran
+ los ficheros y directorios versionados en tu repositorio en
+ un momento determinado. Estas fotografías son generadas como
+ resultado de operaciones de programas cliente, y son llamadas
+ revisiones.</para>
<para>Cada revisión nace como un árbol de transacciones. Cuando se
envían cambios al repositorio, el programa cliente construye
@@ -83,7 +83,7 @@
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,
- la transacción se destruye, y se le informa al cliente del error.</para>
+ la transacción se destruye, y se le informa al cliente del error.</para>
<para>Las actualizaciones funcionan de una manera parecida. El Cliente
prepara un árbol de transacción temporal que <!--mirrors=copia?-->copia el estado
@@ -158,7 +158,7 @@
en tu mensaje de log, puedes simplemente sustituir el valor de
la propiedad <literal>svn:log</literal> con un nuevo y corregido
mensaje de log.</para>
-
+
</sect2>
<!-- ***************************************************************** -->
@@ -173,7 +173,7 @@
su licencia open-source, soporte de transacciones, ser de confianza,
funcionamiento, simplicidad de su API, soporte de hilos, cursores,
y más.</para>
-
+
<para>La base de datos Berkely tiene un soporte real de transacciones
—probablemente es su característica más poderosa.
Muchos procesos que accede a tus repositorios Subversion
@@ -211,7 +211,7 @@
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 BD Berkeley.</para>
<para>Pero toda rosa tiene su espina, así que tenemos que
hablar sobre algunas conocidas limitaciones de la BD Berkeley.
@@ -220,7 +220,7 @@
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.
+ entorno que no lo son.
Segundo, Subversion usa BD 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
@@ -263,7 +263,7 @@
de ficheros remoto como NFS, AFS, o Windows SMB. La DB 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
+ 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
en una unidad compartida de red, los resultados son impredecibles
@@ -320,7 +320,7 @@
<term>dav</term>
<listitem>
<para>Un directorio para Apache y mod_dav_svn y su
- economía privada de datos.<!--TODO:comprobar "housekeeping"--></para>
+ economía privada de datos.<!--TODO:comprobar "housekeeping"--></para>
</listitem>
</varlistentry>
<varlistentry>
@@ -336,7 +336,7 @@
<term>format</term>
<listitem>
<para>Un fichero cuyo contenido es un simple valor entero que
- nos dice el número de versión del repositorio <!--TODO:layout--></para>
+ nos dice el número de versión del repositorio <!--TODO:layout--></para>
</listitem>
</varlistentry>
<varlistentry>
@@ -512,70 +512,70 @@
<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> )
- 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,
+ el mensaje de commit <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,
<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,
- no se permite a los clientes Subversion modificarlos
- del todo remotamente a no ser que este hook se implemente
- para su repositorio.</para>
-
- <para>Este hook 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
- 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>
+ 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,
+ no se permite a los clientes Subversion modificarlos
+ del todo remotamente a no ser que este hook se implemente
+ para su repositorio.</para>
+
+ <para>Este hook 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
+ 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>
</listitem>
</varlistentry>
<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,
- 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>
- 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:
- 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>
-
- <para>La distribución de Subversion incluye el script
- <command>propchange-email.pl</command> script
- (localizado en el directorio <filename>tools/hook-scripts/</filename>
- del árbol de fuentes de Subversion ) que puede ser usado
- para enviar un correo electrónico con ( y/o añadido a un
- fichero de log ) los detalles de un cambio en una propiedad
- de revisión. Este correo electrónico contiene la revisión
- y nombre de la propiedad modificada, el usuario que hizo el cambio,
- y el nuevo valor.</para>
+ <para>Como se ha mencionado antes, este hook es la contrapartida
+ del hook <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>
+ 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:
+ 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>
+
+ <para>La distribución de Subversion incluye el script
+ <command>propchange-email.pl</command> script
+ (localizado en el directorio <filename>tools/hook-scripts/</filename>
+ del árbol de fuentes de Subversion ) que puede ser usado
+ para enviar un correo electrónico con ( y/o añadido a un
+ fichero de log ) los detalles de un cambio en una propiedad
+ de revisión. Este correo electrónico contiene la revisión
+ y nombre de la propiedad modificada, el usuario que hizo el cambio,
+ y el nuevo valor.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Subversión tratará de ejecutar los hooks como el mismo
usuario que posee el proces 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
- 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.
- En otras palabras, esté alerta a problemas potenciales relacionados
- con permisos que impidan al hook realizar las tareas para las cuales
- lo haya escrito.</para>
+ 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
+ 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.
+ En otras palabras, esté alerta a problemas potenciales relacionados
+ con permisos que impidan al hook realizar las tareas para las cuales
+ lo haya escrito.</para>
</sect2>
More information about the svnbook-dev
mailing list