[svnbook commit] r1598 - in trunk/src/es: . book

julot svnbook-dev at red-bean.com
Wed Aug 10 17:27:22 CDT 2005


Author: julot
Date: Wed Aug 10 17:27:21 2005
New Revision: 1598

Modified:
   trunk/src/es/LEAME
   trunk/src/es/TRABAJO
   trunk/src/es/book/appc.xml
   trunk/src/es/book/ch01.xml
Log:
Book Spanish. Fixed the TAB issue with appc.xml, and translated 2 (or 
3?) paragraphs.

In ch1, fixed a tilde.

in trabajo, I added my self

in LEAME, fixed a redaction (little) issue


Modified: trunk/src/es/LEAME
==============================================================================
--- trunk/src/es/LEAME	(original)
+++ trunk/src/es/LEAME	Wed Aug 10 17:27:21 2005
@@ -217,7 +217,7 @@
 usuario. Simultáneamente, quien solicita acceso de escritura tendrá
 que mandar a los responsables (kfogel at collab.net, cmpilato at collab.net
 y sussman at collab.net) un mensaje indicando el nombre de usuario que
-tiene en tigris.org y la palabra clave desea usar para modificar
+tiene en tigris.org y la palabra clave que desea usar para modificar
 el repositorio.
 
 Cuando los responsables del repositorio hayan recibido ambos

Modified: trunk/src/es/TRABAJO
==============================================================================
--- trunk/src/es/TRABAJO	(original)
+++ trunk/src/es/TRABAJO	Wed Aug 10 17:27:21 2005
@@ -38,6 +38,7 @@
 dbrouard                Diego Brouard
 gradha                  Grzegorz Adam Hankiewicz
 ruben                   Rubén Gómez
+julot                   Javier Rojas
 
 
 Ficheros huérfanos con traducción parcial:
@@ -50,6 +51,7 @@
 ch05.xml: dbrouard
 ch06.xml: Federico Edelman
 ch09.xml: gradha
+appc.xml: julot
 appd.xml: ruben
 
 Ficheros que han completado al menos una traducción básica:

Modified: trunk/src/es/book/appc.xml
==============================================================================
--- trunk/src/es/book/appc.xml	(original)
+++ trunk/src/es/book/appc.xml	Wed Aug 10 17:27:21 2005
@@ -1,658 +1,659 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!-- originated from English revision 652 -->
 <appendix id="svn-ap-c">
-   <title>WebDAV y autoversionado</title>
+  <title>WebDAV y autoversionado</title>
+  <simplesect>
 
-   <simplesect>
+    <para>
+      WebDAV es una extensión a HTTP, y se está haciendo más y
+      más  popular como estándar para compartir archivos. Los sistemas 
+      operativos actuales se están haciendo cada vez más compatibles
+      con la web, y muchos de ellos tienen soporte interno para montar
+      directorios compartidos exportados por servidores WebDAV.
+    </para>
+
+    <para>
+      Si usted usa Apache/mod_dav_svn como su servidor de red para 
+      Subversion, entonces, hasta cierto punto, usted también está
+      usando un servidor WebDAV. Este apéndice brinda nociones básicas
+      sobre la naturaleza de este protocolo, cómo lo usa Subversion,
+      y qué tan bien interopera Subversion con otros programas compatibles
+      con WebDAV.
+    </para>
+
+  </simplesect>
+
+  <sect1 id="svn-ap-c-sect-1">
+    <title>Conceptos básicos de WebDAV</title> 
+
+    <para>
+      Esta sección da una introducción muy corta y muy general a las
+      ideas detrás de WebDAV. Debería sentar las bases para entender
+      los problemas de compatibilidad entre los clientes y servidores.
+    </para>
+
+    <sect2 id="svn-ap-c-sect-1.1">
+      <title>WebDAV sencillo</title>
 
       <para>
-         WebDAV es una extensión a HTTP, y se está haciendo más y
-			más  popular como estándar para compartir archivos. Los sistemas 
-         operativos actuales se están haciendo cada vez más compatibles
-         con la web, y muchos de ellos tienen soporte interno para montar
-         directorios compartidos exportados por servidores WebDAV.
+        El RFC 2518 define un conjunto de conceptos y métodos de 
+        extensión acompañantes a HTTP 1.1 que hacen de la web un 
+        medio de lectura/escritura más universal. La idea básica 
+        es que un servidor web compatible con WebDAV puede actuar como 
+        un servidor genérico de archivos; los clientes pueden montar 
+        directorios compartidos que se comportan de manera muy similar 
+        a los directorios compartidos de NFS o SMB.
       </para>
 
       <para>
-         Si usted usa Apache/mod_dav_svn como su servidor de red para 
-         Subversion, entonces, hasta cierto punto, usted también está
-         usando un servidor WebDAV. Este apéndice brinda nociones básicas
-         sobre la naturaleza de este protocolo, cómo lo usa Subversion,
-         y qué tan bien interopera Subversion con otros programas compatibles
-         con WebDAV.
+        Sin embargo, es importante notar que el RFC 2518 <emphasis>no</emphasis>  
+        provee ningún tipo de modelo para control de versiones, a pesar de
+        la <quote>V</quote> en DAV. Los clientes y servidores de
+        WebDAV básico asumen que sólo existe una versión de cada archivo
+        o directorio, y puede ser sobreescrita repetidamente.
+        <footnote><para>Por esta razón, algunas personas se refieren en broma
+            a los clientes genéricos de WebDAV como clientes <quote>WebDA</quote></para></footnote>
       </para>
 
-   </simplesect>
-
-   <sect1 id="svn-ap-c-sect-1">
-      <title>Conceptos básicos de WebDAV</title> 
-
       <para>
-         Esta sección da una introducción muy corta y muy general a las
-         ideas detrás de WebDAV. Debería sentar las bases para entender
-         los problemas de compatibilidad entre los clientes y servidores.
+        Aquí están los conceptos y métodos nuevos introducidos en 
+        el WebDAV básico.
       </para>
 
