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

julot svnbook-dev at red-bean.com
Mon Aug 8 22:47:27 CDT 2005


Author: julot
Date: Mon Aug  8 22:47:25 2005
New Revision: 1596

Modified:
   trunk/src/es/book/appc.xml
Log:
Book Spanish. Translated a few paragraphs of appc.xml. Mostly made to check if my
write access works (first commit)


Modified: trunk/src/es/book/appc.xml
==============================================================================
--- trunk/src/es/book/appc.xml	(original)
+++ trunk/src/es/book/appc.xml	Mon Aug  8 22:47:25 2005
@@ -1,642 +1,658 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
 <!-- originated from English revision 652 -->
 <appendix id="svn-ap-c">
-<title>WebDAV and Autoversioning</title>
+   <title>WebDAV y autoversionado</title>
 
-  <simplesect>
+   <simplesect>
 
-    <para>WebDAV is an extension to HTTP, and is growing more and more
-      popular as a standard for file-sharing.  Today's operating
-      systems are becoming extremely Web-aware, and many have now
-      built-in support for mounting <quote>shares</quote> exported by
-      WebDAV servers.</para>
-
-    <para>If you use Apache/mod_dav_svn as your Subversion network
-      server, then to some extent, you are also running a WebDAV
-      server.  This appendix gives some background on the nature of
-      this protocol, how Subversion uses it, and how well Subversion
-      interoperates with other software that is WebDAV-aware.</para>
-
-  </simplesect>
-
-  <sect1 id="svn-ap-c-sect-1">
-    <title>Basic WebDAV Concepts</title> 
-
-    <para>This section provides a very brief, very general overview to
-      the ideas behind WebDAV.  It should lay the foundation for
-      understanding WebDAV compatibility issues between clients and
-      servers.</para>
-
-    <sect2 id="svn-ap-c-sect-1.1">
-      <title>Just Plain WebDAV</title>
-
-      <para>RFC 2518 defines a set of concepts and accompanying
-        extension methods to HTTP 1.1 that make the web into a more
-        universal read/write medium.  The basic idea is that a
-        WebDAV-compliant web server can act like a generic file server;
-        clients can mount WebDAV <quote>shares</quote> that behave
-        much like NFS or SMB shares.</para>
-      
-      <para>However, it's important to note that RFC 2518 does
-        <emphasis>not</emphasis> provide any sort of model for version
-        control, despite the <quote>V</quote> in DAV.  Basic WebDAV
-        clients and servers assume only one version of each file or
-        directory exists, and can be repeatedly overwritten.
-        <footnote><para>For this reason, some people jokingly refer to
-        generic WebDAV clients as <quote>WebDA</quote>
-        clients!</para></footnote></para>
-  
-      <para>Here are the new concepts and methods introduced in basic
-        WebDAV:</para>
-
-      <variablelist>
-
-        <varlistentry>
-          <term>New write methods</term>
-          <listitem>
-            <para>Beyond the standard HTTP <literal>PUT</literal>
-            method (which creates or overwrites a web resource),
-            WebDAV defines new <literal>COPY</literal> and
-            <literal>MOVE</literal> methods for duplicating or
-            rearranging resources.</para>
-          </listitem>
-        </varlistentry>
-                
-        <varlistentry>
-          <term>Collections</term>
-          <listitem>
-            <para>This is simply the WebDAV term for a grouping of
-              resources (URIs).  In most cases, it is analogous to a
-              <quote>directory</quote>.  You can tell something is a
-              collection if it ends with a trailing <quote>/</quote>.
-              Whereas file resources can be written or created with a
-              <literal>PUT</literal> method, collection resources are
-              created with the new <literal>MKCOL</literal>
-              method.</para>
-          </listitem>
-        </varlistentry>
-
-        <varlistentry>
-          <term>Properties</term>
-          <listitem>
-            <para>This is the same idea present in
-              Subversion—metadata attached to files and
-              collections.  A client can list or retrieve properties
-              attached to a resource with the new
-              <literal>PROPFIND</literal> method, and can change them
-              with the <literal>PROPPATCH</literal> method.  Some
-              properties are wholly created and controlled by users
-              (e.g. a property called <quote>color</quote>), and
-              others are wholly created and controlled by the WebDAV
-              server (e.g. a property that contains the last
-              modification time of a file).  The former kind are
-              called <quote>dead</quote> properties, and the latter
-              kind are called <quote>live</quote> properties.</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>
+         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>
+            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>
+         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>
 



More information about the svnbook-dev mailing list