Ya hemos cubierto en detalle cómo Subversion almacena y recupera varias versiones de ficheros y directorios en sus repositorios. Capítulos enteros han sido dedicados a este trozo fundamental de funcionalidad proporcionada por la herramienta. Y si el soporte de versionado acabase aquí, Subversion seguiría estando completo desde una perspectiva de control de versiones. Pero no acaba aquí.
Además de versionar sus directorios y ficheros, Subversion proporciona una interfaz para añadir, modificar y eliminar meta datos versionados en cada uno de sus directorios y ficheros versionados. Nos referimos a estos meta datos como propiedades, y puede pensar en ellas como tablas de dos columnas que relacionan nombres de propiedades con valores arbitrarios anexos a cada elemento en su copia de trabajo local. En general, los nombres y valores de las propiedades pueden ser cualquier cosa que usted desee, con la restricción de que los nombres sean texto legible por humanos. Y la mejor parte de estas propiedades es que también son versionadas, igual que el contenido textual de sus ficheros. Puede modificar, enviar cambios al repositorio y revertir cambios sobre propiedades tan fácilmente como realiza cambios textuales. Y recibirá las modificaciones de propiedades que otras personas realicen cuando actualice su copia local de trabajo.
En esta sección, examinaremos la utilidad—tanto para usuarios de Subversion como para sí mismo—del soporte de propiedades. Aprenderá los subcomandos svn relacionados con propiedades, y cómo las modificaciones de propiedades pueden afectar a su flujo de trabajo normal con Subversion. Esperamos convencerle de que las propiedades de Subversion pueden mejorar su satisfacción con el control de versiones.
Las propiedades pueden ser adiciones muy útiles a copia de trabajo local. De hecho, Subversion usa para sí mismo propiedades para almacenar información especial, y como modo para indicar que puede ser necesario cierto procesamiento especial. Igualmente, puede usar propiedades para sus propósitos. Por supuesto, cualquier cosa que haga con propiedades puede ser realizada también usando ficheros versionados regulares, pero considere el siguiente ejemplo de uso de propiedades de Subversion.
Digamos que desea diseñar una página web que almacene
muchas fotos digitales, y las muestra con descripciones
y una marca de fecha. Ahora, su conjunto de fotos cambia
constantemente, así que le gustaría tener la mayor parte
posible de la web automatizada. Estas fotos pueden ser
bastante grandes, así que como es habitual en páginas
web de esta naturaleza, desea proporcionar miniaturas
de las imágenes a los visitantes de su web. Puede
hacer esto con ficheros tradicionales. Es decir,
puede tener su imagen123.jpg
y imagen123-miniatura.jpg
uno al lado del otro en un directorio. O si
prefiere tener los mismos nombres, puede tener
las miniaturas en un directorio diferente, como
miniaturas/imagen123.jpg. También
puede almacenar sus descripciones y marcas de fechas del
mismo modo, de nuevo separados del fichero original de
la imagen. Pronto, su árbol de ficheros será un desorden,
y crecerá en múltiplos con cada nueva foto que añada a la
página web.
Ahora considere la misma situación usando las propiedades
de ficheros de Subversion. Imagine tener un único fichero,
imagen123.jpg, y varias propiedades
anexas llamadas descripcion,
marcadetiempo, e incluso
miniatura. Ahora el directorio de su
copia local de trabajo parece más fácil de gestionar—de
hecho, parece que no hay más que ficheros de imágenes. Pero
sus scripts automáticos están preparados. Saben que
pueden usar svn (o incluso mejor,
pueden usar un lenguaje de enlace con Subverion—
vea “Usando lenguajes distintos de C y C++”) para extraer la
información adicional que su página web necesita mostrar
sin tener que leer un fichero índice o jugar manipulando
las rutas de ficheros.
Cómo usar las propiedades de Subversion (si decide usarlas) está en sus manos. Tal y como hemos mencionados, Subversion usa las propiedades para sus propios fines, que discutiremos más tarde en este capítulo. Pero antes, veamos cómo manipular opciones usando el programa svn.
El comando svn tiene la libertad de añadir o modificar propiedades de ficheros y directorios de varias maneras. Para propiedades con valores cortos, legibles por humanos, quizás la forma más simple de añadir una nueva propiedad es especificar el nombre de la propiedad y su valor en la línea de comando con el subcomando propset.
$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c property 'copyright' set on 'calc/button.c' $
Pero hemos estado alabando la
flexibilidad que Subversion ofrece para los valores de sus
propiedades. Y si está planeando tener un valor de propiedad
textual multi línea, o incluso binario, probablemente
no quiera proporcionarlo en la línea de comando. Así
que el subcomando propset acepta el
parámetro --file (-F)
para especificar el nombre de un fichero que contiene el
nuevo valor de una propiedad.
$ svn propset license -F /path/to/LICENSE calc/button.c property 'license' set on 'calc/button.c' $
Además del comando propset, el programa svn proporciona el comando propedit. Este comando usa el programa de edición configurado (vea “Config”) para añadir o modificar propiedades. Cuando ejecuta el comando, svn invoca su programa de edición sobre un fichero temporal que contiene el valor actual de la propiedad (o un fichero vacío, si está añadiendo una nueva propiedad). Entonces, simplemente modifique el valor en su programa de edición hasta que represente el nuevo valor que desea almacenar para la propiedad, guarde el fichero temporal, y salga del programa de edición. Si Subversion detecta que realmente ha modificado el fichero, aceptará esta versión como nuevo valor de la propiedad. Si sale de su programa de edición sin realizar cambios, la propiedad no será modificada.
$ svn propedit copyright calc/button.c ### exit the editor without changes No changes to property 'copyright' on 'calc/button.c' $
Debemos advertirle de que al igual que con otros subcomandos de svn, aquellos relacionados con propiedades pueden actuar sobre varias rutas a la vez. Esto le permite modificar propiedades sobre un conjunto de ficheros con un único comando. Por ejemplo, podríamos haber hecho:
$ svn propset copyright '(c) 2002 Red-Bean Software' calc/* property 'copyright' set on 'calc/Makefile' property 'copyright' set on 'calc/button.c' property 'copyright' set on 'calc/integer.c' … $
Todas estas adiciones y ediciones de propiedades no son realmente muy útiles si no puede recuperar fácilmente el valor almacenado en la propiedad. Así que el programasvn proporciona dos subcomandos para mostrar los nombres y valores de propiedades anexas a ficheros y directorios. El comando svn proplist mostrará un listado de los nombres de las propiedades que existen en una ruta. Una vez conozca el nombre de las propiedades de un nodo, puede solicitar sus valores individualmente usando svn propget. Este comando, dada una ruta (o grupo de rutas) y un nombre de propiedad, imprimirá el valor de la propiedad al flujo estándar de salida.
$ svn proplist calc/button.c Properties on 'calc/button.c': copyright license $ svn propget copyright calc/button.c (c) 2003 Red-Bean Software
Incluso existe una variación del comando
proplist que mostrará tanto
el nombre de todas las propiedad como su valor
command. Simplemente use la opción --verbose
(-v).
$ svn proplist --verbose calc/button.c Properties on 'calc/button.c': copyright : (c) 2003 Red-Bean Software license : ================================================================ Copyright (c) 2003 Red-Bean Software. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the recipe for Fitz's famous red-beans-and-rice. …
El último subcomando que trata con propiedades es propdel. Dado que Subversion le permite almacenar propiedades con valores vacíos, no puede eliminar una propiedad usando propedit o propset. Por ejemplo, este comando no le proporcionará el efecto deseado:
$ svn propset license '' calc/button.c property 'license' set on 'calc/button.c' $ svn proplist --verbose calc/button.c Properties on 'calc/button.c': copyright : (c) 2003 Red-Bean Software license : $
Debe usar el comando propdel para eliminar las propiedades por completo. La sintaxis es similar a la de otros comandos de propiedades:
$ svn propdel license calc/button.c property 'license' deleted from ''. $ svn proplist --verbose calc/button.c Properties on 'calc/button.c': copyright : (c) 2003 Red-Bean Software $
Ahora que está familiarizado con todos los subcomandos de svn relacionados con propiedades, veamos cómo las modificaciones de propiedades afectan al flujo de trabajo habitual de Subversion. Tal y como mencionamos anteriormente, las propiedades de ficheros y directorios están versionadas, igual que los contenidos de los ficheros. Como resultado, Subversion proporciona las mismas oportunidades de fusionar—ya sea de manera limpia o resolviendo conflictos—las modificaciones sobre propiedades de otra persona con las suyas.
Al igual que con los contenidos de sus ficheros, sus cambios sobre propiedades son modificaciones locales, únicamente convertidas en permanentes cuando las envía al repositorio con svn commit. También puede deshacer fácilmente sus cambios—el comando svn revert recuperará sus ficheros y directorios a su estado no modificado, contenido, propiedades, y todo lo demás. Además, puede recibir información interesante sobre el estado de las propiedades de sus ficheros y directorios usando los comandos svn status y svn diff.
$ svn status calc/button.c M calc/button.c $ svn diff calc/button.c Property changes on: calc/button.c ___________________________________________________________________ Name: copyright + (c) 2003 Red-Bean Software $
Fíjese cómo el subcomando status
muestra una M en la segunda columna
en lugar de la primera. Esto es porque hemos modificado
propiedades de calc/button.c, pero no
hemos modificado su contenido. De haber cambiado ambos,
habríamos visto también una M en la
primera columna (vea “svn status”).
Quizás también se haya dado cuenta del modo no estándar usado por Subversion para mostrar las diferencias entre propiedades. Todavía puede ejecutar svn diff y redirigir la salida para crear un fichero parche usable. El programa patch ignorará los parches de propiedades—como regla general, ignora cualquier ruido que no es capaz de entender. Esto significa desafortunadamente que para aplicar completamente un parche generado por svn diff, cualquier modificación de propiedades deberá ser aplicada a mano.
Como puede ver, la presencia de modificaciones de propiedades no tiene efectos significativos en el flujo de trabajo típico con Subversion. Sus patrones generales de actualizar su copia local, verificar el estado de sus ficheros y directorios, obtener informes sobre las modificaciones realizadas, y enviar éstas al repositorio son completamente inmunes a la presencia o ausencia de propiedades. El programa svn tiene algunos subcomandos adicionales para efectuar cambios de propiedades, pero esto es la única asimetría notable.
Subversion no tiene reglas particulares sobre
propiedades—puede usarlas para cualquier
fin. Subversion sólo le pide que no use nombres
de propiedades que comiencen con el prefijo
svn:. Ese es el espacio de nombres que
reserva para uso propio. De hecho, Subversion define ciertas
propiedades que tienen efectos mágicos sobre ficheros y
directorios. En esta sección, desvelaremos el misterio,
y describiremos cómo estas propiedades especiales pueden
hacerle la vida un poco más fácil.
La propiedad svn:executable se
usa para controlar de un modo semi automático el bit
de permiso de ejecución de un fichero versionado.
Esta propiedad no tiene valor definido—su mera
presencia indica el deseo de que el bit de permiso de
ejecución se mantenga activado por Subversion. Eliminar
esta propiedad devolverá el control total del bit de
ejecución al sistema operativo.
En muchos sistemas operativos, la capacidad de ejecutar
un fichero o comando es gobernada por la presencia de un
bit de permiso de ejecución. Éste suele estar desactivado
por defecto, y debe ser activado de forma explícita
por el usuario para cada fichero que lo requiera. En
una copia de trabajo local, se crean nuevos ficheros
constantemente a medida que nuevas versiones de ficheros
existentes son recibidas durante una actualización. Esto
significa que quizás active el bit de ejecución en un
fichero, entonces actualice su copia de trabajo, y si ese
fichero fue modificado como parte de la actualización,
su bit de ejecución puede haber sido desactivado. Así que Subversion proporciona la propiedad
svn:executable para mantener el bit de
ejecución activado.
Esta propiedad no tiene efecto en sistemas de ficheros
que no tienen concepto de bits de permiso de ejecución,
como FAT32 y NTFS.
[36]
Además, aunque no tenga valores definidos, Subversion
forzará el valor a * cuando ajuste
esta propiedad. Finalmente, esta propiedad es únicamente
válida en ficheros, no en directorios.
La propiedad svn:mime-type tiene
varios propósitos en Subversion. Aparte de ser el
lugar genérico para almacenar la clasificación
de extensión polivalente de correo por Internet
(MIME[37]), el
valor de esta propiedad determina algunas características
del comportamiento de Subversion.
Por ejemplo, si la propiedad
svn:mime-type de un fichero tiene un
valor de tipo MIME no textual (generalmente, algo que no
comienza con text/, aunque hay algunas
excepciones), Subversion asumirá que el fichero contiene
datos binarios—es decir, no legibles por un ser
humano. Uno de los beneficios habitualmente proporcionado
por Subversion es el fusionado contextual, basado en
líneas, de los cambios recibidos del servidor durante una
actualización de su fichero de la copia local. Pero para
los ficheros que se considera contienen datos binarios,
no existe el concepto de una “línea”. Así
que para esos ficheros, Subversion no intenta realizar un
fusionado contextual durante la actualización. En su lugar,
siempre que tenga un fichero binario en su copia local
que esté siendo actualizado, su fichero es renombrado
con la extensión .orig, y entonces
Subversion almacena un nuevo fichero que contiene los
cambios recibidos durante la actualización, pero sin sus
modificaciones locales, con el nombre de fichero original.
Este comportamiento es realmente una protección para el
usuario contra intentos fallidos de realizar fusionados
contextuales sobre ficheros que simplemente no pueden ser
fusionados contextualmente.
Además, si la propiedad
svn:mime-type está ajustada, entonces el
módulo Subversion de Apache usará su valor para rellenar
la cabecera HTTP Content-type: cuando
responda peticiones GET. Esto proporciona una pista vital
sobre cómo mostrar un fichero cuando examina su repositorio
con un navegador web.
La propiedad svn:ignore contiene
una lista de patrones de ficheros que serán excluidos por
ciertas operaciones de Subversion. Quizás la propiedad
especial usada con mayor frecuencia, funciona junto con el
parámetro de ejecución global-ignores
(vea “Config”) para filtrar
ficheros y directorios no versionados con los comandos
svn status, svn add,
y svn import.
La razón tras la propiedad
svn:ignore es fácil de explicar.
Subversion no asume que todo fichero o subdirectorio de una
copia de trabajo local está destinado a ser puesto bajo
control de versiones. Los recursos deben ser asignados
explícitamente bajo la gestión de Subversion usando
los comandos svn add o svn
import. Como resultado, con frecuencia
muchos recursos en una copia local de trabajo no están
versionados.
Ahora, el comando svn status
muestra como parte de su salida cada fichero o
subdirectorio en la copia local de trabajo que no está
filtrado por la opción global-ignores
(o su valor por defecto). Esto se hace así para que los
usuarios puedan ver si quizás han olvidado poner un recurso
bajo control de versiones.
Pero Subversion es incapaz de adivinar los nombres de cada recurso que debe ser ignorado. Además, a menudo hay cosas que deberían ser ignoradas en cada copia local de trabajo de un repositorio particular. Obligar a cada usuario del repositorio a que añada patrones para estos recursos a sus áreas de configuración de parámetros de ejecución no sólo sería un incordio, sino que podría entrar en conflicto con las necesidades de configuración de otras copias locales de trabajo que el usuario ha obtenido.
La solución es almacenar los patrones de exclusión que son únicos del directorio donde deben ser aplicados junto con el propio directorio. Ejemplos habituales de recursos no versionados que son básicamente únicos de cada directorio, y propensos a aparecer ahí, son ficheros generados por la compilación de programas. O—para usar un ejemplo más apropiado para este libro—los ficheros HTML, PDF o PostScript generados como resultado de la conversión de los ficheros fuente XML DocBook a un formato de salida más legible.
Para este propósito, la propiedad
svn:ignore es la solución. Su valor es
un conjunto multi línea de patrones de ficheros, un patrón
por línea. La propiedad se activa en el directorio donde
quiere que los patrones sean aplicados.
[38]
Por ejemplo, digamos que obtiene la siguiente salida
svn status:
$ svn status calc M calc/button.c ? calc/calculator ? calc/data.c ? calc/debug_log ? calc/debug_log.1 ? calc/debug_log.2.gz ? calc/debug_log.3.gz
En este ejemplo, ha realizado algunas modificaciones
de propiedades sobre button.c,
pero en su copia local de trabajo también tiene algunos
ficheros sin versionar: la última versión del programa
calculator que ha compilado del
código fuente, un fichero de código fuente llamado
data.c, y un conjunto de ficheros
de depuración. Ahora, ya sabe que su sistema de compilado
siempre acaba generando el programa
calculator.
[39]
Y sabe que el conjunto de sus unidades de verificación
siempre acaban dejando ficheros de depuración en el
directorio. Estos hechos son ciertos para todas las copias
de trabajo, no sólo la suya. Y sabe que no está interesado
en ver estas cosas cada vez que ejecute svn
status. Así que use svn propedit
svn:ignore calc para añadir algunos patrones
de exclusión al directorio calc.
Por ejemplo, podría añadir lo siguiente como nuevo valor
de la propiedad svn:ignore:
calculator debug_log*
Tras añadir esta propiedad, ahora tendrá una modificación
local de propiedad en el directorio calc.
Pero advierta qué otras cosas son diferentes sobre la salida
del comando
svn status:
$ svn status M calc M calc/button.c ? calc/data.c
¡Ahora, los despojos no entorpecen el listado! Por supuesto, esos ficheros aun están en su copia local de trabajo. Subversion únicamente no le está recordando que están presentes y no versionados. Y ahora tras haber eliminado todo el ruido trivial del listado, se encuentra con elementos más interesantes—como por ejemplo el fichero de código fuente que probablemente olvidó poner bajo control de versiones.
Si quiere ver los ficheros ignorados, puede pasar el parámetro --no-ignore a subversion:
$ svn status --no-ignore M calc/button.c I calc/calculator ? calc/data.c I calc/debug_log I calc/debug_log.1 I calc/debug_log.2.gz I calc/debug_log.3.gz
La lista de patrones a excluir también es usada por svn add y svn import. Ambas de estas operaciones conllevan preguntar a Subversion que comience a gestionar algún conjunto de ficheros y directorios. En lugar de forzar al usuario que escoja qué ficheros de un árbol desea comenzar a versionar, Subversion usa los patrones de exclusión para determinar qué ficheros no deberían ser arrastrados bajo control de versiones durante grandes adiciones recursivas u operaciones de importación.
Subversion tiene la capacidad de sustituir palabras clave—trozos dinámicos de información útil sobre un fichero versionado—en el contenido de los propios ficheros. Las palabras clave generalmente describen información sobre la última vez que el fichero fue modificado. Dado que esta información cambia cada vez que el fichero es modificado, y más importante aun, justo después de la modificación, es tarea difícil para todo proceso excepto el sistema de control de versiones, mantener los datos completamente actualizados. Si esta tarea fuese delegada en los autores humanos, la información inevitablemente quedaría desfasada.
Por ejemplo, digamos que posee un documento en el cual le
gustaría mostrar la última fecha en la que fue
modificado. Podría obligar a cada autor de ese documento
a que, justo antes de enviar sus cambios al repositorio,
también modifiquen la parte del documento que describe
la última fecha de modificación. Pero tarde o temprano,
alguien se olvidará de hacer eso. En su lugar, indique a
Subversion que realice la sustitución de la palabra clave
LastChangedDate. Puede controlar
el lugar donde figura esta palabra clave colocando
una marca de palabra clave
en el lugar apropiado del fichero. Esta marca no
es más que una cadena de texto formateada como
$PalabraClave$.
Subversion una lista de palabras clave disponibles para ser sustituidas. Esta lista contiene las cinco siguientes palabras clave, algunas de las cuales tienen sinónimos más cortos que también puede usar:
LastChangedDate
Esta palabra clave describe el último momento en
que el fichero fue modificado en el repositorio, y tiene
el aspecto $LastChangedDate: 2002-07-22 21:42:37
-0700 (Mon, 22 Jul 2002) $. Puede ser abreviada
como Date.
LastChangedRevision
Esta palabra clave describe la última revisión
conocida en la que este fichero fue
modificado en el repositorio, y tiene el aspecto
$LastChangedRevision: 144 $. Puede
ser abreviada como Revision o
Rev.
LastChangedBy
Esta palabra clave describe el último usuario conocido
que modificó este fichero en el repositorio, y tiene
el aspecto $LastChangedBy: juan $.
Puede ser abreviada como Author.
HeadURL
Esta palabra clave describe la URL completa a la
última versión de este fichero en el
repositorio, y tiene el aspecto $HeadURL:
http://svn.collab.net/repos/trunk/README $.
Puede ser abreviada como URL.
Id
Esta palabra clave es una combinación comprimida
de las otras palabras clave. Su sustitución tiene
el aspecto $Id: calc.c 148 2002-07-28
21:30:43Z carmen $, y su interpretación
indica que el fichero calc.c
fue modificado por última vez en la revisión 148
de la tarde del 28 de Julio del 2002 por el usuario
carmen.
Añadir únicamente la marca con la palabra clave a su fichero no hace nada especial. Subversion nunca intentará realizar sustituciones textuales en sus ficheros a no ser que usted lo pida explícitamente. Después de todo, quizás esté escribiendo un documento [40] sobre cómo usar palabras clave, ¡y no desea que Subversion sustituya sus bonitos ejemplos de marcas de palabras claves no sustituidas!
Para indicar a Subversion si desea o no sustituir palabras
clave en un fichero particular, de nuevo volvemos a usar
los subcomandos relacionados con propiedades. La propiedad
svn:keywords, una vez activada en un fichero
versionado, controla qué palabras clave serán sustituidas. El
valor es una lista delimitada por espacios con las palabras
clave o sinónimos de la tabla anterior.
Por ejemplo, digamos que tiene un fichero llamado
weather.txt que tiene el siguiente
aspecto:
Here is the latest report from the front lines. $LastChangedDate$ $Rev$ Cumulus clouds are appearing more frequently as summer approaches.
Sin haber activado la propiedad
svn:keywords en ese fichero, Subversion
no hará nada especial. Ahora, activemos la sustitución de la
palabra clave LastChangedDate.
$ svn propset svn:keywords "LastChangedDate Author" weather.txt property 'svn:keywords' set on 'weather.txt' $
Ahora acaba de realizar una modificación local de propiedad
sobre el fichero weather.txt. No verá
cambios en el contenido del fichero (a no ser que haya realizado
algunos antes de activar la propiedad). Fíjese que el fichero
contenía la marca de la palabra clave Rev,
y no obstante no incluimos esta palabra clave en el valor de
la propiedad. Subversion ignorará felizmente peticiones para
sustituir palabras clave que no están presentes en el fichero,
y no sustituirá palabras clave que no están presentes en el
valor de la propiedad svn:keywords.
Inmediatamente después de que envíe al repositorio la
modificación de esta propiedad, Subversion actualizará
la copia local de su fichero con el nuevo texto
sustituido. En lugar de ver su marca de palabra clave
$LastChangedDate$, verá el resultado de
su sustitución. El resultado también contendrá el nombre de
la palabra clave, y continuará estando rodeado por caracteres
de dólar ($). Y tal y como predijimos,
la palabra clave Rev no fue sustituida
porque no solicitamos hacerlo.
Here is the latest report from the front lines. $LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $ $Rev$ Cumulus clouds are appearing more frequently as summer approaches.
Si alguna otra persona envía al repositorio cambios sobre
el fichero weather.txt, su copia de ese
fichero continuará mostrando el mismo valor de la sustitución de
la palabra clave—hasta que actualice su copia de trabajo
local. Durante ese instante las palabras clave de su fichero
weather.txt serán re-sustituidas para
reflejar la información más reciente de ese fichero enviada
al repositorio.
Mientras la propiedad svn:mime-type
de un fichero versionado no indique lo contrario,
Subversion asume que el fichero contiene datos legibles
por seres humanos. En general, Subversion sólo usa
este conocimiento para determinar si se pueden realizar
ficheros diferenciales contextuales sobre el fichero.
En caso contrario, para Subversion, los bytes son
bytes.
Esto significa que por defecto, Subversion no
presta atención al tipo de marcas de fin de
línea (EOL) que use en sus ficheros.
Desafortunadamente, diferentes sistemas operativos
usan caracteres diferentes para representar los fines
de línea en un fichero de texto. Por ejemplo, el carácter
de fin de línea habitual usado por software en la
plataforma Windows es una pareja de caracteres de
control ASCII —retorno de carro (CR)
y nueva línea
(LF). En su lugar, el software
Unix usa simplemente el carácter LF
para indicar nueva línea.
No todas las herramientas en estos sistemas
operativos están preparadas para entender ficheros
en formatos que difieran del estilo de fin
de línea nativo del sistema operativo
sobre el cual están corriendo. Los resultados habituales
son que los programas Unix tratan el carácter
CR presente en ficheros Windows
como caracteres regulares (normalmente mostrados como
^M), y los programas Windows
combinan todas las líneas de un fichero Unix en una
línea gigante porque no encuentran la combinación de
retorno de carro y nueva línea (o CRLF)
que marca el fin de línea.
Esta sensibilidad a marcas EOL extrañas puede resultar frustrante para quienes comparten un fichero en múltiples sistemas operativos diferentes. Por ejemplo, considere un fichero de código fuente y desarrolladores que modifiquen este fichero tanto en Windows como en Unix. Si todos los desarrolladores usan herramientas que preservan el estilo de fin de línea del fichero, no ocurrirán problemas.
Pero en la práctica, muchas herramientas comunes o bien fallan al leer un fichero con marcas EOL extrañas, o bien convierten los finales de línea al estilo nativo cuando el fichero es guardado. Si lo primero es cierto para un desarrollador, tendrá que usar una utilidad de conversión externa (como por ejemplo dos2unix o su compañera, unix2dos) para preparar el fichero antes de modificarlo. En el segundo caso no hace falta preparación adicional. ¡Pero en ambos casos el resultado es un fichero que difiere del origen al en todas y cada una de las líneas! Antes de enviar sus cambios al repositorio, el usuario tiene dos opciones. O bien usa una utilidad de conversión para recuperar el estilo de línea que tenía el fichero antes de ser modificado. O, simplemente puede enviar sus cambios—con nuevas marcas EOL y todo.
El resultado de este tipo de escenarios incluyen tiempo perdido en modificaciones innecesarias sobre ficheros enviados al repositorio. Perder tiempo ya es doloroso. Pero cuando un cambio modifica toda línea del fichero, esto complica el trabajo de determinar qué lineas realmente cambiaron de un modo poco trivial . ¿Fue el fallo realmente corregido? ¿En qué línea se introdujo un error de sintaxis?
La solución a este problema es la propiedad
svn:eol-style. Cuando se ajusta
esta propiedad a un valor válido, Subversion la usa
para determinar si tiene que realizar un proceso
especial sobre el fichero para que los finales de
línea del fichero no bailen como un flip-flop con
cada cambio enviado al repositorio proveniente de un
sistema operativo diferente. Los valores válidos
son:
native
Esto provoca que el fichero contenta marcas EOL
nativas del sistema operativo en que fue
ejecutado Subversion. En otras palabras.
si un usuario de Windows obtiene una copia local
de un fichero cuya propiedad
svn:eol-style contenga el valor
native, ese fichero contendrá
marcas EOL CRLF. Un usuario de
Unix que obtenga una copia local del mismo fichero
verá marcas EOL LF.
Tenga en cuenta que Subversion en realidad
almacenará el fichero en el repositorio usando
marcas EOL LF normalizadas
sin importar el sistema operativo. No obstante,
esto es básicamente transparente para el
usuario.
CRLF
Esto provoca que el fichero contenga la secuencia
CRLF como marcas EOL, sin importar
el sistema operativo usado.
LF
Esto provoca que el fichero contenga el carácter
LF como marca EOL, sin importar
el sistema operativo usado.
CR
Esto provoca que el fichero contenga el carácter
CR como marca EOL, sin importar
el sistema operativo usado. Este estilo de fin de
línea no es muy habitual. Fue usado en plataformas
Macintosh antiguas (en las cuales Subversion ni si
quiera funciona).
La propiedad svn:externals contiene
instrucciones para Subversion de poblar el directorio
con una o más copias locales de trabajo de Subversion.
Para más información sobre esta propiedad y sus usos,
vea “Repositorios externos”.
Las propiedades son una poderosa característica de Subversion, actuando como componentes clave de muchas características de Subversion descritas en este y otros capítulos—soporte de diferenciado de ficheros y fusión textual, sustitución de palabras clave, traducción de fines de línea, etc. Pero para obtener por completo sus beneficios, debe ajustarlas en los ficheros y directorios adecuados. Desafortunadamente, este paso puede ser fácilmente olvidado en la rutina, especialmente dado que olvidar ajustar una propiedad normalmente no se traduce en una condición de error obvia (al menos si la compara, con digamos, olvidar añadir un fichero al repositorio). Para ayudar a sus propiedades a que sean aplicadas en los lugares necesarios, Subversion proporciona un par de características simples pero útiles.
Siempre que pone un fichero bajo control de revisiones
usando los comandos svn add o
svn import, Subversion ejecuta una
heurística básica para determinar si el fichero se
compone de contenido legible o no legible por un ser
humano. Si decide lo último, Subversion ajustará
automáticamente la propiedad svn:mime-type
de ese fichero a application/octet-stream
(el tipo MIME genérico “esto es un grupo de
bytes”). Por supuesto, si Subversion no acierta,
puede ajustar la propiedad svn:mime-type
a otro valor más concreto—quizás
image/png o
application/x-shockwave-flash—siempre
puede eliminar o modificar esta propiedad.
Subversion también proporciona la característica de
auto propiedades, las cuales le permiten crear una
relación de patrones de ficheros a nombres y valores
de propiedades. Estas relaciones son creadas en su
área de parámetros de ejecución. De nuevo, éstos afectan
a adiciones e importaciones, y no sólo pueden sobreescribir
cualquier tipo de decisión MIME por defecto tomada por
Subversion, también pueden ajustar otras propiedades
propias o de Subversion. Por ejemplo, podría crear una
relación que dice que cada vez que añada ficheros
JPEG—aquellos que coincidan con el patrón
*.jpg—Subversion debería ajustar
automáticamente la propiedad svn:mime-type
de esos ficheros a image/jpeg. O
quizás cualquier fichero que coincida con
*.cpp debería tener la propiedad
svn:eol-style ajustada a
native, y svn:keywords
ajustada a Id. El soporte de
propiedades automáticas es quizás la herramienta de
Subversion más útil en cuanto a propiedades. Vea “Config” para más información
sobre cómo configurar esta característica.
[35] Corregir faltas ortográficas, errores gramaticales,
y “simplemente-cosas-incorrectas”
en el mensaje del informe de cambios es quizás
el caso de uso más habitual para la opción
--revprop.
[36] El sistema de ficheros de Windows usa extensiones
de ficheros (como .EXE,
.BAT, y .COM)
para indicar que un fichero es ejecutable.
[37] N.T.: “Multipurpose Internet Mail Extension” en inglés.
[38] Los patrones únicamente funcionarán en ese directorio—no serán aplicados de forma recursiva en subdirectorios.
[39] ¿No es este acaso el propósito de un sistema de compilación?
[40] … o quizás incluso una sección de un libro …