-      <sect2 id="svn-ap-c-sect-1.1">
-         <title>WebDAV sencillo</title>
+      <variablelist>
+
+        <varlistentry>
+          <term>Nuevos métodos de escritura</term>
+          <listitem>
+            <para>
+              Más allá del método <literal>PUT</literal> del HTTP 
+              estándar (que crea o sobreescribe un recurso web),
+              WebDAV define los nuevos métodos <literal>COPY</literal>
+              y <literal>MOVE</literal> para duplicar o reacomodar 
+              recursos.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Colecciones</term>
+          <listitem>
+            <para>
+              Este es simplemente el término usado en WebDAV para
+              el agrupamiento de recursos (URI's). En la mayoría de
+              los casos, es el análogo a un <quote>directorio</quote>.
+              Se puede decir que algo es una colección si termina con 
+              un <quote>/</quote>. De la misma manera que los archivos 
+              pueden ser creadoscon el método <literal>PUT</literal>,
+              las colecciones son creadas con el nuevo método <literal>MKCOL</literal>.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Propiedades</term>
+          <listitem>
+            <para>
+              Es la misma idea que está presente en Subversion—metadatos
+              asociados a archivos y colecciones. Un cliente puede
+              mostrar u obtener las propiedades asociadas a un recurso
+              con el nuevo método <literal>PROPFIND</literal>, y puede 
+              cambiarlas con el método <literal>PROPPATCH</literal>. Algunas 
+              propiedades son completamente creadas y controladas por los
+              usuarios (por ejemplo, una propiedad llamada <quote>color</quote>),
+              y otras creadas y administradas por el servidor WebDAV (por ejemplo,
+              la propiedad que contiene la última fecha de modificación de un 
+              archivo). Las primeras son llamadas propiedades <quote>muertas</quote>
+              y las segundas propiedades <quote>vivas</quote>.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Bloqueo</term>
+          <listitem>
+            <para>
+              Un servidor WebDAV puede decidir ofrecer una característica de 
+              bloqueo a los clientes— esta parte de la especificación es 
+              opcional, aunque muchos servidores WebDAV ofrecen esta característica.
+              Si está presente los clientes pueden usar los nuevos métodos <literal>LOCK</literal>
+              y <literal>UNLOCK</literal> para mediar el acceso a un recurso. En la 
+              mayoría de los casos estos métodos son usados para crear bloqueos 
+              de escritura exclusivos (como se discutió en <xref linkend="svn-ch-2-sect-2.2"/>),
+              aunque también es posible tener bloqueos de escritura compartidos.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
 
-         <para>
-            El RFC 2518 define un conjunto de conceptos y métodos de 
-            extensión acompañantes a HTTP 1.1 que hacen de la web un 
-            medio de lectura/escritura más universal. La idea básica 
-            es que un servidor web compatible con WebDAV puede actuar como 
-            un servidor genérico de archivos; los clientes pueden montar 
-            directorios compartidos que se comportan de manera muy similar 
-            a los directorios compartidos de NFS o SMB.
-         </para>
-
-         <para>
-            Sin embargo, es importante notar que el RFC 2518 <emphasis>no</emphasis>  
-            provee ningún tipo de modelo para control de versiones, a pesar de
-            la <quote>V</quote> en DAV. Los clientes y servidores de
-            WebDAV básico asumen que sólo existe una versión de cada archivo
-            o directorio, y puede ser sobreescrita repetidamente.
-            <footnote><para>Por esta razón, algunas personas se refieren en broma
-                  a los clientes genéricos de WebDAV como clientes <quote>WebDA</quote></para></footnote>
-         </para>
-
-         <para>
-            Aquí están los conceptos y métodos nuevos introducidos en 
-            el WebDAV básico.
-         </para>
-
-         <variablelist>
-
-            <varlistentry>
-               <term>Nuevos métodos de escritura</term>
-               <listitem>
-                  <para>
-                     Más allá del método <literal>PUT</literal> del HTTP 
-                     estándar (que crea o sobreescribe un recurso web),
-                     WebDAV define los nuevos métodos <literal>COPY</literal>
-                     y <literal>MOVE</literal> para duplicar o reacomodar 
-                     recursos.
-                  </para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Colecciones</term>
-               <listitem>
-                  <para>
-                     Este es simplemente el término usado en WebDAV para
-                     el agrupamiento de recursos (URI's). En la mayoría de
-                     los casos, es el análogo a un <quote>directorio</quote>.
-							Se puede decir que algo es una colección si termina con 
-							un <quote>/</quote>. De la misma manera que los archivos 
-							pueden ser creadoscon el método <literal>PUT</literal>,
-							las colecciones son creadas con el nuevo método <literal>MKCOL</literal>.
-						</para>
-					</listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Propiedades</term>
-               <listitem>
-						<para>
-							Es la misma idea que está presente en Subversion—metadatos
-							asociados a archivos y colecciones. Un cliente puede
-							mostrar u obtener las propiedades asociadas a un recurso
-							con el nuevo método <literal>PROPFIND</literal>, y puede 
-							cambiarlas con el método <literal>PROPPATCH</literal>. Algunas 
-							propiedades son completamente creadas y controladas por los
-							usuarios (por ejemplo, una propiedad llamada <quote>color</quote>),
-							y otras creadas y administradas por el servidor WebDAV (por ejemplo,
-							la propiedad que contiene la última fecha de modificación de un 
-							archivo). Las primeras son llamadas propiedades <quote>muertas</quote>
-							y las segundas propiedades <quote>vivas</quote>.
-						</para>
-					</listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Locking</term>
-               <listitem>
-                  <para>A WebDAV server may decide to offer a locking
-                     feature to clients—this part of the specification is
-                     optional, although most WebDAV servers do offer the
-                     feature.  If present, then clients can use the new
-                     <literal>LOCK</literal> and <literal>UNLOCK</literal>
-                     methods to mediate access to a resource.  In most cases
-                     these methods are used to create exclusive write locks (as
-                     discussed in <xref linkend="svn-ch-2-sect-2.2"/>),
-                     although shared write locks are also possible.</para>
-               </listitem>
-            </varlistentry>
-
-         </variablelist>
-
-      </sect2>
-
-      <sect2 id="svn-ap-c-sect-1.2">
-         <title>DeltaV Extensions</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>
-
-         <variablelist>
-
-            <varlistentry>
-               <term>Per-resource versioning</term>
-               <listitem>
-                  <para>
-                     Like CVS and other version-control systems, DeltaV
-                     assumes that each resource has a potentially infinite
-                     number of states.  A client begins by placing a resource
-                     under version control using the new
-                     <literal>VERSION-CONTROL</literal> method.  This creates
-                     a new Version Controlled Resource (VCR).  Every time you
-                     change the VCR (via <literal>PUT</literal>,
-                     <literal>PROPPATCH</literal>, etc.), a new state of the
-                     resource is created, called a Version Resource (VR).
-                     VCRs and VRs are still ordinary web resources, defined
-                     by URLs.  Specific VRs can have human-friendly names as
-                     well.
-                  </para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Server-side working-copy model</term>
-               <listitem>
-                  <para>Some DeltaV servers support the ability to create a
-                     virtual <quote>workspace</quote> on the server, where all
-                     of your work is performed.  Clients use the
-                     <literal>MKWORKSPACE</literal> method to create a private
-                     area, then indicate they want to change specific VCRs by
-                     <quote>checking them out</quote> into the workspace,
-                     editing them, and <quote>checking them in</quote> again.
-                     In HTTP terms, the sequence of methods would be
-                     <literal>CHECKOUT</literal>, <literal>PUT</literal>,
-                     <literal>CHECKIN</literal>.  After each
-                     <literal>CHECKIN</literal>, a new VR is created, and
-                     the edited VCR's contents now <quote>point to</quote> the
-                     latest VR.  Each VCR has also has a <quote>history</quote>
-                     resource which tracks and orders its various VR
-                     states.</para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Client-side working-copy model</term>
-               <listitem>
-                  <para>Some DeltaV servers also support the idea that the
-                     client may have a private working copy full of specific
-                     VRs.  (This is how CVS and Subversion work.)  When the
-                     client wants to commit changes to the server, it begins by
-                     creating a temporary server transaction (called an
-                     activity) with the <literal>MKACTIVITY</literal> method.
-                     The client then performs a <literal>CHECKOUT</literal> on
-                     each VR it wishes to change, which creates a number of
-                     temporary <quote>working resources</quote> in the
-                     activity, that can be modified using
-                     <literal>PUT</literal> and <literal>PROPPATCH</literal>
-                     methods.  Finally, the client performs a
-                     <literal>CHECKIN</literal> on each working resource, which
-                     creates a new VR within each VCR, and the entire activity
-                     is deleted.</para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Configurations</term>
-               <listitem>
-                  <para>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
-                     <literal>UPDATE</literal> method.  Once the configuration
-                     is perfect, the client can create a
-                     <quote>snapshot</quote> of the whole configuration, called
-                     a <quote>baseline</quote>.  Clients use the
-                     <literal>CHECKOUT</literal> and <literal>CHECKIN</literal>
-                     methods to capture specific states of configurations, much
-                     like they use these methods to create specific VR states
-                     of VCRs.</para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Extensibility</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>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>Autoversioning</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>
-               </listitem>
-            </varlistentry>
-
-         </variablelist>
-
-      </sect2>
-
-   </sect1>
-
-   <sect1 id="svn-ap-c-sect-2">
-      <title>Subversion and DeltaV</title> 
-
-      <para>So how <quote>compatible</quote> is Subversion with other
-         DeltaV software?  In two words: not very.  At least not yet, not
-         in Subversion 1.0.</para>
-
-      <para>While libsvn_ra_dav sends DeltaV requests to the server, the
-         Subversion client is <emphasis>not</emphasis> a general-purpose
-         DeltaV client.  In fact, it expects some custom features from
-         the server (especially through custom <literal>REPORT</literal>
-         requests).  Further, mod_dav_svn is <emphasis>not</emphasis> a
-         general-purpose DeltaV server.  It only implements a strict
-         subset of the DeltaV specification.  A more general WebDAV or
-         DeltaV client may very well be able to interoperate against it,
-         but only if that client operates within the narrow confines of
-         those features that the server has implemented.  The Subversion
-         development team plans to address general WebDAV
-         interoperability in a future release of Subversion.</para>
-
-      <sect2 id="svn-ap-c-sect-2.1">
-         <title>Mapping Subversion to DeltaV</title>
-
-         <para>Here is a very <quote>high-level</quote> description of
-            how various Subversion client operations use DeltaV.  In many
-            cases, these explanations are gross oversimplifications.  They
-            should <emphasis>not</emphasis> be taken as a substitute for
-            reading Subversion's source code or talking with its
-            developers.</para>
-
-         <variablelist>
-
-            <varlistentry>
-               <term>svn checkout/list</term>
-               <listitem>
-                  <para>
-                     Perform a <literal>PROPFIND</literal> of depth 1 on the
-                     collection to get a list of immediate children.  Perform
-                     a <literal>GET</literal> (and possibly a
-                     <literal>PROPFIND</literal>) on each child.  Recurse
-                     into collections and repeat.
-                  </para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>svn commit</term>
-               <listitem>
-                  <para>
-                     Create an activity with <literal>MKACTIVITY</literal>,
-                     and do a <literal>CHECKOUT</literal> of each changed
-                     item, followed by a <literal>PUT</literal> of new data.
-                     Finally, a <literal>MERGE</literal> request causes an
-                     implicit <literal>CHECKIN</literal> of all working
-                     resources.
-                  </para>
-               </listitem>
-            </varlistentry>
-
-            <varlistentry>
-               <term>svn update/switch/status/merge/diff</term>
-               <listitem>
-                  <para>
-                     Send a custom <literal>REPORT</literal> request that
-                     describes the mixed-revision (and mixed-url) state of
-                     the working copy.  The server sends a custom response
-                     that describes which items need updating.  The client
-                     loops over the response, performing
-                     <literal>GET</literal> and <literal>PROPFIND</literal>
-                     requests as needed.  For updates and switches, install
-                     the new data in the working copy.  For diff and merge
-                     commands, compare the data to the working copy, possibly
-                     applying changes as local modifications.
-                  </para>
-               </listitem>
-            </varlistentry>
-
-         </variablelist>
-
-      </sect2>
-
-      <sect2 id="svn-ap-c-sect-2.2">
-         <title>Autoversioning Support</title>
-
-         <para>At the time of writing, the truth is that there are very
-            few DeltaV clients in the world; RFC 3253 is still relatively
-            new.  However users do have access to <quote>generic</quote>
-            clients, because almost every modern operating system now has
-            an integrated basic WebDAV client.  With this in mind,
-            Subversion developers realized that if Subversion 1.0 was to
-            have <emphasis>any</emphasis> interoperability features,
-            support for DeltaV autoversioning would be the best
-            approach.</para>
-
-         <para>To activate autoversioning in mod_dav_svn, use the
-            <literal>SVNAutoversioning</literal> directive within the
-            <filename>httpd.conf</filename> <literal>Location</literal>
-            block, like so:</para>
-
-         <screen>
-            <Location /repos>
-            DAV svn
-            SVNPath /absolute/path/to/repository
-            SVNAutoversioning on
-            </Location>
-         </screen>
-
-         <para>Normally, if a generic WebDAV client attempted a
-            <literal>PUT</literal> to a path within your repository
-            location, mod_dav_svn would outright reject the request.  (It
-            normally only allows such operations on <quote>working
-               resources</quote> within DeltaV <quote>activities</quote>.)
-            With <literal>SVNAutoversioning</literal> turned on, however,
-            the server interprets the <literal>PUT</literal> request as an
-            internal <literal>MKACTIVITY</literal>,
-            <literal>CHECKOUT</literal>, <literal>PUT</literal>, and
-            <literal>CHECKIN</literal>.  A generic log message is
-            auto-generated, and a new filesystem revision is
-            created.</para>
-
-         <para>Because so many operating systems already have integrated
-            WebDAV abilities, the use-case for this feature borders on
-            fantastical: imagine an office of ordinary users running
-            Microsoft Windows or Mac OS.  Each computer
-            <quote>mounts</quote> the Subversion repository, which appears
-            to be an ordinary network share.  They use the server as they
-            always do:  open files from the server, edit them, and
-            save them back to the server.  But in this fantasy, the server
-            is automatically versioning everything.  Later on, a sysadmin
-            can use a Subversion client to search and retrieve all older
-            versions.</para>
-
-         <para>Is this fantasy real?  Not quite.  The main snag is that
-            Subversion 1.0 has no support whatsoever for the WebDAV
-            <literal>LOCK</literal> or <literal>UNLOCK</literal> methods.
-            Most operating system DAV clients attempt to
-            <literal>LOCK</literal> a resource opened directly from a
-            DAV-mounted network share.  For now, users may have to copy a
-            file from the DAV share to local disk, edit the file, then
-            copy it back again.  Not ideal autoversioning, but still
-            doable.</para>
-
-      </sect2>
-
-      <sect2 id="svn-ap-c-sect-2.3">
-         <title>The mod_dav_lock Alternative</title>
-
-         <para>The mod_dav Apache module is a complex beast:  it
-            understands and parses all of the WebDAV and DeltaV methods,
-            yet it depends on a back-end <quote>provider</quote> to
-            access the resources themselves.</para>
-
-         <para>In its simplest incarnation, a user can use mod_dav_fs as
-            a provider for mod_dav.  mod_dav_fs uses the ordinary
-            filesystem to store files and directories, and only
-            understands vanilla WebDAV methods, not DeltaV.</para>
-
-         <para>Subversion, on the other hand, uses mod_dav_svn as a
-            provider for mod_dav.  mod_dav_svn understands all WebDAV
-            methods except <literal>LOCK</literal>, and understands a
-            sizable subset of DeltaV methods.  It accesses data in the
-            Subversion repository, rather than in the real filesystem.
-            Subversion 1.0 doesn't support locking, because it would
-            actually be quite difficult to implement, since Subversion uses
-            the copy-modify-merge model.<footnote><para>Subversion may
-                  someday develop a reserved-checkout locking model that can
-                  live peaceably with copy-modify-merge, but it probably won't
-                  happen soon.</para></footnote></para>
-
-         <para>In Apache httpd-2.0, mod_dav supports the
-            <literal>LOCK</literal> method by tracking locks in a private
-            database, assuming that the provider is willing to accept
-            them.  In Apache httpd-2.1 or later, however, this locking
-            support has been broken into an independent module,
-            mod_dav_lock.  It allows any mod_dav provider to take
-            advantage of the lock database, including mod_dav_svn, even
-            though mod_dav_svn doesn't actually understand locking.</para>
-
-         <para>Confused yet?</para>
-
-         <para>In a nutshell, you can use mod_dav_lock in Apache
-            httpd-2.1 (or later) to create the
-            <emphasis>illusion</emphasis> that mod_dav_svn is honoring
-            <literal>LOCK</literal> requests.  Make sure mod_dav_lock is
-            either compiled into httpd, or being loaded in your
-            <filename>httpd.conf</filename>.  Then simply add the
-            <literal>DAVGenericLockDB</literal> directive to your
-            <literal>Location</literal> like so:</para>
-
-         <screen>
-            <Location /repos>
-            DAV svn
-            SVNPath /absolute/path/to/repository
-            SVNAutoversioning on
-            DavGenericLockDB /path/to/store/locks
-            </Location>
-         </screen>
-
-         <para>This technique is a risky business; in some sense, the
-            mod_dav_svn is now lying to the WebDAV client.  It claims to
-            accept the <literal>LOCK</literal> request, but in reality the
-            lock isn't being enforced at all levels.  If a second WebDAV
-            client attempts to <literal>LOCK</literal> the same resource,
-            then mod_dav_lock will notice and correctly deny the request.
-            But there's absolutely nothing preventing an ordinary
-            Subversion client from changing the file via a normal
-            <command>svn commit</command>!  If you use this technique,
-            you're giving users the opportunity to stomp on each others'
-            changes.  In particular, a WebDAV client might accidentally
-            overwrite a change committed by regular svn client.</para>
-
-         <para>On the other hand, if you set up your environment very
-            carefully, you may mitigate the risk.  For example, if
-            <emphasis>all</emphasis> of your users are working though
-            basic WebDAV clients (rather than svn clients), then things
-            should be fine.</para>
-
-      </sect2>
-
-   </sect1>
-
-   <sect1 id="svn-ap-c-sect-3">
-      <title>Autoversioning Interoperability</title> 
-
-      <para>In this section, we'll describe the most common generic
-         WebDAV clients (at the time of writing), and how well they
-         operate against a mod_dav_svn server using the
-         <literal>SVNAutoversioning</literal> directive.  RFC 2518 is a
-         bit large, and perhaps a bit too flexible.  Every WebDAV
-         client behaves slightly differently, and creates slightly
-         different problems.</para>
-
-      <!-- list of subsections goes here. -->
-
-      <sect2 id="svn-ap-c-sect-3.1">
-         <title>Win32 WebFolders</title>
-
-         <para>Windows 98, 2000, and XP have an integrated WebDAV client
-            known as <quote>WebFolders</quote>.  On Windows 98, the
-            feature might need to be explicitly installed;  if present, a
-            <quote>WebFolders</quote> directory appears directly within My
-            Computer.  On Windows 2000 and XP, simply open My Network
-            Places, and run the Add Network Place icon.  When prompted,
-            enter the WebDAV URL.  The shared folder will appear within My
-            Network Places.</para>
-
-         <para>Most write operations work fine against an autoversioning
-            mod_dav_svn server, but there are a few problems:</para>
-
-         <itemizedlist>
-
-            <listitem>
-               <para>If a Windows XP computer is a member of an NT Domain,
-                  then it seems to be unable to connect to the WebDAV share.
-                  It repeatedly asks for a name and password, even when the
-                  Apache server isn't issuing an authentication challenge!
-                  If the machine isn't part of an NT Domain, then the share
-                  is mounted without a problem.</para>
-
-               <para>This problem seems to stem from changes in the way
-                  Windows XP creates WebFolder shortcuts (
-                  <filename>.lnk</filename> files).  It sometimes replaces
-                  the URL of the WebDAV share with a Windows
-                  <quote>UNC</quote> (Universal Naming Convention) path
-                  instead.  This causes Explorer to attempt a connection
-                  using SMB instead of HTTP.</para>
-
-               <para>A workaround for this problem is to create the
-                  <filename>.lnk</filename> shortcut on a Windows 2000
-                  computer and then copy this shortcut to the Windows XP
-                  computer.  It would probably also be possible to
-                  <quote>fix</quote> the shortcut using a HEX editor, if
-                  one were to reverse-engineer the <filename>.lnk</filename>
-                  file format.</para>
-            </listitem>
-
-            <listitem>
-               <para>A file can't be opened for direct editing from the
-                  share; it always comes up read-only.  The mod_dav_lock
-                  technique doesn't help, because WebFolders doesn't use the
-                  <literal>LOCK</literal> method at all.  The previously
-                  mentioned <quote>copy, edit, re-copy</quote> method does
-                  work, however.  The file on the share can be successfully
-                  overwritten by a locally edited copy.</para>
-            </listitem>
-
-         </itemizedlist>
-
-      </sect2>
-
-      <sect2 id="svn-ap-c-sect-3.2">
-         <title>Mac OS X</title>
-
-         <para>Apple's OS X operating system has an integrated WebDAV
-            client.  From the Finder, select the <quote>Connect to
-               Server</quote> item from the Go menu.  Enter a WebDAV URL,
-            and it appears as a disk on the desktop, just like any file
-            server.<footnote><para>Unix users can also run <command>mount
-                     -t webdav URL /mountpoint</command>.</para></footnote></para>
-
-         <para>Unfortunately, this client refuses to work against an
-            autoversioning mod_dav_svn because of its lack of
-            <literal>LOCK</literal> support.  Mac OS X discovers the
-            missing <literal>LOCK</literal> ability during the initial
-            HTTP <literal>OPTIONS</literal> feature exchange, and thus
-            decides to mount the Subversion repository as a read-only
-            share.  After that, no write operations are possible at all.
-            In order to mount the repository as a read-write share, you
-            <emphasis>must</emphasis> use the mod_dav_lock trick discussed
-            previously.  Once locking seems to work, the share behaves
-            very nicely: files can be opened directly in read/write mode,
-            although each save operation will cause the client to do a
-            <literal>PUT</literal> to a temporary location, a
-            <literal>DELETE</literal> of original file, and a
-            <literal>MOVE</literal> of the temporary resource to the
-            original filename.  That's three new Subversion revisions per
-            save!</para>
-
-         <para>One more word of warning: OS X's WebDAV client can be
-            overly sensitive to HTTP redirects.  If you're unable to mount
-            the repository at all, you may need to enable the
-            <literal>BrowserMatch</literal> directive in your
-            <filename>httpd.conf</filename>:</para>
-
-         <screen>
-            BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully
-         </screen>
-
-      </sect2>
-
-      <sect2 id="svn-ap-c-sect-3.3">
-         <title>Unix: Nautilus 2</title>
-
-         <para>Nautilus is the official file manager/browser for the
-            GNOME desktop.  Its main home page is at <systemitem
-               class="url">http://www.gnome.org/projects/nautilus/</systemitem>.
-            By simply typing a WebDAV URL into the Nautilus window,
-            the DAV share appears like a local filesystem.</para>
-
-         <para>In general, Nautilus 2 works reasonably well against an
-            autoversioning mod_dav_svn, with the following caveats:</para>
-
-         <itemizedlist>
-
-            <listitem>
-               <para>Any files opened directly from the share are treated
-                  as read-only.  Even the mod_dav_lock trick seems to have
-                  no effect.  It seems that Nautilus never issues the
-                  <literal>LOCK</literal> method at all.  The <quote>copy
-                     locally, edit, copy back</quote> trick does work, however.
-                  Unfortunately, Nautilus overwrites the old file by issuing
-                  a <literal>DELETE</literal> first, which creates an extra
-                  revision.</para>
-            </listitem>
-
-            <listitem>
-               <para>When overwriting or creating a file , Nautilus first
-                  does a <literal>PUT</literal> of an empty file, then
-                  overwrites it with a second <literal>PUT</literal>.  This
-                  creates two Subversion filesystem revisions, rather than
-                  one.</para>
-            </listitem>
-
-            <listitem>
-               <para>When deleting a collection, it issues an HTTP
-                  <literal>DELETE</literal> on each individual child instead
-                  of on the collection itself.  This creates a whole bunch of
-                  new revisions.</para>
-            </listitem>
-
-         </itemizedlist>
-
-      </sect2>
-
-      <sect2 id="svn-ap-c-sect-3.4">
-         <title>Linux davfs2</title>
-
-         <para>Linux davfs2 is a filesystem module for the Linux kernel,
-            whose development is located at <systemitem
-               class="url">http://dav.sourceforge.net/</systemitem>.  Once
-            installed, a WebDAV network share can be mounted with the
-            usual Linux <command>mount</command> command.</para>
-
-         <para>The word on the street is that this DAV client doesn't
-            work at all with mod_dav_svn's autoversioning.  Every single
-            attempt to write to the server is preceded by a
-            <literal>LOCK</literal> request, which mod_dav_svn doesn't
-            support.  At this time, there is no data indicating whether
-            the use of mod_dav_lock resolves this problem.</para>
+    </sect2>
+
+    <sect2 id="svn-ap-c-sect-1.2">
+      <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>
+
+      <variablelist>
+
+        <varlistentry>
+          <term>Versionado por recurso</term>
+          <listitem>
+            <para>
+              Como CVS y otros sistemas de control de versiones, DeltaV
+              asume que cada recurso tiene un número de estados potencialmente
+              infinito. Un cliente empieza poniendo un recurso bajo control de 
+              versiones usando el nuevo método <literal>VERSION-CONTROL</literal>.
+              Éste crea un nuevo recurso de versión controlada (VCR, por sus siglas en inglés).
+              Cada vez que usted cambia el VCR (vía <literal>PUT</literal>,<literal>PROPPATCH</literal>,
+              etc.), un nuevo estado del recurso es creado, llamado recurso de versión (VR por sus 
+              siglas en inglés). Los VRs y VCRs son recursos web ordinarios, 
+              definidos por URLs. Los VRs específicos también pueden tener nombres
+              amables con el usuario.
+              <!--TODO:human-friendly. no me termina de gustar lo de amable (o amigable) con el usuario
+              otra cosa es la traducción del "as well", que puse como también
+              -->
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Server-side working-copy model</term>
+          <listitem>
+            <para>Some DeltaV servers support the ability to create a
+              virtual <quote>workspace</quote> on the server, where all
+              of your work is performed.  Clients use the
+              <literal>MKWORKSPACE</literal> method to create a private
+              area, then indicate they want to change specific VCRs by
+              <quote>checking them out</quote> into the workspace,
+              editing them, and <quote>checking them in</quote> again.
+              In HTTP terms, the sequence of methods would be
+              <literal>CHECKOUT</literal>, <literal>PUT</literal>,
+              <literal>CHECKIN</literal>.  After each
+              <literal>CHECKIN</literal>, a new VR is created, and
+              the edited VCR's contents now <quote>point to</quote> the
+              latest VR.  Each VCR has also has a <quote>history</quote>
+              resource which tracks and orders its various VR
+              states.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Client-side working-copy model</term>
+          <listitem>
+            <para>Some DeltaV servers also support the idea that the
+              client may have a private working copy full of specific
+              VRs.  (This is how CVS and Subversion work.)  When the
+              client wants to commit changes to the server, it begins by
+              creating a temporary server transaction (called an
+              activity) with the <literal>MKACTIVITY</literal> method.
+              The client then performs a <literal>CHECKOUT</literal> on
+              each VR it wishes to change, which creates a number of
+              temporary <quote>working resources</quote> in the
+              activity, that can be modified using
+              <literal>PUT</literal> and <literal>PROPPATCH</literal>
+              methods.  Finally, the client performs a
+              <literal>CHECKIN</literal> on each working resource, which
+              creates a new VR within each VCR, and the entire activity
+              is deleted.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Configurations</term>
+          <listitem>
+            <para>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
+              <literal>UPDATE</literal> method.  Once the configuration
+              is perfect, the client can create a
+              <quote>snapshot</quote> of the whole configuration, called
+              a <quote>baseline</quote>.  Clients use the
+              <literal>CHECKOUT</literal> and <literal>CHECKIN</literal>
+              methods to capture specific states of configurations, much
+              like they use these methods to create specific VR states
+              of VCRs.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Extensibility</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>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>Autoversioning</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>
+          </listitem>
+        </varlistentry>
+
+      </variablelist>
+
+    </sect2>
+
+  </sect1>
+
+  <sect1 id="svn-ap-c-sect-2">
+    <title>Subversion and DeltaV</title> 
+
+    <para>So how <quote>compatible</quote> is Subversion with other
+      DeltaV software?  In two words: not very.  At least not yet, not
+      in Subversion 1.0.</para>
+
+    <para>While libsvn_ra_dav sends DeltaV requests to the server, the
+      Subversion client is <emphasis>not</emphasis> a general-purpose
+      DeltaV client.  In fact, it expects some custom features from
+      the server (especially through custom <literal>REPORT</literal>
+      requests).  Further, mod_dav_svn is <emphasis>not</emphasis> a
+      general-purpose DeltaV server.  It only implements a strict
+      subset of the DeltaV specification.  A more general WebDAV or
+      DeltaV client may very well be able to interoperate against it,
+      but only if that client operates within the narrow confines of
+      those features that the server has implemented.  The Subversion
+      development team plans to address general WebDAV
+      interoperability in a future release of Subversion.</para>
+
+    <sect2 id="svn-ap-c-sect-2.1">
+      <title>Mapping Subversion to DeltaV</title>
+
+      <para>Here is a very <quote>high-level</quote> description of
+        how various Subversion client operations use DeltaV.  In many
+        cases, these explanations are gross oversimplifications.  They
+        should <emphasis>not</emphasis> be taken as a substitute for
+        reading Subversion's source code or talking with its
+        developers.</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term>svn checkout/list</term>
+          <listitem>
+            <para>
+              Perform a <literal>PROPFIND</literal> of depth 1 on the
+              collection to get a list of immediate children.  Perform
+              a <literal>GET</literal> (and possibly a
+              <literal>PROPFIND</literal>) on each child.  Recurse
+              into collections and repeat.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>svn commit</term>
+          <listitem>
+            <para>
+              Create an activity with <literal>MKACTIVITY</literal>,
+              and do a <literal>CHECKOUT</literal> of each changed
+              item, followed by a <literal>PUT</literal> of new data.
+              Finally, a <literal>MERGE</literal> request causes an
+              implicit <literal>CHECKIN</literal> of all working
+              resources.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>svn update/switch/status/merge/diff</term>
+          <listitem>
+            <para>
+              Send a custom <literal>REPORT</literal> request that
+              describes the mixed-revision (and mixed-url) state of
+              the working copy.  The server sends a custom response
+              that describes which items need updating.  The client
+              loops over the response, performing
+              <literal>GET</literal> and <literal>PROPFIND</literal>
+              requests as needed.  For updates and switches, install
+              the new data in the working copy.  For diff and merge
+              commands, compare the data to the working copy, possibly
+              applying changes as local modifications.
+            </para>
+          </listitem>
+        </varlistentry>
+
+      </variablelist>
+
+    </sect2>
+
+    <sect2 id="svn-ap-c-sect-2.2">
+      <title>Autoversioning Support</title>
+
+      <para>At the time of writing, the truth is that there are very
+        few DeltaV clients in the world; RFC 3253 is still relatively
+        new.  However users do have access to <quote>generic</quote>
+        clients, because almost every modern operating system now has
+        an integrated basic WebDAV client.  With this in mind,
+        Subversion developers realized that if Subversion 1.0 was to
+        have <emphasis>any</emphasis> interoperability features,
+        support for DeltaV autoversioning would be the best
+        approach.</para>
+
+      <para>To activate autoversioning in mod_dav_svn, use the
+        <literal>SVNAutoversioning</literal> directive within the
+        <filename>httpd.conf</filename> <literal>Location</literal>
+        block, like so:</para>
+
+      <screen>
+        <Location /repos>
+        DAV svn
+        SVNPath /absolute/path/to/repository
+        SVNAutoversioning on
+        </Location>
+      </screen>
+
+      <para>Normally, if a generic WebDAV client attempted a
+        <literal>PUT</literal> to a path within your repository
+        location, mod_dav_svn would outright reject the request.  (It
+        normally only allows such operations on <quote>working
+          resources</quote> within DeltaV <quote>activities</quote>.)
+        With <literal>SVNAutoversioning</literal> turned on, however,
+        the server interprets the <literal>PUT</literal> request as an
+        internal <literal>MKACTIVITY</literal>,
+        <literal>CHECKOUT</literal>, <literal>PUT</literal>, and
+        <literal>CHECKIN</literal>.  A generic log message is
+        auto-generated, and a new filesystem revision is
+        created.</para>
+
+      <para>Because so many operating systems already have integrated
+        WebDAV abilities, the use-case for this feature borders on
+        fantastical: imagine an office of ordinary users running
+        Microsoft Windows or Mac OS.  Each computer
+        <quote>mounts</quote> the Subversion repository, which appears
+        to be an ordinary network share.  They use the server as they
+        always do:  open files from the server, edit them, and
+        save them back to the server.  But in this fantasy, the server
+        is automatically versioning everything.  Later on, a sysadmin
+        can use a Subversion client to search and retrieve all older
+        versions.</para>
+
+      <para>Is this fantasy real?  Not quite.  The main snag is that
+        Subversion 1.0 has no support whatsoever for the WebDAV
+        <literal>LOCK</literal> or <literal>UNLOCK</literal> methods.
+        Most operating system DAV clients attempt to
+        <literal>LOCK</literal> a resource opened directly from a
+        DAV-mounted network share.  For now, users may have to copy a
+        file from the DAV share to local disk, edit the file, then
+        copy it back again.  Not ideal autoversioning, but still
+        doable.</para>
+
+    </sect2>
+
+    <sect2 id="svn-ap-c-sect-2.3">
+      <title>The mod_dav_lock Alternative</title>
+
+      <para>The mod_dav Apache module is a complex beast:  it
+        understands and parses all of the WebDAV and DeltaV methods,
+        yet it depends on a back-end <quote>provider</quote> to
+        access the resources themselves.</para>
+
+      <para>In its simplest incarnation, a user can use mod_dav_fs as
+        a provider for mod_dav.  mod_dav_fs uses the ordinary
+        filesystem to store files and directories, and only
+        understands vanilla WebDAV methods, not DeltaV.</para>
+
+      <para>Subversion, on the other hand, uses mod_dav_svn as a
+        provider for mod_dav.  mod_dav_svn understands all WebDAV
+        methods except <literal>LOCK</literal>, and understands a
+        sizable subset of DeltaV methods.  It accesses data in the
+        Subversion repository, rather than in the real filesystem.
+        Subversion 1.0 doesn't support locking, because it would
+        actually be quite difficult to implement, since Subversion uses
+        the copy-modify-merge model.<footnote><para>Subversion may
+            someday develop a reserved-checkout locking model that can
+            live peaceably with copy-modify-merge, but it probably won't
+            happen soon.</para></footnote></para>
+
+      <para>In Apache httpd-2.0, mod_dav supports the
+        <literal>LOCK</literal> method by tracking locks in a private
+        database, assuming that the provider is willing to accept
+        them.  In Apache httpd-2.1 or later, however, this locking
+        support has been broken into an independent module,
+        mod_dav_lock.  It allows any mod_dav provider to take
+        advantage of the lock database, including mod_dav_svn, even
+        though mod_dav_svn doesn't actually understand locking.</para>
+
+      <para>Confused yet?</para>
+
+      <para>In a nutshell, you can use mod_dav_lock in Apache
+        httpd-2.1 (or later) to create the
+        <emphasis>illusion</emphasis> that mod_dav_svn is honoring
+        <literal>LOCK</literal> requests.  Make sure mod_dav_lock is
+        either compiled into httpd, or being loaded in your
+        <filename>httpd.conf</filename>.  Then simply add the
+        <literal>DAVGenericLockDB</literal> directive to your
+        <literal>Location</literal> like so:</para>
+
+      <screen>
+        <Location /repos>
+        DAV svn
+        SVNPath /absolute/path/to/repository
+        SVNAutoversioning on
+        DavGenericLockDB /path/to/store/locks
+        </Location>
+      </screen>
+
+      <para>This technique is a risky business; in some sense, the
+        mod_dav_svn is now lying to the WebDAV client.  It claims to
+        accept the <literal>LOCK</literal> request, but in reality the
+        lock isn't being enforced at all levels.  If a second WebDAV
+        client attempts to <literal>LOCK</literal> the same resource,
+        then mod_dav_lock will notice and correctly deny the request.
+        But there's absolutely nothing preventing an ordinary
+        Subversion client from changing the file via a normal
+        <command>svn commit</command>!  If you use this technique,
+        you're giving users the opportunity to stomp on each others'
+        changes.  In particular, a WebDAV client might accidentally
+        overwrite a change committed by regular svn client.</para>
+
+      <para>On the other hand, if you set up your environment very
+        carefully, you may mitigate the risk.  For example, if
+        <emphasis>all</emphasis> of your users are working though
+        basic WebDAV clients (rather than svn clients), then things
+        should be fine.</para>
+
+    </sect2>
+
+  </sect1>
+
+  <sect1 id="svn-ap-c-sect-3">
+    <title>Autoversioning Interoperability</title> 
+
+    <para>In this section, we'll describe the most common generic
+      WebDAV clients (at the time of writing), and how well they
+      operate against a mod_dav_svn server using the
+      <literal>SVNAutoversioning</literal> directive.  RFC 2518 is a
+      bit large, and perhaps a bit too flexible.  Every WebDAV
+      client behaves slightly differently, and creates slightly
+      different problems.</para>
+
+    <!-- list of subsections goes here. -->
+
+    <sect2 id="svn-ap-c-sect-3.1">
+      <title>Win32 WebFolders</title>
+
+      <para>Windows 98, 2000, and XP have an integrated WebDAV client
+        known as <quote>WebFolders</quote>.  On Windows 98, the
+        feature might need to be explicitly installed;  if present, a
+        <quote>WebFolders</quote> directory appears directly within My
+        Computer.  On Windows 2000 and XP, simply open My Network
+        Places, and run the Add Network Place icon.  When prompted,
+        enter the WebDAV URL.  The shared folder will appear within My
+        Network Places.</para>
+
+      <para>Most write operations work fine against an autoversioning
+        mod_dav_svn server, but there are a few problems:</para>
+
+      <itemizedlist>
+
+        <listitem>
+          <para>If a Windows XP computer is a member of an NT Domain,
+            then it seems to be unable to connect to the WebDAV share.
+            It repeatedly asks for a name and password, even when the
+            Apache server isn't issuing an authentication challenge!
+            If the machine isn't part of an NT Domain, then the share
+            is mounted without a problem.</para>
+
+          <para>This problem seems to stem from changes in the way
+            Windows XP creates WebFolder shortcuts (
+            <filename>.lnk</filename> files).  It sometimes replaces
+            the URL of the WebDAV share with a Windows
+            <quote>UNC</quote> (Universal Naming Convention) path
+            instead.  This causes Explorer to attempt a connection
+            using SMB instead of HTTP.</para>
+
+          <para>A workaround for this problem is to create the
+            <filename>.lnk</filename> shortcut on a Windows 2000
+            computer and then copy this shortcut to the Windows XP
+            computer.  It would probably also be possible to
+            <quote>fix</quote> the shortcut using a HEX editor, if
+            one were to reverse-engineer the <filename>.lnk</filename>
+            file format.</para>
+        </listitem>
+
+        <listitem>
+          <para>A file can't be opened for direct editing from the
+            share; it always comes up read-only.  The mod_dav_lock
+            technique doesn't help, because WebFolders doesn't use the
+            <literal>LOCK</literal> method at all.  The previously
+            mentioned <quote>copy, edit, re-copy</quote> method does
+            work, however.  The file on the share can be successfully
+            overwritten by a locally edited copy.</para>
+        </listitem>
+
+      </itemizedlist>
+
+    </sect2>
+
+    <sect2 id="svn-ap-c-sect-3.2">
+      <title>Mac OS X</title>
+
+      <para>Apple's OS X operating system has an integrated WebDAV
+        client.  From the Finder, select the <quote>Connect to
+          Server</quote> item from the Go menu.  Enter a WebDAV URL,
+        and it appears as a disk on the desktop, just like any file
+        server.<footnote><para>Unix users can also run <command>mount
+              -t webdav URL /mountpoint</command>.</para></footnote></para>
+
+      <para>Unfortunately, this client refuses to work against an
+        autoversioning mod_dav_svn because of its lack of
+        <literal>LOCK</literal> support.  Mac OS X discovers the
+        missing <literal>LOCK</literal> ability during the initial
+        HTTP <literal>OPTIONS</literal> feature exchange, and thus
+        decides to mount the Subversion repository as a read-only
+        share.  After that, no write operations are possible at all.
+        In order to mount the repository as a read-write share, you
+        <emphasis>must</emphasis> use the mod_dav_lock trick discussed
+        previously.  Once locking seems to work, the share behaves
+        very nicely: files can be opened directly in read/write mode,
+        although each save operation will cause the client to do a
+        <literal>PUT</literal> to a temporary location, a
+        <literal>DELETE</literal> of original file, and a
+        <literal>MOVE</literal> of the temporary resource to the
+        original filename.  That's three new Subversion revisions per
+        save!</para>
+
+      <para>One more word of warning: OS X's WebDAV client can be
+        overly sensitive to HTTP redirects.  If you're unable to mount
+        the repository at all, you may need to enable the
+        <literal>BrowserMatch</literal> directive in your
+        <filename>httpd.conf</filename>:</para>
+
+      <screen>
+        BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully
+      </screen>
+
+    </sect2>
+
+    <sect2 id="svn-ap-c-sect-3.3">
+      <title>Unix: Nautilus 2</title>
+
+      <para>Nautilus is the official file manager/browser for the
+        GNOME desktop.  Its main home page is at <systemitem
+          class="url">http://www.gnome.org/projects/nautilus/</systemitem>.
+        By simply typing a WebDAV URL into the Nautilus window,
+        the DAV share appears like a local filesystem.</para>
+
+      <para>In general, Nautilus 2 works reasonably well against an
+        autoversioning mod_dav_svn, with the following caveats:</para>
+
+      <itemizedlist>
+
+        <listitem>
+          <para>Any files opened directly from the share are treated
+            as read-only.  Even the mod_dav_lock trick seems to have
+            no effect.  It seems that Nautilus never issues the
+            <literal>LOCK</literal> method at all.  The <quote>copy
+              locally, edit, copy back</quote> trick does work, however.
+            Unfortunately, Nautilus overwrites the old file by issuing
+            a <literal>DELETE</literal> first, which creates an extra
+            revision.</para>
+        </listitem>
+
+        <listitem>
+          <para>When overwriting or creating a file , Nautilus first
+            does a <literal>PUT</literal> of an empty file, then
+            overwrites it with a second <literal>PUT</literal>.  This
+            creates two Subversion filesystem revisions, rather than
+            one.</para>
+        </listitem>
+
+        <listitem>
+          <para>When deleting a collection, it issues an HTTP
+            <literal>DELETE</literal> on each individual child instead
+            of on the collection itself.  This creates a whole bunch of
+            new revisions.</para>
+        </listitem>
+
+      </itemizedlist>
+
+    </sect2>
+
+    <sect2 id="svn-ap-c-sect-3.4">
+      <title>Linux davfs2</title>
+
+      <para>Linux davfs2 is a filesystem module for the Linux kernel,
+        whose development is located at <systemitem
+          class="url">http://dav.sourceforge.net/</systemitem>.  Once
+        installed, a WebDAV network share can be mounted with the
+        usual Linux <command>mount</command> command.</para>
+
+      <para>The word on the street is that this DAV client doesn't
+        work at all with mod_dav_svn's autoversioning.  Every single
+        attempt to write to the server is preceded by a
+        <literal>LOCK</literal> request, which mod_dav_svn doesn't
+        support.  At this time, there is no data indicating whether
+        the use of mod_dav_lock resolves this problem.</para>
 
-      </sect2>
+    </sect2>
 
-   </sect1>
+  </sect1>
 
 </appendix>
 

Modified: trunk/src/es/book/ch01.xml
==============================================================================
--- trunk/src/es/book/ch01.xml	(original)
+++ trunk/src/es/book/ch01.xml	Wed Aug 10 17:27:21 2005
@@ -6,7 +6,7 @@
 
   <simplesect>
     <para> El control de versiones es el arte del manejo de los cambios
-      en la información. Ha sido durante mucho tiempo una herramienta critica
+      en la información. Ha sido durante mucho tiempo una herramienta crítica
       para los programadores, quienes normalmente gastaban su tiempo haciendo
       pequeños cambios al software y después deshaciendo esos cambios al día
       siguiente. Pero la utilidad del software de control de versiones se



More information about the svnbook-dev mailing list