La forma de control de acceso más simple a un repositorio es autorizar a ciertos usuarios el acceso de sólo lectura, o lectura y escritura.
Puede restringir el acceso sobre todas las operaciones del repositorio añadiendo la directiva Require valid-user al bloque . Usando nuestro ejemplo anterior, esto equivaldría a que sólo los clientes que clamasen ser juan o carmen, y proporcionan la clave correcta para su usuario correspondiente, podrían hacer operaciones con el repositorio Subversion:
DAV svn
SVNParentPath /usr/local/svn
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
# only authenticated users may access the repository
Require valid-user
A veces no necesita extremar tanto la seguridad. Por ejemplo, el propio repositorio de código fuente de Subversion ubicado en http://svn.collab.net/repos/svn permite a cualquiera realizar operaciones de sólo lectura (como por ejemplo obtener copias locales y explorar el repositorio con un navegador web), pero restringe todas las operaciones de escritura a usuarios autenticados. Para realizar este tipo de selección restrictiva, puede usar las directivas de configuración Limit y LimitExcept. Igual que la directiva Location, estos bloques tienen etiquetas de comienzo y final, y las anidaría dentro de su bloque >.
Los parámetros presentes en las directivas Limit y LimitExcept son los tipos de peticiones HTTP afectadas por ese bloque. Por ejemplo, si quisiese prohibir todo el acceso a su repositorio excepto las operaciones actualmente soportadas de sólo lectura, podría usar la directiva LimitExcept incluyendo los tipos de peticiones GET, PROPFIND, OPTIONS, y REPORT. Entonces la directiva anteriormente mencionada Require valid-user sería colocada dentro del bloque en lugar del bloque.
DAV svn
SVNParentPath /usr/local/svn
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
# For any operations other than these, require an authenticated user.
Require valid-user
Estos son sólo unos pocos ejemplos simples. Para más información detallada sobre el control de acceso de Apache y la directiva Require.
Control de acceso por directorio
Es posible establecer permisos más precisos usando el segundo módulo de Apache httpd, mod_authz_svn. Este módulo coge las diversas URLs opacas del cliente al servidor, solicita a mod_dav_svn que las decodifique, y entonces posiblemente veta estas peticiones basándose en la política definida en un fichero de configuración.
Si ha instalado Subversion a partir del código fuente, mod_authz_svn habrá sido instalado automáticamente junto a mod_dav_svn. Muchas distribuciones binarias también lo instalan automáticamente. Para verificar que está instalado correctamente, asegúrese de que viene justo tras la directiva LoadModule de mod_dav_svn en httpd.conf:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
Para activar este módulo, necesita configurar su bloque Location para que use la directiva AuthzSVNAccessFile, la cual especifica el fichero que contiene la política de permisos para las rutas en sus repositorios.
Apache es flexible, así que tiene la opción de configurar su bloque con uno de estos tres patrones generales. Para comenzar, escoja uno de estos patrones básicos de configuración.
El bloque más simple es permitir el acceso a cualquiera. En este escenario, Apache nunca envía solicitudes de autenticación, así que todos los usuarios son tratados como "anónimos".
Ejemplo: A sample configuration for anonymous access.
DAV svn
SVNParentPath /usr/local/svn
# our access control policy
AuthzSVNAccessFile /path/to/access/file
En el lado opuesto de la escala de paranoia, puede configurar su bloque para demandar la autenticación de todo el mundo. Todos los clientes deberán proporcionar credenciales para identificarse. Su bloque requiere de manera incondicional la autenticación vía directiva Require valid-user, y define un método de autenticación.
Ejemplo: A sample configuration for authenticated access.
DAV svn
SVNParentPath /usr/local/svn
# our access control policy
AuthzSVNAccessFile /path/to/access/file
# only authenticated users may access the repository
Require valid-user
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
Un tercer patrón muy popular es permitir una combinación de acceso autenticado y anónimo. Por ejemplo, muchos administradores quieren que los usuarios anónimos puedan leer ciertos directorios del repositorio, pero restringen la lectura (o escritura) de otras áreas más sensibles a usuarios autenticados. Con esta configuración, todos los usuarios comienzan accediendo al repositorio de manera anónima. Si su política de control de acceso requiere un nombre de usuario real en algún punto, Apache demandará una autenticación del cliente. Para hacer esto, use tanto la directiva Satisfy Any como Require valid-user simultáneamente.
Ejemplo: A sample configuration for mixed authenticated/anonymous access.
DAV svn
SVNParentPath /usr/local/svn
# our access control policy
AuthzSVNAccessFile /path/to/access/file
# try anonymous access first, resort to real
# authentication if necessary.
Satisfy Any
Require valid-user
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
Una vez tenga configurado su bloque Location básico, puede crear un fichero de acceso y definir en él algunas reglas de autorización.
La sintaxis del fichero de acceso es la misma que la usada por svnserve.conf y los ficheros del área de configuración de parámetros de ejecución. Las líneas que comienzan con una almohadilla (#) son ignoradas. En su forma más simple, cada sección nombra a un repositorio y ruta dentro del mismo, y los nombres de usuario autenticados son los nombres de las opciones dentro de cada sección. El valor de cada opción describe el nivel de acceso del usuario a la ruta del repositorio: ya sea r (sólo lectura) o rw (lectura-escritura). Si el nombre de un usuario no se menciona, no se le permite el acceso.
Para ser más específicos, el valor de los nombres de sección tienen la forma [repositorio-nombre:ruta] o la forma [ruta]. Si está usando la directiva SVNParentPath, entonces es importante especificar los nombres de repositorio en sus secciones. Si los omite, una sección como [/algún/directorio] coincidirá con la ruta /algún/directorio en cada repositorio. No obstante si está usando la directiva SVNPath, entonces está bien definir rutas en sus secciones—después de todo, sólo hay un repositorio.
[calc:/branches/calc/bug-142]
harry = rw
evelyn = r
En este primer ejemplo, el usuario juan tiene permisos de lectura y escritura sobre el directorio /branches/calc/bug-142 del repositorio calc, pero el usuario carmen sólo tiene permisos de lectura. Cualquier otro usuario tendrá bloqueado el acceso a este directorio.
Por supuesto, los permisos son heredados del directorio padre al hijo. Esto significa que puede especificar un subdirectorio con una política de acceso diferente para Carmen:
[calc:/branches/calc/bug-142]
harry = rw
evelyn = r
# give evelyn write access only to the 'testing' subdir
[calc:/branches/calc/bug-142/testing]
evelyn = rw
Ahora Carmen puede escribir en el subdirectorio testing de la rama, pero sigue accediendo con permisos de sólo lectura a otras ubicaciones. Mientras tanto, Juan continua con permisos de lectura-escritura para toda la rama.
También es posible denegarle los permisos a alguien de manera explícita mediante reglas de herencia, ajustando su variable de nombre de usuario a nada:
[calc:/branches/calc/bug-142]
harry = rw
evelyn = r
[calc:/branches/calc/bug-142/secret]
harry =
En este ejemplo, Juan tiene acceso de lectura-escritura a todo el árbol bug-142, pero no tiene acceso en absoluto al subdirectorio secret dentro del mismo.
Por defecto, nadie tiene acceso en absoluto al repositorio. Esto significa que si comienza con un fichero vacío, probablemente querrá permitir el acceso de lectura la raíz del repositorio a todos los usuarios. Puede hacer esto con la variable asterisco (*), la cual significa "todos los usuarios":
[/]
* = r
Ésta es una configuración común; fíjese que no hay nombre de repositorio nombrado en el nombre de la sección. Esto hace todos los repositorios legibles por todos los usuarios, usando tanto SVNPath como SVNParentPath. Una vez todos los usuarios tienen acceso de lectura a los repositorios, puede dar permisos explícitos rw a determinados usuarios en subdirectorios específicos dentro de repositorios específicos.
La variable asterisco (*) también merece aquí una mención especial: es el único patrón que coincide con el usuario anónimo. Si ha configurado su bloque Location para permitir una mezcla de acceso anónimo y autenticado, todos los usuarios comienzan accediendo a Apache de forma anónima. mod_authz_svn busca el valor * definido para la ruta que se está accediendo; si no puede encontrar uno, entonces Apache demanda una autenticación real del cliente.
El fichero de acceso también le permite definir grupos enteros de usuarios, de manera muy similar al fichero /etc/group Unix:
[groups]
calc-developers = harry, evelyn, joe
paint-developers = frank, evelyn, jane
everyone = harry, evelyn, joe, frank, evelyn, jane
A los grupos se les puede facilitar el acceso igual que a los usuarios. Distíngalos con el prefijo "arroba" (@):
[calc:/projects/calc]
@calc-developers = rw
[paint:/projects/paint]
@paint-developers = rw
jane = r
…y eso es prácticamente todo lo que hay que hacer.
Extra
Hemos cubierto la mayoría de las opciones de autenticación y autorización para Apache y mod_dav_svn. Pero Apache proporciona algunas otras características interesantes.
Uno de los beneficios más útiles de una configuración Apache/WebDAV de su repositorio Subversion es que las revisiones más recientes de sus ficheros y directorios versionados están disponibles inmediatamente para ser visualizados con un navegador web normal. Dado que Subversion usa URLs para identificar recursos versionados, aquellas URLs basadas en HTTP para acceder al repositorio pueden teclearse directamente en un navegador. Su navegador realizará una petición GET para esta URL, y dependiendo de que ésta represente un directorio o fichero versionado, mod_dav_svn responderá con un listado de directorio o con el contenido del fichero.
Dado que las URLs no contienen información sobre qué versión del recurso desea ver, mod_dav_svn responderá siempre con la versión más reciente. Esta funcionalidad tiene el maravilloso efecto secundario de que puede pasar a sus colegas referencias a documentos, y esas URLs siempre apuntarán a la última manifestación de los mismos. Por supuesto, también puede usar las URLs como hiperenlaces desde otras páginas web.
Generalmente obtendrá más utilidad del uso de URLs a ficheros versionados—después de todo, ahí es donde suele estar el contenido interesante. Pero quizás disponga de la ocasión de navegar por un listado de directorio de Subversion, y percibir que el HTML generado para mostrar el listado es muy básico, y desde luego no está pensado para ser estéticamente agradable (o incluso interesante). Para permitir la personalización de estas muestras de directorio, Subversion proporciona una característica de indexado XML. Una única directiva SVNIndexXSLT en el bloque Location de httpd.conf indicará a mod_dav_svn que genere la salida del listado de directorio en un XML, usando como referencia una hoja de estilo XSLT de su elección:
DAV svn
SVNParentPath /usr/local/svn
SVNIndexXSLT "/svnindex.xsl"
.
Usando la directiva SVNIndexXSLT y una hoja de estilo XSLT creativa, puede hacer que sus listados de directorio concuerden con los esquemas de color e imágenes usados en otras partes de su página web. O, si lo prefiere, puede usar las hojas de estilo de ejemplo que proporciona la distribución de código fuente de Subversion en el directorio tools/xslt/. Tenga en cuenta que la ruta que apunta al directorio SVNIndexXSLT es en realidad una URL—¡los navegadores deben poder leer sus hojas de estilo para poder usarlas!
Algunas de las características proporcionadas por Apache en su rol de servidor web robusto también pueden ser aprovechadas para incrementar la funcionalidad o seguridad en Subversion. Subversion se comunica con Apache usando Neon, que es una librería HTTP/WebDAV genérica con soporte para mecanismos tales como SSL (Secure Socket Layer, discutidos anteriormente) y compresión Deflate (el mismo algoritmo usado por los programas gzip y PKZIP para "reducir" ficheros en bloques de datos de tamaño menor). Sólo necesita compilar el soporte de las características que desea tener en Subversion y Apache, y configurar adecuadamente estos programas para que las usen.
La compresión Deflate carga ligeramente al cliente y al servidor para comprimir y descomprimir transmisiones por red para minimizar el tamaño de los datos. En aquellos casos donde el ancho de banda de red es escaso, este tipo de compresión puede incrementar sustancialmente la velocidad con la que se comunican el servidor y el cliente. En casos extremos, la minimización de la transmisión por red puede marcar la diferencia entre una operación cuyo tiempo de espera es agotado o termina con éxito.
Menos interesantes, pero igualmente útiles, son otras características de la relación entre Apache y Subversion, como la capacidad de especificar un puerto específico (en lugar del puerto 80 por defecto de HTTP) o un nombre de dominio virtual mediante el cual se pueda acceder a un repositorio de Subversion, o la capacidad de acceder al repositorio a través de un proxy. Estas cosas las soporta Neon, así que Subversion las obtiene de manera gratuita.
Por último, dado que mod_dav_svn habla un dialecto semi completo de WebDAV/DeltaV, es posible acceder al repositorio mediante clientes DAV de terceros. La mayoría de los sistemas operativos modernos (Win32, OS X, y Linux) tienen soporte para montar un servidor DAV como un "recurso" estándar de red.
Ofrecer múltiples métodos de acceso al repositorio
Le hemos enseñado a acceder a un repositorio de muchas maneras diferentes. Pero, ¿es posible—o seguro—acceder a su repositorio mediante múltiples métodos simultáneamente? La respuesta es afirmativa, siempre y cuando planifique un poco las cosas.
En cualquier instante, estos procesos pueden requerir acceso de lectura y escritura a su repositorio:
usuarios normales del sistema (que se identifican como ellos mismos) usando un cliente de Subversion para acceder a los repositorios directamente vía URLs file:///;
usuarios normales del sistema (que se identifican como ellos mismos) conectándose a procesos svnserve privados mediante sesiones SSH, los cuales acceden al repositorio;
un proceso svnserve—ya sea un demonio o uno invocado por inetd—ejecutándose como un usuario particular invariable;
un proceso httpd de Apache, ejecutándose como un usuario particular invariable.
El problema más común que se encuentran los administradores es con la propiedad y permisos del repositorio. ¿Tiene cada proceso (o usuario) en la lista anterior permisos para leer y escribir los ficheros de la base de datos Berkeley? Asumiendo que tiene un sistema operativo tipo Unix, una opción simple sería colocar a cada usuario potencial del repositorio en un nuevo grupo svn, y hacer que el repositorio al completo esté poseído por este grupo. Pero ni si quiera eso es suficiente, porque un proceso puede escribir los ficheros de la base de datos usando una máscara de permisos hostil—aquella que impida el acceso a otros usuarios.
Así que el siguiente paso tras el establecimiento de un grupo común para los usuarios del repositorio es forzar a todos los procesos que acceden al repositorio a usar una máscara de permisos aceptable. Para los usuarios que acceden al repositorio directamente, puede envolver el programa svn en un script cuyo primer paso sea ejecutar umask 002 y después ejecute el programa cliente svn auténtico. Puede escribir un script de envoltorio similar para el programa svnserve, y añadir el comando umask 002 al propio fichero de arranque de Apache, apachectl. Por ejemplo:
$ cat /usr/local/bin/svn
#!/bin/sh
umask 002
/usr/local/subversion/bin/svn "$@"
Hay otro problema común en sistemas tipo Unix. A medida que se usa un repositorio, la base de datos Berkeley ocasionalmente crea nuevos ficheros de registro para sus transacciones. Incluso si el repositorio completo pertenece al grupo svn, estos nuevos ficheros no pertenecerán necesariamente al mismo grupo, lo cual crea de nuevo problemas de permisos para sus usuarios. Un buen método para corregir esto es activar el bit de grupo SUID en el directorio db del repositorio. Esto causa que todos los ficheros de registros creados tengan el mismo grupo que el directorio padre..
Una vez haya saltado por estos aros, su repositorio debería ser accesible por todos los procesos necesarios. Puede que parezca un poco lioso y complicado, pero los problemas de tener múltiples usuarios compartiendo acceso de escritura a ficheros comunes son clásicos, pocas veces solucionados de manera elegante.
Afortunadamente, la mayoría de los administradores de repositorios no tendrán nunca la necesidad de tener configuraciones tan complejas. Los usuarios que desean acceder a repositorios que residen en la misma máquina no están limitados a usar el las URLs de acceso file://—típicamente pueden contactar con el servidor HTTP de Apache o svnserve usando el nombre de servidor localhost en sus URLs http:// o svn://. Y mantener múltiples procesos servidores para sus repositorios de Subversion es probablemente un dolor de cabeza más que algo necesario.
Lista de tareas para servidor svn+ssh://
Puede ser complicado hacer que un grupo de usuarios con cuentas SSH existentes compartan un repositorio sin problemas de permisos. Si se siente confuso respecto a todas las cosas que usted (como administrador) necesita realizar en un sistema tipo Unix, aquí tiene una lista de tareas que resumen algunas de las cosas discutidas en esta sección:
Todos sus usuarios SSH necesitan ser capaces de leer y escribir en el repositorio. Ponga a todos los usuarios SSH en un único grupo. Haga que el propietario del repositorio sea ese grupo, y active los permisos de lectura/escritura para el mismo.
Sus usuarios deben usar una máscara de permisos aceptable al acceder al repositorio. Asegúrese de que svnserve (/usr/local/bin/svnserve, o donde quiera que esté en $PATH) es en realidad un script envoltorio que ejecuta umask 002 y luego el binario svnserve auténtico. Tome medidas similares con svnlook y svnadmin. Es decir, ejecútelos con una máscara de permisos aceptable, o envuélvalos tal y como se describe anteriormente.
Cuando la base de datos Berkeley crea nuevos ficheros de registros, también necesitan pertenecer al mismo grupo, así que asegúrese de que ejecuta chmod g+s en el directorio db del repositorio.
Listado de comandos
El cliente de línea de comando de Subversión: svn
Para usar el cliente de línea de comando, debe teclear svn, el subcomando que desea usar y cualquier parámetro u objetivos sobre los cuales desea operar—no hay un orden específico en el cual deben aparecer los subcomandos y parámetros. Por ejemplo, todos los siguientes ejemplos de uso de svn status son válidos:
$ svn -v status
$ svn status -v
$ svn status -v myfile
Parámetros de svn
Aunque Subversión tiene diferentes parámetros para sus subcomandos, todos los parámetros son globales—es decir, se garantiza que cada parámetro significa la misma cosa sin importar el subcomando que use. Por ejemplo, –verbose (-v) siempre significa "salida abundante de mensajes", sin importar el subcomando con el que lo use.
–auto-props
Activa auto propiedades, reemplazando la directiva enable-auto-props del fichero config.
–config-dir DIR
Indica a Subversión que lea la información de configuración del directorio especificado en lugar del lugar por defecto (.subversión en el directorio home del usuario).
–diff-cmd CMD
Especifica el programa externo que desea usar para mostrar las diferencias entre ficheros. Cuando invoca svn diff, usa el motor diferencial interno de Subversión, el cual genera ficheros diferenciales en formato unificado por defecto. Si quiere usar un programa de diferenciación externo, use –diff-cmd. Puede pasar parámetros a su programa de diferenciación con el parámetro –extensions (más sobre esto adelante en esta sección).
–diff3-cmd CMD
Especifica el programa externo que desea usar para fusionar los ficheros.
–dry-run
Recorre todo el proceso interno de la ejecución del comando, pero en realidad no se realizan cambios—ya sea en disco o en el repositorio.
–editor-cmd CMD
Especifica el programa externo que desea usar para modificar mensajes de informes de cambios o valores de propiedades.
–encoding ENC
Indica a Subversión que el mensaje que escribe al enviar cambios al repositorio está en la codificación indicada. Por defecto se usa la configuración local nativa de su sistema operativo, y debería especificar la codificación si sus mensajes de cambios están en otra codificación.
–extensions (-x) ARGS
Especifica un parámetro o varios que Subversión debe pasar al comando de diferenciación externo cuando se muestran diferencias entre ficheros. Si desea pasar múltiples argumentos, debe entrecomillarlos todos (por ejemplo, svn diff –diff-cmd /usr/bin/diff -x "-b -E"). Este parámetro sólo puede ser usado si también usa el parámetro –diff-cmd.
–file (-F) FILENAME
Usa el contenido del fichero pasado como argumento de este parámetro para el subcomando especificado.
–force
Obliga la ejecución de un comando u operación particular. Hay algunas operaciones que Subversión evitará hacer durante un uso normal, pero puede pasar el parámetro de forzado para decirle a Subversión "Se lo que estoy haciendo y las posibles repercusiones de mis actos, así que déjame hacerlos". Este parámetro es el equivalente programático de realizar algún trabajo eléctrico sin desconectar la corriente—si no sabe lo que está haciendo, es probable que consiga una desagradable electrocución.
–force-log
Obliga la aceptación de parámetros sospechosos usados con las opciones –message (-m) o –file (-F). Por defecto, Subversión producirá un error si los parámetros de estas opciones perecen ser objetivos del subcomando. Por ejemplo, si pasa la ruta de un fichero versionado a la opción –file (-F), Subversión asumirá que ha cometido un fallo, y que esa ruta era en realidad el objetivo de la operación, y simplemente se equivocó al indicar el fichero—no versionado—que contiene el registro de mensajes de cambios. Para confirmar su intención y anular este tipo de errores, pase la opción –force-log a comandos que aceptan mensajes de cambios.
–help (-h o -?)
Si se usa con uno o más subcomandos, muestra la ayuda de texto empotrada en el cliente para cada subcomando. Si se usa sin nada más, muestra la ayuda de texto genérica del cliente.
–ignore-ancestry
Indica a Subversión que ignore la ascendencia cuando calcule diferencias (sólo usará el contenido de las rutas).
–incremental
Muestra la salida en un formato que permite la concatenación.
–message (-m) MESSAGE
Indica que especificará el mensaje del informe de cambios en la línea de comando, siguiendo al parámetro. Por ejemplo:
$ svn commit -m "They don't make Sunday."
–new ARG
Usa ARG como el objetivo nuevo.
–no-auth-cache
Previene el cacheado de información de autenticación (ej: nombre de usuario y clave de acceso) en los directorios administrativos de Subversión.
–no-auto-props
Desactiva las propiedades automáticas, reemplazando la directiva enable-auto-props del fichero config.
–no-diff-deleted
Evita que Subversión muestre diferencias para ficheros borrados. El comportamiento por defecto cuando elimina un fichero es que svn diff imprima las mismas diferencias que vería si hubiese dejado el fichero pero eliminando su contenido.
–no-ignore
Muestra ficheros en el listado de estado que normalmente serían omitidos debido a que coinciden con un patrón de la propiedad svn:ignore.
–non-interactive
En el caso de un fallo de autenticación, o credenciales insuficientes, evita que se soliciten las credenciales (ej: nombre de usuario o clave). Esto es útil si está ejecutando Subversión dentro de un script automático y le resulta más apropiado que Subversión falle en lugar de pedir más información de manera interactiva.
–non-recursive (-N)
Evita que un subcomando entre de manera recursiva en subdirectorios. La mayoría de los subcomandos son recursivos por defecto, pero algunos subcomandos—normalmente aquellos que tienen el potencial de borrar o deshacer sus modificaciones locales—no lo son.
–notice-ancestry
Presta atención a la ascendencia cuando calcula diferencias.
–old ARG
Usa ARG como el objetivo antiguo.
–password PASS
Indica en la línea de comando la palabra clave para la autenticación—de otro modo, siempre que sea necesario, Subversión le preguntará por ella.
–quiet (-q)
Solicita que el cliente imprima solamente la información esencial mientras realiza su operación.
–recursive (-R)
Obliga a un subcomando a que entre de manera recursiva en subdirectorios. La mayoría de los subcomandos son recursivos por defecto.
–relocate FROM TO [PATH…]
Usado con el subcomando svn switch, cambia la ubicación del repositorio que su copia local de trabajo referencia. Esto es útil si la ubicación de su repositorio cambia y tiene una copia local existente que querría continuar usando.
–revision (-r) REV
Indica que va a proporcionar una revisión (o rango de revisiones) para una operación en particular. Puede proporcionar números de revisión, palabras clave o fechas (rodeadas por llaves), como argumentos del parámetro de revisión. Si quiere proporcionar un rango de revisiones, puede proporcionar dos revisiones separadas por dos puntos. Por ejemplo:
$ svn log -r 1729
$ svn log -r 1729:HEAD
$ svn log -r 1729:1744
$ svn log -r {2001-12-04}:{2002-02-17}
$ svn log -r 1729:{2002-02-17}
–revprop
Opera sobre una propiedad de revisión en lugar de una propiedad Subversión particular de un fichero o directorio. Este parámetro requiere que también indique la revisión con el parámetro –revision (-r).
–show-updates (-u)
Hace que el cliente muestre la información sobre qué ficheros de su copia local de trabajo no están actualizados. Esto realmente no actualiza ninguno de sus ficheros—solamente muestra qué ficheros serían actualizados en caso de ejecutar svn update.
–stop-on-copy
Hace que el subcomando de Subversión que está recorriendo la historia de un recurso versionado deje de procesar esa información histórica cuando encuentre una copia—es decir, un punto en la historia cuando el recurso fue copiado desde otra ubicación del repositorio.
–strict
Hace que Subversión siga unas semánticas estrictas, una noción que es bastante vaga a no ser que hablemos de subcomandos específicos.
–targets FILENAME
Indica a Subversión que obtenga un listado de los ficheros sobre los que usted desea operar a partir del fichero proporcionado en lugar de listar todos sus nombres en la línea de comando.
–username NAME
Indica que está proporcionando su nombre de usuario para la autenticación en la línea de comando—de lo contrario, si es necesario, Subversión le preguntará por el.
–verbose (-v)
Solicita que el cliente imprima tanta información como sea posible mientras ejecuta cualquier subcomando. Esto puede tener como resultado que Subversión imprima campos adicionales, información detallada sobre cada fichero, o información adicional relacionada con las acciones que toma.
–version
Imprime la información de versión del cliente. Esta información no sólo incluye el número del cliente, sino que también muestra un listado de todos los módulos de acceso a repositorio que el cliente puede usar para acceder a repositorios de Subversión.
–xml
Imprime la salida en formato XML.
Subcomandos de svn
svn add
Añade ficheros y directorios.
svn add PATH…
Para añadir un fichero a su copia de trabajo local:
$ svn add foo.c
A foo.c
Cuando añade un directorio, el comportamiento por defecto de svn add es recurrir dentro:
$ svn add testdir
A testdir
A testdir/a
A testdir/b
A testdir/c
A testdir/d
Puede añadir un directorio sin añadir su contenido:
$ svn add –non-recursive otherdir
A otherdir
svn blame
Muestra en línea información del autor y la revisión sobre los ficheros o URLs especificados.
svn blame TARGET…
Si quiere ver el código fuente de readme.txt en su repositorio de pruebas anotado con la información de blame:
$ svn blame http://svn.red-bean.com/repos/test/readme.txt
3 evelyn This is a README file.
5 harry You should read this.
svn cat
Vuelca el contenido de los ficheros o URLs especificados.
svn cat TARGET…
Si quiere ver readme.txt de su repositorio sin obtener una copia local:
$ svn cat http://svn.red-bean.com/repos/test/readme.txt
This is a README file.
You should read this.
svn checkout
Obtiene una copia local de trabajo de un repositorio.
svn checkout URL… [PATH]
Obtener una copia local en un directorio llamado 'mine':
$ svn checkout file:///tmp/repos/test mine
A mine/a
A mine/b
Checked out revision 2.
$ ls
mine
Obtener dos directorios diferentes en dos copias locales de trabajo separadas:
$ svn checkout file:///tmp/repos/test file:///tmp/repos/quiz
A test/a
A test/b
Checked out revision 2.
A quiz/l
A quiz/m
Checked out revision 2.
$ ls
quiz test
Obtener dos directorios diferentes en dos copias locales de trabajo separadas, pero guardando ambas en un directorio llamado 'working copies':
$ svn checkout file:///tmp/repos/test file:///tmp/repos/quiz working-copies
A working-copies/test/a
A working-copies/test/b
Checked out revision 2.
A working-copies/quiz/l
A working-copies/quiz/m
Checked out revision 2.
$ ls
working-copies
Si interrumpe la operación (o alguna otra cosa interrumpe su operación de descarga como una pérdida de conectividad, etc), puede continuarla ya sea ejecutando el mismo comando para obtener la copia local de nuevo, o actualizando la copia local de trabajo incompleta:
$ svn checkout file:///tmp/repos/test test
A test/a
A test/b
^C
svn: The operation was interrupted
svn: caught SIGINT
$ svn checkout file:///tmp/repos/test test
A test/c
A test/d
^C
svn: The operation was interrupted
svn: caught SIGINT
$ cd test
$ svn update
A test/e
A test/f
Updated to revision 3.
svn cleanup
Limpia la copia local de trabajo de forma recursiva.
svn cleanup [PATH…]
svn commit
Envía cambios desde su copia de trabajo local al repositorio.
svn commit [PATH…]
Enviar al servidor una modificación simple a un fichero con el mensaje del informe de cambios en la línea de comando y el objetivo implícito del directorio actual ("."):
$ svn commit -m "added howto section."
Sending a
Transmitting file data .
Committed revision 3.
Enviar los cambios de una modificación al fichero foo.c (especificada de forma explícita en la línea de comando con el mensaje del informe de cambios contenido en un fichero llamado msg:
$ svn commit -F msg foo.c
Sending foo.c
Transmitting file data .
Committed revision 5.
Si quiere usar un fichero que está bajo control de versiones para el mensaje del informe de cambios con –file, necesita pasar también el parámetro –force-log:
$ svn commit –file file_under_vc.txt foo.c
svn: The log message file is under version control
svn: Log message file is a versioned file; use '–force-log' to override
$ svn commit –force-log –file file_under_vc.txt foo.c
Sending foo.c
Transmitting file data .
Committed revision 6.
Para enviar al repositorio el cambio de un fichero programado para ser borrado:
$ svn commit -m "removed file 'c'."
Deleting c
Committed revision 7.
svn copy
Copia un fichero o un directorio en la copia de trabajo local o en el repositorio.
svn copy SRC DST
Copia un fichero en la copia de trabajo local o en el repositorio. SRC y DST pueden ser ambos o bien la ruta de una copia de trabajo local (WC) o una URL:
WC -> WC
Copia y programa la adición (con historia) de un elemento.
WC -> URL
Envía al servidor inmediatamente una copia de WC a URL.
URL -> WC
Obtiene una copia local de URL en WC, y la programa para una adición.
URL -> URL
Copia realizada por completo en el servidor. Esto normalmente se usa para crear una rama o etiqueta.
svn delete
Borra un elemento de una copia de trabajo local o del repositorio.
svn delete PATH…
svn delete URL…
Usar svn para borrar un fichero de su copia local de trabajo meramente lo programa para ser borrado. Cuando envía cambios al repositorio, el fichero es borrado del mismo.
$ svn delete myfile
D myfile
$ svn commit -m "Deleted file 'myfile'."
Deleting myfile
Transmitting file data .
Committed revision 14.
Borrar una URL es, no obstante, inmediato, por lo que debe proporcionar un mensaje para el informe de cambios:
$ svn delete -m "Deleting file 'yourfile'" file:///tmp/repos/test/yourfile
Committed revision 15.
Aquí tiene un ejemplo de cómo forzar el borrado de un fichero que tiene modificaciones locales:
$ svn delete over-there
svn: Attempting restricted operation for modified resource
svn: Use –force to override this restriction
svn: 'over-there' has local modifications
$ svn delete –force over-there
D over-there
svn diff
Muestra las diferencias entre dos rutas.
svn diff [-r N[:M]] [–old OLD-TGT] [–new NEW-TGT] [PATH…]
svn diff -r N:M URL
svn diff [-r N[:M]] URL1[@N] URL2[@M]
Para comparar la versión BASE con su copia local de trabajo (uno de los usos más populares de svn diff):
$ svn diff COMMITTERS
Index: COMMITTERS
===================================================================
— COMMITTERS (revision 4404)
+++ COMMITTERS (working copy)
Compruebe cómo sus modificaciones locales son comparadas contra una versión anterior:
$ svn diff -r 3900 COMMITTERS
Index: COMMITTERS
===================================================================
— COMMITTERS (revision 3900)
+++ COMMITTERS (working copy)
Comparar la revisión 3000 con la 3500 usando la sintaxis "@":
$ svn diff http://svn.collab.net/repos/svn/trunk/COMMITTERS@3000 http://svn.collab.net/repos/svn/trunk/COMMITTERS@3500
Index: COMMITTERS
===================================================================
— COMMITTERS (revision 3000)
+++ COMMITTERS (revision 3500)
.
Comparar la revisión 3000 con la 3500 usando la notación de rango (en este caso sólo proporciona una URL):
$ svn diff -r 3000:3500 http://svn.collab.net/repos/svn/trunk/COMMITTERS
Index: COMMITTERS
===================================================================
— COMMITTERS (revision 3000)
+++ COMMITTERS (revision 3500)
Comparar la revisión 3000 con la 3500 de todos los ficheros en trunk usando la notación de rango:
$ svn diff -r 3000:3500 http://svn.collab.net/repos/svn/trunk
Comparar la revisión 3000 con la 3500 de sólo tres ficheros en trunk usando la notación de rango:
$ svn diff -r 3000:3500 –old http://svn.collab.net/repos/svn/trunk COMMITTERS README HACKING
Si tiene una copia de trabajo local, puede obtener las diferencias sin necesidad de teclear largas URLs:
$ svn diff -r 3000:3500 COMMITTERS
Index: COMMITTERS
===================================================================
— COMMITTERS (revision 3000)
+++ COMMITTERS (revision 3500)
Use la opción –diff-cmd CMD -x para pasar argumentos de manera directa al programa externo de diferenciación
$ svn diff –diff-cmd /usr/bin/diff -x "-i -b" COMMITTERS
Index: COMMITTERS
===================================================================
0a1,2
> This is a test
>
svn export
Exporta un árbol de directorios limpio.
svn export [-r REV] URL [PATH]
svn export PATH1 PATH2
Exportar desde su copia de trabajo local (no muestra cada fichero y directorio individual):
$ svn export a-wc my-export
Export complete.
Exportar desde un repositorio (muestra cada fichero y directorio):
$ svn export file:///tmp/repos my-export
A my-export/test
A my-export/quiz
.
Exported revision 15.
svn help
¡Ayuda!
svn help [SUBCOMMAND…]
svn import
El comando svn import es una manera rápida de copiar un árbol de ficheros sin versionar en el repositorio, creando directorios intermedios como sea necesario.
$ svnadmin create /usr/local/svn/newrepos
$ svn import mytree file:///usr/local/svn/newrepos/some/project
Adding mytree/foo.c
Adding mytree/bar.c
Adding mytree/subdir
Adding mytree/subdir/quux.h
Committed revision 1.
El ejemplo anterior copia el contenido del directorio mytree debajo del directorio some/project en el repositorio:
$ svn ls file:///usr/local/svn/newrepos/some/project
bar.c
foo.c
subdir/
Observe que después de que la importación esté acabada, el árbol original no se convierte en una copia de trabajo. Para empezar a trabajar, usted todavía necesita hacer svn checkout en una copia de trabajo fresca del árbol.
svn info
Imprime información sobre RUTAs.
svn info [PATH…]
Mostrará toda la información útil que tiene para los elementos en su copia local de trabajo. Mostrará información sobre ficheros:
$ svn info foo.c
Path: foo.c
Name: foo.c
URL: http://svn.red-bean.com/repos/test/foo.c
Revision: 4417
Node Kind: file
Schedule: normal
Last Changed Author: evelyn
Last Changed Rev: 20
Last Changed Date: 2003-01-13 16:43:13 -0600 (Mon, 13 Jan 2003)
Text Last Updated: 2003-01-16 21:18:16 -0600 (Thu, 16 Jan 2003)
Properties Last Updated: 2003-01-13 21:50:19 -0600 (Mon, 13 Jan 2003)
Checksum: /3L38YwzhT93BWvgpdF6Zw==
Y también mostrará información sobre directorios:
$ svn info vendors
Path: trunk
URL: http://svn.red-bean.com/repos/test/vendors
Revision: 19
Node Kind: directory
Schedule: normal
Last Changed Author: harry
Last Changed Rev: 19
Last Changed Date: 2003-01-16 23:21:19 -0600 (Thu, 16 Jan 2003)
svn list
Lista las entradas de directorio en el repositorio.
svn list [TARGET…]
Es útil sobre todo cuando desea ver qué ficheros contiene un repositorio sin tener que descargar una copia local de trabajo del mismo:
$ svn list http://svn.red-bean.com/repos/test/support
README.txt
INSTALL
examples/
.
Al igual que el comando UNIX ls, puede pasar el parámetro –verbose para obtener información adicional:
$ svn list –verbose file:///tmp/repos
16 evelyn 28361 Jan 16 23:18 README.txt
27 evelyn 0 Jan 18 15:27 INSTALL
24 harry Jan 18 11:27 examples/
svn log
Muestra los mensajes de los informes de cambios.
svn log [PATH]
svn log URL [PATH…]
Puede ver los mensajes de informes de cambios para todas las rutas que fueron modificadas en su copia local ejecutando svn log:
$ svn log
————————————————————————
r20 | harry | 2003-01-17 22:56:19 -0600 (Fri, 17 Jan 2003) | 1 line
Tweak.
————————————————————————
r17 | evelyn | 2003-01-16 23:21:19 -0600 (Thu, 16 Jan 2003) | 2 lines
.
Examinar todos los mensajes de informes de cambios para un fichero particular de su copia local de trabajo:
$ svn log foo.c
————————————————————————
r32 | evelyn | 2003-01-13 00:43:13 -0600 (Mon, 13 Jan 2003) | 1 line
Added defines.
————————————————————————
r28 | evelyn | 2003-01-07 21:48:33 -0600 (Tue, 07 Jan 2003) | 3 lines
.
Si no tiene a mano una copia local, puede obtener los mensajes de informes de cambios a partir de una URL:
$ svn log http://svn.red-bean.com/repos/test/foo.c
————————————————————————
r32 | evelyn | 2003-01-13 00:43:13 -0600 (Mon, 13 Jan 2003) | 1 line
Added defines.
————————————————————————
r28 | evelyn | 2003-01-07 21:48:33 -0600 (Tue, 07 Jan 2003) | 3 lines
.
Si quiere usar varias rutas distintas bajo una misma URL, puede usar la sintaxis URL [PATH…].
$ svn log http://svn.red-bean.com/repos/test/ foo.c bar.c
————————————————————————
r32 | evelyn | 2003-01-13 00:43:13 -0600 (Mon, 13 Jan 2003) | 1 line
Added defines.
————————————————————————
r31 | harry | 2003-01-10 12:25:08 -0600 (Fri, 10 Jan 2003) | 1 line
Added new file bar.c
————————————————————————
r28 | evelyn | 2003-01-07 21:48:33 -0600 (Tue, 07 Jan 2003) | 3 lines
.
Eso es igual que poner de forma explícita ambas URLs en la línea de comando:
$ svn log http://svn.red-bean.com/repos/test/foo.c
http://svn.red-bean.com/repos/test/bar.c
.
Cuando concatene los resultados de múltiples llamadas al comando log, quizás desee usar el parámetro –incremental. svn log normalmente imprime una línea de guiones al comienzo de cada mensaje de informe de cambios, entre mensajes, y después el último. Si ejecuta svn log sobre un rango de dos revisiones, obtendría esto:
$ svn log -r 14:15
————————————————————————
r14 | …
————————————————————————
r15 | …
————————————————————————
No obstante, si quisiese recoger dos mensajes de informes de cambios no secuenciales en un mismo fichero, podría hacer algo como esto:
$ svn log -r 14 > mylog
$ svn log -r 19 >> mylog
$ svn log -r 27 >> mylog
$ cat mylog
————————————————————————
r14 | …
————————————————————————
————————————————————————
r19 | …
————————————————————————
————————————————————————
r27 | …
————————————————————————
Puede evitar la duplicidad de líneas de guiones en la salida usando el parámetro incremental:
$ svn log –incremental -r 14 > mylog
$ svn log –incremental -r 19 >> mylog
$ svn log –incremental -r 27 >> mylog
$ cat mylog
————————————————————————
r14 | …
————————————————————————
r19 | …
————————————————————————
r27 | …
El parámetro –incremental proporciona un control de la salida similar cuando usa el parámetro –xml.
svn merge
Aplica las diferencias entre dos fuentes a una ruta de su copia local de trabajo.
svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
svn merge -r N:M SOURCE [PATH]
Fusionar una rama de nuevo en el tronco (asumiendo que tiene una copia local del tronco, y que la rama fue creada en la revisión 250):
$ svn merge -r 250:HEAD http://svn.red-bean.com/repos/branches/my-branch
U myproj/tiny.txt
U myproj/thhgttg.txt
U myproj/win.txt
U myproj/flo.txt
Si creó una rama en la revisión 23, y quiere fusionar los cambios del tronco en ella, puede hacer lo siguiente desde su copia local de trabajo de la rama:
$ svn merge -r 23:30 file:///tmp/repos/trunk/vendors
U myproj/thhgttg.txt
.
Para fusionar cambios en un único fichero:
$ cd myproj
$ svn merge -r 30:31 thhgttg.txt
U thhgttg.txt
svn mkdir
Crear directorio
svn mkdir PATH
svn move
Mover un fichero o directorio.
svn move SRC DST
Mover un fichero en su copia local de trabajo:
$ svn move foo.c bar.c
A bar.c
D foo.c
Mover un fichero en el repositorio (el cambio es inmediato, por lo que se requiere un mensaje de informe de cambios):
$ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c
http://svn.red-bean.com/repos/bar.c
Committed revision 27.
svn propdel
Borrar la propiedad de un elemento.
svn propdel PROPNAME [PATH…]
svn propdel PROPNAME –revprop -r REV [URL]
Borrar la propiedad de un fichero de su copia local de trabajo
$ svn propdel svn:mime-type some-script
property 'svn:mime-type' deleted from 'some-script'.
Borrar la propiedad de una revisión:
$ svn propdel –revprop -r 26 release-date
property 'release-date' deleted from repository revision '26'
svn propedit
Editar la propiedad de uno o más elementos bajo control de versiones.
svn propedit PROPNAME PATH…
svn propedit PROPNAME –revprop -r REV [URL]
Facilita la modificación de propiedades que tienen múltiples valores:
$ svn propedit svn:keywords foo.c
containing the current contents of the svn:keywords property. You
can add multiple values to a property easily here by entering one
value per line.>
Set new value for property 'svn:keywords' on 'foo.c'
svn propget
Imprime el valor de una propiedad.
svn propget PROPNAME [PATH…]
svn propget PROPNAME –revprop -r REV [URL]
Examinar la propiedad de un fichero en su copia local de trabajo:
$ svn propget svn:keywords foo.c
Author
Date
Rev
Lo mismo sirve para una propiedad de revisión:
$ svn propget svn:log –revprop -r 20
Began journal.
svn proplist
Mostrar todas las propiedades.
svn proplist [PATH…]
svn proplist –revprop -r REV [URL]
Puede usar proplist para ver las propiedades asociadas a un elemento en su copia local de trabajo:
$ svn proplist foo.c
Properties on 'foo.c':
svn:mime-type
svn:keywords
owner
Pero con el parámetro –verbose, svn proplist es extremadamente útil ya que también muestra los valores de las propiedades:
$ svn proplist –verbose foo.c
Properties on 'foo.c':
svn:mime-type : text/plain
svn:keywords : Author Date Rev
owner : evelyn
svn propset
Asocia PROPNAME a PROPVAL en ficheros, directorios, o revisiones.
svn propset PROPNAME [PROPVAL | -F VALFILE] PATH…
svn propset PROPNAME –revprop -r REV [PROPVAL | -F VALFILE] [URL]
Si obtiene un conflicto tras una actualización, su copia de trabajo local generará tres nuevos ficheros:
$ svn update
C foo.c
Updated to revision 31.
$ ls
foo.c
foo.c.mine
foo.c.r30
foo.c.r31
svn resolved
Deja que Subversión lo sepa una ves resuelto un conflicto. Esto borrará los ficheros temporales y Subversión no considerará por más tiempo que el fichero está en estado de conflicto.
$ svn resolved evelyn.txt
Resolved conflicted state of 'evelyn.txt'
svn revert
Deshacer todas las modificaciones locales.
svn revert PATH…
svn status
Le dará toda la información que necesita sobre qué ha cambiado en su copia de trabajo local.
En este ejemplo puede ver todos los códigos de estado diferentes que svn status puede devolver. (Observe que el texto que sigue a # en el siguiente ejemplo no es impreso realmente por svn status.)
$ svn status
L abc.c # svn has a lock in its .svn directory for abc.c
M bar.c # the content in bar.c has local modifications
M baz.c # baz.c has property but no content modifications
X 3rd_party # this dir is part of an externals definition
? foo.o # svn doesn't manage foo.o
! some_dir # svn manages this, but it's either missing or incomplete
~ qux # versioned as dir, but is file, or vice versa
I .screenrc # this file is ignored
A + moved_dir # added with history of where it came from
M + moved_dir/README # added with history and has local modifications
D stuff/fish.c # this file is scheduled for deletion
A stuff/loot/bloo.h # this file is scheduled for addition
C stuff/loot/lump.c # this file has conflicts from an update
S stuff/squawk # this file or dir has been switched to a branch
.
svn switch
Actualizar una copia local de trabajo a una URL diferente.
svn switch URL [PATH]
svn update
Para aportar a su copia de trabajo local sincronización con la última revisión en el repositorio.
$ svn update
U foo.c
U bar.c
Updated to revision 2.
En este caso, alguien modificó foo.c y bar.c desde la última vez que usted actualizó, y Subversión ha actualizado su copia de trabajo local para incluir estos cambios.
Subcomandos de snvadmin
svnadmin es la herramienta administrativa para monitorizar y reparar su repositorio Subversión.
svnadmin create
Crea un repositorio nuevo vacío.
svnadmin create REPOS_PATH
svnadmin deltify
Deltifica rutas cambiadas en un rango de revisiones.
svnadmin deltify [-r LOWER[:UPPER]] REPOS_PATH
svnadmin dump
Vuelca el contenido de un sistema de ficheros por la salida estándar.
svnadmin dump REPOS_PATH [-r LOWER[:UPPER]] [–incremental]
svnadmin help
svnadmin help [SUBCOMMAND…]
svnadmin hotcopy
Realiza una copia en caliente del repositorio.
svnadmin hotcopy OLD_REPOS_PATH NEW_REPOS_PATH
svnadmin list-dblogs
Pregunta a la base de datos Berkeley qué ficheros de registro existen para un repositorio svn determinado.
svnadmin list-dblogs REPOS_PATH
svnadmin load
Lee un flujo "con formato de volcado" de la entrada estándar.
svnadmin load REPOS_PATH
svnadmin lstxns
Imprime los nombres de todas las transacciones en curso.
svnadmin lstxns REPOS_PATH
svnadmin recover
Recupera cualquier estado perdido en el repositorio.
svnadmin recover REPOS_PATH
svnadmin rmtxns
Elimina transacciones de un repositorio.
svnadmin rmtxns REPOS_PATH TXN_NAME…
svnadmin setlog
Cambia el mensaje de informe de cambios de una revisión.
svnadmin setlog REPOS_PATH -r REVISION FILE
svnadmin verify
Verifica datos almacenados en el repositorio.
svnadmin verify REPOS_PATH
"Version Control whit Subversion" (Biblia de Subversión)
Autor:
Lic. Evelyn Men?ndez Alonso
| Página siguiente |