Uso de herramientas de diferenciación externa y de combinación La interfaz entre Subversion y las herramientas de diferenciación externas de dos y tres vías se remonta a una época en que las capacidades de diferenciación contextual de Subversion se construían alrededor de las invocaciones de la cadena de herramientas diffutils de GNU, específicamente las utilidades diff y diff3. Para obtener el tipo de comportamiento que Subversion necesitaba, llamó a estas utilidades con más de un puñado de opciones y parámetros, la mayoría de los cuales eran bastante específicos para las utilidades. Un tiempo después, Subversion creó su propia biblioteca de diferenciación interna y, como mecanismo de conmutación por error, las opciones --diff-cmd y - diff3-cmd se agregaron al cliente de línea de comandos de Subversion para que los usuarios pudieran indicar más fácilmente que preferían Para usar las utilidades diff y diff3 de GNU en lugar de la biblioteca de diferencias internas newfangled. Si se usaban esas opciones, Subversion simplemente ignoraría la biblioteca interna de diferencias y volvería a ejecutar esos programas externos, listas de argumentos largos y todo. Y eso es donde las cosas siguen siendo hoy. No tardó mucho tiempo para gente para darse cuenta de que tener tales mecanismos fáciles de la configuración para especificar que Subversion debe utilizar el external GNU diff y las utilidades del diff3 situadas en un lugar particular en el sistema se podrían aplicar hacia el uso de otras herramientas de la diferenciación, también. Después de todo, Subversion realmente no verificó que las cosas que se estaba diciendo que ejecutaban eran miembros de la cadena de herramientas GNU diffutils. Pero el único aspecto configurable de usar esas herramientas externas es su ubicación en el sistema, no el conjunto de opciones, el orden de los parámetros, etc. Subversion continúa lanzando todas esas opciones de utilidad GNU en su herramienta de dif externa independientemente de si ese programa puede entender esas opciones. Y eso es donde las cosas no son intuitivas para la mayoría de los usuarios. La decisión sobre cuándo disparar una diferencia contextual de dos o tres vías como parte de una operación Subversion más grande es hecha enteramente por Subversion y se ve afectada, entre otras cosas, si los archivos que se están operando son legibles por el ser humano según lo determinado por Su propiedad svn: mime-type. Esto significa, por ejemplo, que incluso si tuviera la mejor herramienta de diferenciación o combinación de Microsoft Word en el universo, nunca sería invocada por Subversion siempre y cuando sus documentos versionados de Word tuvieran un tipo MIME configurado que denotaba que no eran Legible por humanos (como application / msword). Mucho más tarde, Subversion 1.5 introdujo la resolución interactiva de conflictos (descrita en la sección llamada Resolver conflictos). Una de las opciones que esta característica proporciona a los usuarios es la capacidad de iniciar de forma interactiva una herramienta de combinación de tercero. Si se realiza esta acción, Subversion verificará si el usuario ha especificado una herramienta para usar de esta manera. Subversion verificará primero la variable de entorno SVNMERGE para el nombre de una herramienta de combinación externa. Si no se establece esta variable, buscará la misma información en el valor de la opción de configuración de tiempo de ejecución merge-tool-cmd. Al encontrar una herramienta de fusión externa configurada, invocará esa herramienta. Si bien los propósitos generales de las herramientas de diferenciación y combinación de tres vías son más o menos los mismos (encontrar una forma de hacer que los cambios de archivo independientes pero superpuestos vivan en armonía), Subversion ejerce cada una de estas opciones en diferentes momentos y por diferentes razones. El motor interno de diferenciación de tres vías y su sustitución externa opcional se utilizan cuando no se espera interacción con el usuario. De hecho, el retraso significativo introducido por una herramienta de este tipo puede resultar en el fracaso de algunas operaciones Subversion sensibles al tiempo. Es la herramienta de fusión externa que está destinada a ser invocada de forma interactiva. Ahora, mientras que la interfaz entre Subversion y una herramienta de fusión externa es significativamente menos complicada que la que existe entre Subversion y las herramientas diff y diff3, la probabilidad de encontrar tal herramienta cuyas convenciones de llamada coincidan exactamente con lo que Subversion espera es todavía bastante baja. La clave para usar herramientas de diferenciación externa y de combinación con Subversion es utilizar scripts de wrapper, que convierten la entrada de Subversion en algo que su herramienta de diferenciación específica puede entender y luego convertir la salida de la herramienta en un formato que Subversion espera. Las siguientes secciones cubren las especificidades de esas expectativas. Diferencia externa Subversion llama a programas de dif externos con parámetros adecuados para la utilidad de dif de GNU, y sólo espera que el programa externo regrese con un código de error exitoso según la definición de diff de GNU. Para la mayoría de los programas de difición alternativos, sólo el sexto y el séptimo argumentan los caminos de los archivos que representan los lados izquierdo y derecho del diff, respectivamente, son de interés. Tenga en cuenta que Subversion ejecuta el programa diff una vez por archivo modificado cubierto por la operación Subversion, por lo que si su programa se ejecuta de manera asíncrona (o está en segundo plano), es posible que tenga varias instancias de que todo se ejecute simultáneamente. Finalmente, Subversion espera que su programa devuelva un código de error de 1 si su programa detectó diferencias, o 0 si no cualquier otro código de error se considera un error fatal. 63 Ejemplo 7.2, diffwrap. py y Ejemplo 7.3, diffwrap. bat son plantillas para wrappers externos de herramientas de dif en los lenguajes de scripts por lotes Python y Windows, respectivamente. Ejemplo 7.2. Diffwrap. pyProperties Ya hemos cubierto en detalle cómo Subversion almacena y recupera varias versiones de archivos y directorios en su repositorio. Capítulos enteros se han dedicado a esta pieza fundamental de funcionalidad proporcionada por la herramienta. Y si el soporte de versiones se detuvo allí, Subversion aún estaría completo desde una perspectiva de control de versiones. Pero no se detiene allí. Además de versiones de sus directorios y archivos, Subversion proporciona interfaces para agregar, modificar y eliminar metadatos versionados en cada uno de sus directorios y archivos versionados. Nos referimos a estos metadatos como propiedades. Y se pueden considerar como tablas de dos columnas que asignan nombres de propiedades a valores arbitrarios adjuntos a cada elemento de su copia de trabajo. En general, los nombres y valores de las propiedades pueden ser lo que quieras que sean, con la restricción de que los nombres deben contener sólo caracteres ASCII. Y la mejor parte de estas propiedades es que también, se versionan, al igual que el contenido textual de sus archivos. Puede modificar, validar y revertir cambios de propiedad tan fácilmente como pueda cambiar el contenido del archivo. Y el envío y la recepción de los cambios de propiedad se produce como parte de su típico commit y actualizar operaciones que no tienen que cambiar sus procesos básicos para dar cabida a ellos. Subversion ha reservado el conjunto de propiedades cuyos nombres comienzan con svn: como propio. Aunque sólo hay un puñado de estas propiedades en uso hoy en día, debe evitar la creación de propiedades personalizadas para sus propias necesidades cuyos nombres comienzan con este prefijo. De lo contrario, se corre el riesgo de que una versión futura de Subversion crezca el soporte para una característica o comportamiento impulsado por una propiedad del mismo nombre, pero quizás con una interpretación completamente diferente. Las propiedades también aparecen en Subversion. Así como los archivos y directorios pueden tener nombres de propiedad y valores arbitrarios asociados a ellos, cada revisión como un todo puede tener propiedades arbitrarias asociadas a ella. Las mismas restricciones se aplican a los nombres legibles por el hombre ya cualquier cosa que desee valores binarios. La principal diferencia es que las propiedades de revisión no están versionadas. En otras palabras, si cambia el valor de, o elimina, una propiedad de revisión, no hay manera, dentro del alcance de la funcionalidad de Subversions, para recuperar el valor anterior. Subversion no tiene una política particular con respecto al uso de propiedades. Sólo le pide que no utilice nombres de propiedades que comiencen con el prefijo svn: como thats el espacio de nombres que pone a un lado para su propio uso. Y Subversion, de hecho, usa propiedades tanto la versión versionada como la no versionada. Algunas propiedades versionadas tienen un significado o efectos especiales cuando se encuentran en archivos y directorios, o alojan un poco de información sobre las revisiones en las que se encuentran. Ciertas propiedades de revisión se asocian automáticamente a las revisiones del proceso de confirmación de Subversions y llevan información sobre la revisión. La mayoría de estas propiedades se mencionan en otra parte de este u otros capítulos como parte de los temas más generales a los cuales están relacionados. Para obtener una lista exhaustiva de las propiedades predefinidas de Subversions, consulte la sección Subversion Properties en el Capítulo 9, Subversion Complete Reference. Si bien Subversion asigna automáticamente propiedades a las revisiones (svn: date, svn: author, svn: log, etc.), no presupone la existencia de esas propiedades y ni tú ni las herramientas que usas para interactuar con tu repositorio . Las propiedades de revisión se pueden eliminar mediante programación o mediante el cliente (si los ganchos del repositorio lo permiten) sin dañar la capacidad de Subversions de funcionar. Por lo tanto, al escribir scripts que operan en sus datos de repositorio de Subversion, no cometa el error de suponer que existe alguna propiedad de revisión en particular en una revisión. En esta sección, examinaremos la utilidad tanto para los usuarios de Subversion como para Subversion mismo del soporte de propiedad. Aprenderá sobre los subcomandos svn relacionados con la propiedad y cómo las modificaciones de propiedades afectarán a su flujo de trabajo normal de Subversion. Propiedades Al igual que Subversion utiliza propiedades para almacenar información adicional sobre los archivos, directorios y revisiones que contiene, también puede encontrar propiedades que sean de uso similar. Puede ser útil tener un lugar cercano a los datos versionados para colgar metadatos personalizados sobre esos datos. Digamos que desea diseñar un sitio web que alberga muchas fotos digitales y las muestra con subtítulos y una fecha. Ahora, su conjunto de fotos está cambiando constantemente, por lo que le gustaría tener tanto de este sitio automatizado como sea posible. Estas fotos pueden ser muy grandes, por lo que es común con los sitios de esta naturaleza, que desea proporcionar imágenes en miniatura más pequeñas a los visitantes del sitio. Ahora, puede obtener esta funcionalidad utilizando archivos tradicionales. Es decir, puede tener su image123.jpg y una imagen123-thumbnail. jpg lado a lado en un directorio. O si desea mantener los nombres de archivo iguales, es posible que tenga sus miniaturas en un directorio diferente, como miniaturas / image123.jpg. También puede almacenar sus subtítulos y fechas de una manera similar, de nuevo separados del archivo de imagen original. Pero el problema aquí es que su colección de archivos se multiplica con cada nueva foto agregada al sitio. Ahora considere el mismo sitio web implementado de una manera que hace uso de las propiedades del archivo Subversions. Imagine tener un solo archivo de imagen, image123.jpg. Con propiedades definidas en ese archivo que se llaman subtítulo. sello de la fecha. E incluso la miniatura. Ahora su directorio de copia de trabajo se ve mucho más manejable de hecho, se ve en el navegador casual como no hay nada, pero los archivos de imagen en él. Pero sus scripts de automatización saben mejor. Ellos saben que pueden usar svn (o mejor aún, pueden usar las vinculaciones del lenguaje Subversion para ver la sección llamada Using the APIs) para extraer la información adicional que su sitio necesita para mostrar sin tener que leer un archivo de índice o jugar juegos de manipulación de rutas . Aunque Subversion coloca pocas restricciones en los nombres y valores que usa para las propiedades, no ha sido diseñada para llevar óptimamente valores de propiedad grandes o conjuntos grandes de propiedades en un archivo o directorio determinado. Subversion comúnmente contiene todos los nombres de propiedad y valores asociados con un solo elemento en la memoria al mismo tiempo, lo que puede causar un rendimiento perjudicial o las operaciones fallidas cuando se utilizan conjuntos de propiedades extremadamente grandes. También se utilizan frecuentemente propiedades de revisión personalizadas. Un uso común de este tipo es una propiedad cuyo valor contiene un identificador de seguimiento de problemas con el que está asociada la revisión, tal vez porque el cambio realizado en esa revisión corrige un error archivado en el problema del rastreador con ese ID. Otros usos incluyen colgar nombres más amigables en la revisión. Puede ser difícil recordar que la revisión 1935 fue una revisión completamente probada. Pero si hay, por ejemplo, una propiedad de resultados de prueba en esa revisión con el valor de todos los que pasan. Esa es una información significativa que tener. Y Subversion le permite hacerlo fácilmente a través de la opción --with-revprop del comando svn commit: Searchability (o, Why Not Properties) Para toda su utilidad, propiedades de Subversion o, con mayor precisión, las interfaces disponibles para themhave una deficiencia importante: Mientras que es una cuestión sencilla para establecer una propiedad personalizada, encontrando que la propiedad más tarde es una bola totalmente diferente de cera. Tratar de localizar una propiedad de revisión personalizada generalmente implica realizar un paseo lineal a través de todas las revisiones del repositorio, preguntando por cada revisión, ¿Tiene la propiedad que busco? Utilice la opción --with-all-revprops con los comandos svn log XML Salida para facilitar esta búsqueda. Observe la presencia de los resultados de prueba de la propiedad de revisión personalizada en la siguiente salida: Tratar de encontrar una propiedad versionada personalizada es doloroso, y con frecuencia implica un propc svn recursivo en toda una copia de trabajo. En su situación, que podría no ser tan malo como un paso lineal a través de todas las revisiones. Pero ciertamente deja mucho que desear en términos de rendimiento y probabilidad de éxito, especialmente si el alcance de su búsqueda requiere una copia de trabajo de la raíz de su repositorio. Por esta razón, puede elegir especialmente en el uso de la propiedad de revisión, simplemente agregue sus metadatos al mensaje de registro de revisiones usando algún formato orientado a directivas (y tal vez programado) que está diseñado para ser analizado rápidamente a partir de la salida de svn log. Es bastante común ver lo siguiente en los mensajes de registro de Subversion: Pero aquí también reside alguna desgracia. Subversion todavía no proporciona un mecanismo de templating de mensajes de registro, lo cual ayudaría mucho a los usuarios a ser consistentes con el formato de sus metadatos de revisión incorporados en el registro. Manipulación de propiedades El programa svn ofrece algunas maneras de agregar o modificar propiedades de archivos y directorios. Para propiedades con valores cortos y legibles por el usuario, quizás la forma más sencilla de agregar una nueva propiedad es especificar el nombre de la propiedad y el valor en la línea de comandos del subcomando svn propset: Pero hemos estado promocionando la flexibilidad que Subversion ofrece para los valores de su propiedad . Y si está planeando tener un valor de propiedad multilínea textual, o incluso binario, es probable que no desee suministrar ese valor en la línea de comandos. Así, el subcomando svn propset toma una opción --file (-F) para especificar el nombre de un archivo que contiene el nuevo valor de la propiedad. Hay algunas restricciones sobre los nombres que puede utilizar para las propiedades. Un nombre de propiedad debe comenzar con una letra, dos puntos (.) O un guión bajo () después de eso, también puede usar dígitos, guiones (-) y puntos (.). 13 Además del comando propset, el programa svn suministra el comando propedit. Este comando utiliza el programa de editor configurado (consulte la sección Config) para agregar o modificar propiedades. Cuando ejecuta el comando, svn invoca su programa editor en un archivo temporal que contiene el valor actual de la propiedad (o que está vacío, si está agregando una nueva propiedad). A continuación, modifique ese valor en su programa de edición hasta que represente el nuevo valor que desea almacenar para la propiedad, guarde el archivo temporal y, a continuación, salga del programa de edición. Si Subversion detecta que has cambiado realmente el valor existente de la propiedad, aceptará que como el nuevo valor de la propiedad. Si sale del editor sin realizar ningún cambio, no se producirá ninguna modificación de la propiedad: Debemos tener en cuenta que, al igual que con otros subcomandos svn, los relacionados con propiedades pueden actuar en múltiples rutas a la vez. Esto le permite modificar las propiedades de conjuntos completos de archivos con un solo comando. Por ejemplo, podríamos haber hecho lo siguiente: Toda esta propiedad añadiendo y editando no es muy útil si no puedes obtener fácilmente el valor de la propiedad almacenada. Por lo tanto, el programa svn proporciona dos subcomandos para mostrar los nombres y valores de las propiedades almacenadas en archivos y directorios. El comando svn proplist listará los nombres de las propiedades que existen en una ruta. Una vez que conozca los nombres de las propiedades en el nodo, puede solicitar sus valores individualmente mediante svn propget. Este comando, dado un nombre de propiedad y una ruta (o conjunto de rutas), imprime el valor de la propiedad en el flujo de salida estándar. Theres incluso una variación del comando del proplist que enumerará el nombre y el valor para todas las características. Suministre simplemente la opción --verbose (-v). El último subcomando relacionado con la propiedad es propdel. Puesto que Subversion le permite almacenar propiedades con valores vacíos, no puede quitar una propiedad completamente usando svn propedit o svn propset. Por ejemplo, este comando no producirá el efecto deseado: Necesita usar el subcomando propdel para eliminar propiedades por completo. La sintaxis es similar a los otros comandos de propiedad: Recuerde las propiedades de revisión sin versión También puede modificarlas usando los mismos subcomandos svn que acabamos de describir. Simplemente agregue el parámetro de línea de comandos --revprop y especifique la revisión cuya propiedad desee modificar. Dado que las revisiones son globales, no es necesario especificar una ruta de destino para estos comandos relacionados con la propiedad, siempre y cuando se encuentre en una copia de trabajo del repositorio cuya propiedad de revisión desee modificar. De lo contrario, puede simplemente proporcionar la URL de cualquier ruta del repositorio de interés (incluida la URL raíz del repositorio). Por ejemplo, es posible que desee reemplazar el mensaje de registro de confirmación de una revisión existente. 14 Si su directorio de trabajo actual es parte de una copia de trabajo de su repositorio, simplemente puede ejecutar el comando svn propset sin ruta de destino: Pero incluso si no ha extraído una copia de trabajo de ese repositorio, puede efectuar el cambio de propiedad Al proporcionar la URL raíz de repositorios: Tenga en cuenta que el administrador del repositorio debe agregar explícitamente la posibilidad de modificar estas propiedades no versionadas (consulte la sección denominada Corrección de mensajes de registro de confirmación). Eso se debe a que las propiedades no son versionadas, por lo que corre el riesgo de perder información si no tiene cuidado con sus ediciones. El administrador del repositorio puede configurar métodos para protegerse contra esta pérdida y, por defecto, la modificación de las propiedades no versionadas está deshabilitada. Los usuarios deben, cuando sea posible, usar svn propedit en lugar de svn propset. Mientras que el resultado final de los comandos es idéntico, el primero les permitirá ver el valor actual de la propiedad que están a punto de cambiar, lo que les ayuda a verificar que, de hecho, están haciendo el cambio que piensan que están haciendo . Esto es especialmente cierto cuando se modifican las propiedades de revisión no versionadas. Además, es significativamente más fácil modificar valores de propiedad multilínea en un editor de texto que en la línea de comandos. Propiedades y el flujo de trabajo de Subversion Ahora que está familiarizado con todos los subcomandos svn relacionados con la propiedad, veamos cómo las modificaciones de propiedades afectan al flujo de trabajo habitual de Subversion. Como mencionamos anteriormente, las propiedades de archivos y directorios están versionadas, al igual que el contenido de su archivo. Como resultado, Subversion ofrece las mismas oportunidades para fusionar de forma limpia o con conflictos a otras modificaciones en su cuenta. Al igual que con el contenido del archivo, los cambios de propiedad son modificaciones locales, permanecen permanentes sólo cuando se envían al repositorio con svn commit. Sus cambios de propiedad se pueden deshacer fácilmente, toothe svn revert comando restaurará sus archivos y directorios a sus estados uneditedcontents, propiedades, y todo. Además, puede recibir información interesante sobre el estado de sus propiedades de archivo y directorio mediante los comandos svn status y svn diff. Observe cómo el subcomando de estado muestra M en la segunda columna en lugar de la primera. Esto es porque hemos modificado las propiedades en calc / button. c. Pero no su contenido textual. Si hubiéramos cambiado ambos, también habríamos visto a M en la primera columna. (Cubrimos el estado de svn en la sección llamada Ver una descripción general de sus cambios). Al igual que con el contenido del archivo, las modificaciones de propiedades locales pueden entrar en conflicto con los cambios cometidos por otra persona. Si actualiza su directorio de copia de trabajo y recibe cambios de propiedad en un objeto versionado que choca con el suyo propio, Subversion informará de que el objeto está en un estado conflictivo. Subversion también creará, en el mismo directorio que el objeto en conflicto, un archivo con una extensión. prej que contenga los detalles del conflicto. Debe examinar el contenido de este archivo para que pueda decidir cómo resolver el conflicto. Hasta que el conflicto se resuelva, verá un C en la segunda columna de la salida de estado svn para ese objeto, y los intentos de cometer sus modificaciones locales fallarán. Para resolver conflictos de propiedad, simplemente asegúrese de que las propiedades en conflicto contienen los valores que deberían y, a continuación, utilice el comando svn resolve --acceptworking para alertar a Subversion de que ha resuelto manualmente el problema. También puede haber notado la forma no estándar en la que Subversion muestra las diferencias de propiedad. Todavía puede utilizar svn diff y redirigir su salida para crear un archivo de parche utilizable. El programa de parches ignorará patches de propiedad como una regla, ignora cualquier ruido que no pueda entender. Esto, por desgracia, significa que para aplicar plenamente un parche generado por svn diff utilizando parche. Cualquier modificación de la propiedad tendrá que ser aplicada a mano. Subversion 1.7 mejora esta situación de dos maneras. En primer lugar, su visualización no estándar de las diferencias de propiedades es por lo menos legible por máquina, una mejora con respecto a la visualización de propiedades en versiones anteriores a 1.7. Pero Subversion 1.7 también introduce el subcomando svn patch, diseñado específicamente para manejar la información adicional que puede transmitir svn diff s, aplicando esos cambios a la copia de trabajo de Subversion. De importancia específica para nuestro tema, las diferencias de propiedad presentes en los archivos de parches generados por svn diff en Subversion 1.7 o superior pueden aplicarse automáticamente a una copia de trabajo mediante el comando svn patch. Para más información sobre svn patch. Vea svn patch en el Capítulo 9, Subversion Complete Reference. Hay una excepción a cómo los cambios de propiedad son reportados por svn diff. Los cambios en la propiedad especial de svn: mergeinfo de Subversions utilizada para rastrear la información sobre fusiones que se han realizado en su repositorio se describen de una forma más legible por el usuario. Esto es muy útil para los seres humanos que tienen que leer esas descripciones. Pero también sirve para que los programas de parches (incluyendo svn patch) salten esas descripciones de cambio como ruido. Esto puede sonar como un error, pero realmente no es porque esta propiedad está destinada a ser gestionado únicamente por el subcomando svn merge. Para obtener más información sobre el seguimiento de la combinación, consulte el Capítulo 4, Ramificación y Fusión. Las Propiedades de Propiedades de Propiedades Automáticas son una característica poderosa de Subversion, actuando como componentes clave de muchas características de Subversion discutidas en otra parte de este y otros capítulos, la sustitución de diferencias y combinaciones, la sustitución de palabras clave, la traducción de nueva línea y así sucesivamente. Pero para obtener el beneficio completo de las propiedades, deben establecerse en los archivos y directorios adecuados. Desafortunadamente, ese paso puede ser fácilmente olvidado en la rutina de las cosas, especialmente porque no establecer una propiedad no suele resultar en un error obvio (al menos en comparación con, digamos, no agregar un archivo al control de versiones). Para ayudar a que sus propiedades se apliquen a los lugares que las necesitan, Subversion proporciona un par de características simples pero útiles. Siempre que introduzca un archivo en el control de versiones utilizando los comandos svn add o svn import, Subversion intentará ayudar configurando algunas propiedades de archivo comunes de forma automática. En primer lugar, en los sistemas operativos cuyos sistemas de archivos soportan un bit de permiso de ejecución, Subversion establecerá automáticamente la propiedad svn: ejecutable en archivos recién agregados o importados cuyo bit de ejecución está habilitado. (Consulte la sección llamada Ejecución de archivos más adelante en este capítulo para obtener más información sobre esta propiedad.) En segundo lugar, Subversion intenta determinar el tipo MIME de archivos. Si has configurado un parámetro de configuración de tiempo de ejecución de mime-types-files, Subversion intentará encontrar una asignación de tipo MIME en ese archivo para la extensión de archivos. Si encuentra una correlación de este tipo, establecerá la propiedad svn: mime-type de los archivos en el tipo MIME que encontró. Si no se ha configurado ningún archivo de asignación o no se ha podido encontrar ninguna correlación para su extensión de archivos, Subversion volverá a algoritmos heurísticos para determinar el tipo MIME de archivos. Dependiendo de cómo se construya, Subversion 1.7 puede hacer uso de las bibliotecas de exploración de archivos 15 para detectar un tipo de archivo basado en su contenido. A falta de todo lo demás, Subversion empleará su propia heurística muy básica para determinar si el archivo contiene contenido no textual. Si es así, automáticamente establece la propiedad svn: mime-type en ese archivo en application / octet-stream (el genérico es una colección de bytes de tipo MIME). Por supuesto, si Subversion adivina incorrectamente, o si desea configurar la propiedad svn: mime-type a algo más preciso, tal vez image / png o application / x-shockwave-flash siempre puede quitar o editar esa propiedad. UTF-16 se utiliza comúnmente para codificar archivos cuyo contenido semántico es de naturaleza textual, pero la codificación en sí hace uso intensivo de bytes que Están fuera del rango típico de bytes de caracteres ASCII. Como tal, Subversion tenderá a clasificar tales archivos como archivos binarios, para gran disgusto de los usuarios que desean diferenciar y combinar en línea, sustitución de palabras clave y otros comportamientos para esos archivos. Subversion también proporciona, a través de su sistema de configuración de tiempo de ejecución (consulte la sección denominada Área de configuración de tiempo de ejecución), una función de configuración de propiedades automática más flexible que le permite crear asignaciones de patrones de nombre de archivo a nombres y valores de propiedades. Una vez más, estas asignaciones afectan a las importaciones e importaciones, y no sólo pueden anular la decisión de tipo MIME predeterminada tomada por Subversion durante esas operaciones, sino que también pueden establecer propiedades adicionales de Subversion o personalizadas. Por ejemplo, puede crear una asignación que indique que cada vez que agregue archivos JPEG con nombres que coincidan con el patrón. Subversion debería establecer automáticamente la propiedad svn: mime-type en esos archivos a image / jpeg. O quizás cualquier archivo que coincida con. cpp debería tener svn: eol-style configurado como nativo. Y svn: palabras clave establecidas en Id. El soporte automático de propiedades es quizás la herramienta más apropiada para la propiedad en la caja de herramientas de Subversion. Consulte la sección Config para obtener más información sobre cómo configurar dicha compatibilidad. Los administradores de Subversion comúnmente preguntan si es posible configurar, en el lado del servidor, un conjunto de definiciones de propiedad que todos los clientes conectados considerarán automáticamente cuando operen en copias de trabajo extraídas de ese servidor. Lamentablemente, Subversion no ofrece esta función. Los administradores pueden usar scripts de gancho para validar que las propiedades agregadas y modificadas en los archivos y directorios coinciden con las directivas preferidas de los administradores, rechazando los compromisos que no cumplen de esta manera. (Véase la sección titulada Implementing Repository Hooks para más información sobre los scripts de gancho). Pero no hay manera de dictar automáticamente esas preferencias a los clientes de Subversion de antemano. 13 Si está familiarizado con XML, esto es prácticamente el subconjunto ASCII de la sintaxis de XML Name. 14 Corregir los errores de ortografía, gramaticales y simplemente erróneos en los mensajes de registro de confirmación es quizás el caso de uso más común para la opción --revprop. 15 Actualmente, libmagic es la biblioteca de soporte utilizada para lograr esto. Está leyendo Control de versiones con Subversion (para Subversion 1.7), por Ben Collins-Sussman, Brian W. Fitzpatrick y C. Michael Pilato. Esta obra está licenciada bajo la licencia Creative Commons Attribution License v2.0. Para ver una copia de esta licencia, visite el sitio Creative Commons o envíe una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, EE. UU. Para enviar comentarios, correcciones u otras contribuciones al texto, por favor visite svnbook /.Cannot display: archivo marcado como un tipo binario Publicaría esto en el grupo de usuarios de Subversion, pero esto es en parte en respuesta al subproceso de TortoiseSVN quotApply Sugerencias del 4/25/2009. De svn. haxx. se/tsvn/archive-2009-04/0197.shtml Veo Stefan Kng escribió: gt Otra cosa a recordar: svn 1.7 tendrá un nuevo formato de parche que gt incluye cambios binarios y renombra / movimientos. También proporcionará una nueva API gt para crear y aplicar dichos archivos de parches. Esto significa que la característica diff / patch gt de TMerge tendrá que ser reescrita de todos modos, por lo que estoy inclinando gt hacia la espera de implementar estos cambios ahora mismo, pero esperar al menos gt hasta que cambiemos el tronco TSVN a la troncal svn. Usando svn 1.7.1, intenté crear un archivo de revisión para un cambio de archivo binario y obtuve esto: Cuando miro a través de las notas de la versión de Subversion 1.7, no veo nada sobre el manejo de archivos binarios. También no podría encontrar ninguna otra mención de esta característica en la tela. ¿La declaración de Stefans resultó ser incorrecta, o estamos perdiendo algo sobre la creación de parches para archivos binarios? ¿Se puede hacer con la línea de comandos de Tortoise frente a la línea de comandos de Subversion? Entonces realmente intenté usar svn diff - force. Esto generó un archivo de parche. He guardado una copia del archivo modificado, he revertido el archivo binario, usado svn patch para aplicar el cambio, y luego comparado el resultado parcheado con el binario originalmente modificado. El resultado en este momento fue un archivo dañado. Por lo tanto, parecería que diff - force tampoco es la respuesta. Intenté usar Tortoise para hacer esto, y conseguí el mismo error que arriba. (Esto ocurre incluso si se selecciona la opción para usar el formato git.) No hay ninguna opción quotforcequot que pueda ver en Tortoise. ¿Estoy perdiendo algo, o esta característica no se ha implementado aún en svn o Tortoise Si alguien sabe de cualquier utilidad de contenedor de cualquier tipo que manejan binarios, me gustaría saber que también. Por favor considere el medio ambiente antes de imprimir este e-mail. El contenido de este mensaje de correo electrónico (incluyendo cualquier archivo adjunto) es confidencial y está destinado a ser transmitido para el uso del destinatario a quien se dirige solamente. Si recibe esta transmisión por error, notifique inmediatamente al remitente y elimine el mensaje de su sistema. Cualquier distribución, reproducción o uso de este mensaje por alguien que no sea receptor no está autorizado y puede ser ilegal. Para darse de baja de esta discusión, e-mail: users-unsubscribeattortoisesvn46 tigris. org. Recibido en 2011-10-28 18:19:57 CEST
No comments:
Post a Comment