Así que ¿qué tan “compatible” es Subversion con otro software DeltaV? En dos palabras: no mucho. Al menos no aún, no en Subversion 1.0.
Mientras que libsvn_ra_dav envía solicitudes DeltaV al servidor, el
cliente de Subversion no es un cliente DeltaV de
propósito general. De hecho, espera ciertas características particulares
(especialmente a través de solicitudes REPORT
personalizadas). Además, mod_dav_svn no es
un servidor DeltaV de propósito general. Sólo implementa un subconjunto
estricto de la especificación DeltaV. Un cliente WebDAV o DeltaV más
general puede interoperar bastante bien con él, pero sólo si el cliente
opera dentro de los estrechos confines de aquéllas caractrísticas que el
servidor ha implementado. El equipo de desarrollo de Subversion planea
completar la interoperabilidad general con WebDAV en un lanzamiento futuro
de Subversion.
Aquí se presenta una descripción muy general de cómo varias operaciones del cliente de Subversion usan DeltaV. En muchos casos, estas explicaciones son simplificaciones groseras. No deberían ser tomadas como un sustituto frente a leer el código fuente de Subversion o hablar con sus desarrolladores.
Ejecuta un PROPFIND de profundidad 1 en la
colección para obtener una lista de los hijos inmediatos. Ejecuta
un GET(y posiblemente un
PROPFIND) en cada hijo. Avanza recursivamente
dentro de las colecciones y repite.
Crea una actividad con NKACTIVITY, y hace un
CHECKOUT de cada ítem que ha cambiado, seguido
de un PUT de datos nuevos. Finalmente, una
solicitud de MERGEprovoca un
CHECKIN implícito de todos los recursos de
trabajo.
Envía una petición personalizada REPORT que
describe
Send a custom REPORT 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
GET and PROPFIND
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.
En el momento de escribir esto, la verdad es que hay muy pocos clientes DeltaV en el mundo; el RFC 3253 aún es relativamente nuevo. Sin embargo, los usuario tienen acceso a clientes “genéricos”, porque casi cada sistema operativo moderno tiene integrado un cliente básico WebDAV. Con esto en mente, los desarrolladores de Subversion se dieron cuenta de que si Subversion 1.0 iba a tener cualquier característica de interoperabilidad, el soporte para autoversionado DeltaV sería la mejor aproximación.
Para activar el auotversionado en mod_dav_svn, use la directiva
SVNAutoversioning dentro del bloque
Location en el archivo
httpd.conf, así:
<Location /repos>
DAV svn
SVNPath /absolute/path/to/repository
SVNAutoversioning on
</Location>
Normalmente, si un cliente WebDAV genérico intentó un
PUT a una ruta dentro de la ubicación de su
repositorio, mod_dav_svn rechazaría la petición.
(Normalmente sólo permite este tipo de operaciones en “recursos de
trabajo” dentro de “actividades” DeltaV.) Con la
opción SVNAutoversioning activada, sin embargo, el
servidor interpreta la petición PUT como un
MKACTIVITY, CHECKOUT,
PUT y CHECKIN. Un mensaje de
registro genérico se genera automáticamente, y se crea además una nueva
revisión del sistema de archivos
Dado que muchos sistemas operativos ya tienen integradas habilidades WebDAV, el caso de uso para esta característica raya en lo fantástico: imagine una oficina de usuarios ordinarios ejecutando Windows o Mac OS. Cada computador “monta” el repositorio de Subversion, que aparece como una unidad compartida de red cualquiera. Usan el servidor como siempre lo hacen: abren archivos del servidor, los editan, y los guardan de vuelta en el servidor. Pero en esta fantasía, el servidor está versionando todo automáticamente. Después, un administrador del sistema puede usar un cliente de Subversion para buscar y recuperar todas las versiones antigüas.
¿Es esta fantasía real? No mucho. El problema principal es que
Subversion 1.0 no tiene ningún tipo de soporte para los métodos
LOCK o UNLOCK. Muchos clientes DAV
de sistemas operativos intentan hacer un LOCK sobre
un recurso abierto directamente de una unidad compartida montada
mediante DAV. Por ahora, los usuarios pueden tener que copiar un archivo
de la unidad DAV al disco local, etidar el archivo, y copiarlo de
vuelta. No es el autoversionado ideal, pero aún hacible.
El módulo mod_dav de Apache es una bestia compleja: entiende y analiza sintácticamente todos los métodos WebDAV y DeltaV, pero depende de un proveedor externo para acceder a los recursos en sí.
En su encarnación más simple, un usuario puede usar mod_dav_sf como un proveedor para mod_dav. mod_dav_fs usa el sistema de archivos ordinario para guardar archivos y directorios, y sólo entiende métodos WebDAV puros, no DeltaV.
Subversion, por otra parte, usa mod_dav_svn como un proveedor para
mod_dav. mod_dav_svn entiende todos los métodos WebDAV excepto
LOCK, y entiende un subconjunto medible de métodos
DeltaV. Él accesa los datos en el repositorio Subversion, en vez de
hacerlo en el sistema de archivos real.
Subversion 1.0 no soporta bloqueo, porque sería realmente difícil de
implementar, dado que Subversion usa el modelo copiar-modificar-mezclar.
[59]
En Apache httpd-2.0, mod_dav soporta el método LOCK
llevando la cuenta de los bloqueos en una base de datos privada,
asumiendo que el proveedor quiera aceptar esto. En Apache httpd-2.1 o
posterior, sin embargo, el soporte de bloqueo se ha puesto en un módulo
independiente, mod_dav_lock. Esto le permite a cualquier proveedor de
mod_dav hacer uso de la base de datos de bloqueos, incluyendo a
mod_dav_svn, aún cuando mod_dav_svn no sabe nada de bloqueo actualmente.
¿Confundido aún?
Resumiendo, mod_dav_lock puede usarse en Apache httpd-2.1
(o posterior) para crear la ilusión de que
mod_dav_svn está cumpliendo las peticiones LOCK.
Asegúrese de que mod_dav_lock esté compilado en httpd, o de que está
siendo cargado en su httpd.conf. Luego simplemente
añada la directiva DAVGenericLockDB a su archivo
de manera similar a ésta:
<Location /repos>
DAV svn
SVNPath /absolute/path/to/repository
SVNAutoversioning on
DavGenericLockDB /path/to/store/locks
</Location>
Esta técnica es un negocio peligroso; de cierta manera, mod_dav_svn le
está mintiendo ahora al cliente WebDAV. El módulo dice aceptar las
solicitudes LOCK, pero en realidad el bloqueo
no está siendo forzado en todos los niveles. Si un segundo cliente
WebDAV intenta hacer un LOCK sobre el mismo recurso,
entonces mod_dav_lock se dará cuenta de ello y denegará (correctamente)
la solicitud.
Pero no hay absolutamente nada que evite que un cliente Subversion
ordinario cambie el archivo vía el comando svn
commit!. Si usted usa esta técnica, le está dando a los
usuarios la oprtunidad de pisotear los cambios de otros.
En paticular, un cliente WebDAV podría sobreescribir accidentalmente un
cambio enviado por cliente svn normal.
Por otra parte, si usted prepara su entorno cuidadosamente, puede mitigar el riesgo. Por ejemplo, si todos sus usuarios están trabajando a través de clientes WebDAV básicos (en vez de clientes svn), entonces todo debería estar bien.
[59] Tal vez algún día Subversion desarrolle un modelo de checkout reservado con bloqueo que pueda vivir en paz con copiar-modificar-mezclar, pero probablemente esto no pase pronto.