TortoiseSVN

TortoiseSVN se ejecuta en Windows 2000 SP2, Windows XP o superiores. Windows 98, Windows ME y Windows NT4 ya no se soportan desde TortoiseSVN 1.2.0, pero aún puede descargar las versiones más antiguas si realmente las necesita.

Si encuentra algún problema durante o después de la instalación de TortoiseSVN, por favor visite primero Apéndice A, Preguntas más frecuentes (FAQ).

TortoiseSVN viene con un instalador fácil de utilizar. Haga doble click en el fichero de instalación y siga las instrucciones. El instalador se encargará del resto.

El interfaz de usuario de TortoiseSVN se ha traducido a muchos idiomas distintos, por lo que es posible que pueda descargar un pack de idioma que se ajuste a sus necesidades. Puede encontrar los packs de idioma en nuestra página de estado de las traducciones. Y si aún no hay un pack de idioma disponible, por qué no unirse al equipo y enviar su propia traducción ;-)

Cada pack de idioma está empaquetado como un instalador .exe. Sólo tiene que ejecutar el programa de instalación y seguir las instrucciones. La siguiente vez que reinicie, tendrá disponible la traducción.

TortoiseSVN incluye un corrector ortográfico que le permite comprobar sus mensajes de registro en las confirmaciones. Esto es especialmente útil si el idioma del proyecto no es su lengua materna. El corrector ortográfico utiliza los mismos diccionarios que OpenOffice y Mozilla.

El instalador automáticamente añade los diccionarios de inglés de EE.UU. y de Reino Unido. Si desea tenerlos en otros idiomas, la opción más sencilla es símplemente instalar uno de los packs de idiomas de TortoiseSVN. Eso instalará los ficheros de diccionario adecuados junto con el interface de usuario de TortoiseSVN en ese idioma. La siguiente vez que reinicie, el diccionario también estará disponible.

O puede instalar los diccionarios usted mismo. Si tiene OpenOffice o Mozilla instalados, puede copiar esos diccionarios, que se encuentran en las carpetas de instalación de esas aplicaciones. Si no, deberá descargar los ficheros de diccionario necesarios desde http://wiki.services.openoffice.org/wiki/Dictionaries

Una vez que tenga los ficheros de diccionario, seguramente deberá cambiarlos de nombre para que los nombres de los ficheros sólo contengan los caracteres del idioma. Por ejemplo:

Luego sólo tiene que copiarlos en la subcarpeta bin de la carpeta de instalación de TortoiseSVN. Normalmente ésta será C:\Archivos de programa\TortoiseSVN\bin. Si no desea jugar con la subcarpeta bin, también puede poner los ficheros del corrector ortográfico en C:\Archivos de programa\TortoiseSVN\Languages. Si esa carpeta no está ahí, tendrá que crearla primero. La siguiente vez que inicie TortoiseSVN, podrá utilizar el corrector ortográfico.

Si instala múltiples diccionarios, TortoiseSVN utilizará estas reglas para seleccionar cuál utilizar.

Considere este escenario: suponga que tiene dos compañeros de trabajo, Harry y Sally. Cada uno decide editar el mismo fichero del repositorio a la vez. Si Harry graba sus cambios en el repositorio primero, el posible que (unos momentos después) Sally pueda accidentalmente sobreescribirlos con su propia versión nueva del fichero. Mientras que la versión del fichero de Harry no se ha perdido para siempre (porque el sistema recuerda cada cambio), cualquier cambio que Harry hizo no estará en la versión nueva del fichero de Sally, porque para empezar ella nunca vió los cambios de Harry. El trabajo de Harry está aún efectivamente perdido - o al menos falta en la última versión del fichero - y probablemente por accidente. ¡Esta es una situación que definitivamente tenemos que evitar!

Figura 2.2. El problema a evitar

Muchos sistemas de control de versiones utilizan un modelo bloquear-modificar-desbloquear para enfrentarse a este problema, que es una solución muy simple. En estos sistemas, el repositorio sólo permite que una persona cambie un fichero al mismo tiempo. Harry primero debe bloquear el fichero antes de que pueda empezar a hacer cambios en él. Bloquear un fichero se parece mucho a tomar prestado un libro de la biblioteca; si Harry ha bloqueado un fichero, entonces Sally no puede hacer ningún cambio en él. Si ella intenta bloquear el fichero, el repositorio le denegará la petición. Todo lo que ella puede hacer es leer el fichero, y esperar a que Harry termine sus cambios y libere su bloqueo. Después de que Harry desbloquee el fichero, se acabó su turno, y ahora Sally puede bloquear y editar.

Figura 2.3. La solución bloquear-modificar-desbloquear

El problema con el modelo bloquear-modificar-desbloquear es que es un poco restrictivo, y a menudo se convierte en una calle cortada para los usuarios:

Subversion, CVS y otros sistemas de control de versiones utilizan un modelo copiar-modificar-fusionar como alternativa al bloqueo. En este modelo, el cliente de cada usuario lee el repositorio y crea una copia de trabajo personal del fichero o del proyecto. Luego, los usuarios trabajan en paralelo, modificando sus copias privadas. Finalmente, las copias privadas se fusionan juntas en una nueva versión final. El sistema de control de versiones a menudo ofrece ayuda en la fusión, pero al final la persona es la responsable de hacer que ocurra correctamente.

Aquí hay un ejemplo. Digamos que tanto Harry como Sally crean copias de trabajo del mismo proyecto, copiado del repositorio. Ellos trabajan concurrentemente, y hacen los cambios al mismo fichero A dentro de sus copias. Sally es la primera en grabar sus cambios en el repositorio. Cuando Harry intenta grabar sus cambios más tarde, el repositorio le informa que su fichero A está desactualizado. En otras palabras, que el fichero A en el repositorio ha cambiado de alguna forma desde la última vez que lo copió. Por lo que Harry le pide a su cliente que fusione cualquier nuevo cambio del repositorio dentro de su copia de trabajo del fichero A. Lo más seguro es que los cambios de Sally no se superpongan a los suyos; por lo que una vez que ambos conjuntos de cambios se han integrado, él graba su copia de trabajo de nuevo en el repositorio.

Figura 2.4. La solución copiar-modificar-fusionar

Figura 2.5. ...Copiar-modificar-fusionar continuado

¿Pero qué ocurre si los cambios de Sally sí se superponen a los cambios de Harry? ¿Qué hacemos entonces? La situación se denomina un conflicto, y normalmente no es mucho problema. Cuando Harry le pide a su cliente que fusione los últimos cambios del repositorio en su copia de trabajo, su copia del fichero A se marca de alguna forma como que está en un estado de conflicto: él será capaz de ver ambos conjuntos de cambios conflictivos, y manualmente podrá elegir entre ellos. Tenga en cuenta que el software no puede resolver conflictos automáticamente; sólo los humanos son capaces de entender y hacer las elecciones necesarias de forma inteligente. Una vez que Harry haya resuelto manualmente los cambios que se superponían (¡quizás discutiendo el conflicto con Sally!), puede volcar de forma segura el fichero fusionado al repositorio.

El modelo copiar-modificar-fusionar puede sonar un poco caótico, pero en la práctica, funciona extremadamente bien. Los usuarios pueden trabajar en paralelo, sin que tengan que esperar nunca uno por otro. Cuando trabajan en los mismos ficheros, resulta que la mayoría de los cambios concurrentes no se superponen en absoluto; los conflictos no son frecuentes. Y el tiempo que lleva resolver conflictos es mucho menor que el tiempo perdido por un sistema bloqueante.

Al final, todo se reduce a un factor crítico: la comunicación entre usuarios. Cuando los usuarios se comunican de forma pobre, aumentan los conflictos sintácticos y semánticos. No hay sistema capaz de forzar a los usuarios a comunicarse perfectamente, y no hay sistema que pueda detectar conflictos semánticos. Por lo que no hay motivo para que se le prometa falsamente que un sistema con bloqueos prevendrá de alguna forma los conflictos; en la práctica, el bloqueo parece inhibir la productividad más que otra cosa.

Hay una situación común donde el modelo bloquear-modificar-desbloquear resulta mejor, y es cuando tiene ficheros no-fusionables. Por ejemplo si su repositorio contiene algunas imágenes gráficas, y dos personas cambian la imagen a la vez, no hay forma de fusionar esos cambios. O Harry o Sally perderán sus cambios.

Subversion utiliza la solución copiar-modificar-mezclar por defecto, y en muchos casos esto es todo lo que necesitará. Sin embargo, desde la Versión 1.2, Subversion también admite bloqueo de ficheros, por lo que si tiene ficheros no-fusionables, o si simplemente está forzado a una política de bloqueo por la dirección, Subversion seguirá teniendo las características que necesita.

Ya ha oído hablar sobre las copias de trabajo; ahora le demostraremos cómo las crea y las utiliza el cliente de Subversion.

Una copia de trabajo de Subversion es un árbol de directorios ordinario en su sistema local, conteniendo una colección de ficheros. Puede editar estos ficheros como desee, y si son ficheros de código fuente, puede compilar su programa de la forma habitual. Su copia de trabajo es su propia área de trabajo privada: Subversion nunca incorporará los cambios de otra gente, ni hará que sus cambios estén disponibles para los demás, a menos que se lo pida explícitamente.

Después de que haya hecho algunos cambios en los ficheros dentro de su copia de trabajo y haya verificado que funcionan correctamente, Subversion le provee de comandos para publicar sus cambios para los demás que trabajan con usted en su proyecto (escribiendo en el repositorio). Si los demás publican sus propios cambios, Subversion le provee de comandos para fusionar esos cambios dentro de su copia de trabajo (leyendo desde el repositorio).

Una copia de trabajo también contiene algunos ficheros extra, creados y mantenidos por Subversion, para ayudarse a llevar a cabo esos comandos. En particular, cada directorio detnro de su copia de trabajo contiene un subdirectorio llamado .svn, también conocido como el directorio administrativo de la copia de trabajo. Los ficheros dentro de los directorios administrativos ayudan a Subversion a reconocer qué ficheros contienen cambios no publicados, y qué ficheros están desactualizados respecto al trabajo de los demás.

Un repositorio típico de Subversion a menudo contiene los ficheros (o el código fuente) de varios proyectos; usualmente, cada proyecto es un subdirectorio en el árbol de ficheros del repositorio. Con esta disposición, una copia de trabajo de un usuario normalmente corresponderán a un subárbol particular del repositorio.

Por ejemplo, suponga que tiene un repositorio que contiene dos proyectos de software.

Figura 2.6. El sistema de ficheros del repositorio

En otras palabras, el directorio raíz del repositorio tiene dos subdirectorios, paint y calc.

Para obtener una copia de trabajo, primero debe obtener algún subárbol del repositorio. (El término obtener puede sonar como que tenga algo que ver con el bloqueo o la reserva de recursos, pero no es cierto; simplemente crea una copia privada del proyecto para usted).

Suponga que ha hecho cambios a button.c. Dado que el directorio .svn recuerda la fecha de modificación y los contenidos originales del fichero, Subversion puede decirle que ha cambiado el fichero. Sin embargo, Subversion no hace públicos sus cambios hasta que explícitamente se lo pida. El acto de publicar sus cambios se conoce más comúnmente como confirmar (o enviar) los cambios al repositorio.

Para publicar sus cambios para los demás, puede utilizar el comando de Subversion commit.

Ahora que sus cambios a button.c se han confirmado en el respositorio, si cualquier otro usuario obtiene una copia de trabajo de /calc, verán sus cambios en la última versión del fichero.

Suponga que tiene un colaborador, Sally, que obtuvo una copia de trabajo de /calc al mismo tiempo que usted. Cuando ha confirmado sus cambios en button.c, la copia de trabajo de Sally se queda sin cambios; Subversion sólo modifica las copias de trabajo cuando lo pide el usuario.

Para poner al día su proyecto, Sally puede pedirle a Subversion actualizar su copia de trabajo, utilizando el comando de Subversion actualizar. Esto incorporará sus cambios en la copia de trabajo de Sally, junto con cualquier otro que se haya confirmado desde que ella lo obtuvo.

Tenga en cuenta que Sally no necesita especificar qué ficheros actualizar; Subversion utiliza la información en el directorio .svn, y más información desde el repositorio, para decidir qué ficheros deben ponerse al día.

Los repositorios de Subversion pueden ser accedidos por muchos métodos diversos - en discos locales, o a través de varios protocolos de red. La ruta de un repositorio es siempre, sin embargo, una URL. El esquema URL indica el método de acceso:

En su mayoría, las URLs de Subversion utilizan la sintaxis estándar, permitiendo que se especifiquen nombres de servidor y números de puertos como parte de la URL. El método de acceso file:// se utiliza normalmente para el acceso local, aunque puede utilizarse con rutas UNC a equipos en red. La URL por lo tanto toma la forma file://nombredeequipo/ruta/al/repositorio. Para la máquina local, la parte nombredeequipo de la URL debe estar o ausente o ser localhost. Por esta razón, las rutas locales normalmente aparecen con tres barras, file:///ruta/al/repositorio.

Además, los usuarios del esquema file:// en las plataformas Windows necesitarán utilizar una sintaxis “estándar” no oficial para acceder a los repositorios que están en la misma máquina, pero en una letra de unidad diferente de la unidad actual del cliente. Cualquiera de las siguientes sintaxis de URL funcionarán, donde X es la unidad en la que reside el repositorio:

file:///X:/ruta/al/repositorio
...
file:///X|/ruta/al/repositorio
...

Tenga en cuenta que las URLs utilizan las barras hacia delante (las de dividir) incluso aunque la forma nativa (no-URL) de una ruta en Windows utiliza las barras contrarias.

Puede acceder con seguridad a un repositorio FSFS utilizando una carpeta compartida de red, pero no puede acceder a un repositorio BDB de esta forma.

Una operación svn commit puede publicar los cambios de cualquier número de ficheros y carpetas como una única transacción atómica. En su copia de trabajo, puede cambiar el contenido de los ficheros, crear, borrar, renombrar y copiar ficheros y directorios, y luego confirmar el conjunto completo de cambios como una unidad.

En el repositorio, cada confirmación se trata como una transacción atómica: o bien todos los cambios de la confirmación se llevan a cabo, o bien ninguno de ellos se realiza. Subversion aplica esta atomicidad en caso de errores en el programa, errores del sistema, problemas de red, y otras acciones del usuario.

Cada vez que el repositorio acepta una confirmación, crea un nuevo estado del árbol de ficheros, llamado revisión. A cada revisión se le asigna un número natural único, un número mayor que la revisión anterior. La revisión inicial de un repositorio recién creado se numera como cero, y consiste únicamente en un directorio raíz vacío.

Una buena forma de visualizar el repositorio es como una serie de árboles. Imagine una fila de números de revisiones, empezando en 0, de izquierda a derecha. Cada número de revisión tiene un árbol colgando debajo, y cada árbol es una “foto” de cómo estaba el repositorio tras cada confirmación.

Figura 2.7. El repositorio

Es importante que tenga en cuenta que las copias de trabajo no siempre se corresponden a una única revisión en el repositorio; pueden contener ficheros de varias revisiones.Por ejemplo, suonga que obtiene una copia de trabajo de un repositorio cuya revisión más reciente es la 4:

calc/Makefile:4
     integer.c:4
     button.c:4

En este momento, esta copia de trabajo corresopnde exactamente a la revisión 4 en el respositorio. Sin embargo, suponga que ha hecho cambios al fichero button.c, y confirme ese cambio. Asumiendo que no se haya llevado a cambio ninguna otra confirmación, su confirmación creará la revisión 5 en el repositorio, y su copia de trabajo quedará así:

calc/Makefile:4
     integer.c:4
     button.c:5

Suponga que, en este punto, Sally hace un cambio a integer.c, creando la revisión 6. Si utiliza svn update para actualizar su copia de trabajo, obtendrá ésto:

calc/Makefile:6
     integer.c:6
     button.c:6

Los cambios de Sally a integer.c aparecerán en su copia de trabajo, y su cambio estará aún presente en button.c. En este ejemplo, el texto de Makefile es idéntico en las revisiones 4, 5, y 6, pero Subversion marcará su copia de trabajo de Makefile con la revisión 6 para indicar que aún está actualizado. Por lo que, después de que haga una actualización limpia en la parte superior de su copia de trabajo, generalmente obtendrá exactamente una revisión del repositorio.

Por cada fichero en un directorio de trabajo, Subversion grabará dos piezas esenciales de información en el área administrativa .svn/:

Con esta información, hablando con el repositorio, Subversion puede decirle en cuál de los siguientes cuatro estados está un fichero de trabajo:

Ahora ya tiene un nuevo repositorio que se encuentra en D:\SVN\MiNuevoRepositorio.

Para acceder a su repositorio local, necesita la ruta a esa carpeta. Recuerde que Subversion espera todas las rutas de repositorios con el formato file:///C:/RepositorioSVN/. Tenga en cuenta el uso de las barras de dividir.

Para acceder a un repositorio que se encuentre en una unidad de red compartida puede o bien utilizar mapeado de unidades, o bien usar la ruta UNC. El formato de una ruta UNC es file://NombreDelServidor/ruta/al/repositorio/. Observe que sólo hay 2 barras invertidas aquí.

Antes de SVN 1.2, las rutas UNC tenían que estar dadas en la forma más oscura file:///\NombreDelServidor/ruta/al/repositorio. Esta forma aún se puede utilizar, pero no está recomendada.

Aunque en teoría es posible poner un repositorio FSFS en una unidad de red y hacer que varios usuarios accedan a él utilizando el protocolo file://, esto realmente no está recomendado. De hecho, nosotros lo desaconsajemos encarecidamente, y no soportamos este uso.

En primer lugar, está dando a todos los usuarios acceso directo de escritura en el repositorio, por lo que cualquier usuario podría accidentalmente borrar el repositorio completo o hacerlo inutilizable de cualquier otra forma.

En segundo lugar, no todos los protocolos de compartición de ficheros de red soportan el bloqueo que Subversion necesita, por lo que puede encontrar que su repositorio se corrompe. Puede que no ocurra al principio, pero un día dos usuarios intentarán acceder al repositorio al mismo tiempo.

En tercer lugar, también debe establecer los permisos de los ficheros. Puede ser sencillo en una unidad de red nativa de Windows, pero en SAMBA esto es particularmente dificil.

El acceso file:// está pensado únicamente para el acceso local por un único usuario, en particular para testeos y depuraciones. Cuando desee compartir el repositorio, realmente necesita configurar un servidor de forma apropiada, y realmente no es tan dificil como pueda pensar. Lea “Accediendo al repositorio” para obtener indicaciones sobre cómo elegir y configurar un servidor.

Antes de que importe sus datos al repositorio, primero debería pensar cómo quiere organizar sus datos. Si utiliza uno de los patrones recomendados lo tendrá luego mucho más fácil.

Hay algunas formas estándar y recomendadas de organizar un repositorio. La mayoría de la gente crea un directorio trunk (tronco) para alojar la “línea principal del desarrollo, un directorio branches (ramas) para que contenga las copias/ramas, y un directorio tags (etiquetas) para contener las copias/etiquetas. Si un repositorio s”

/trunk
/branches
/tags

Si un repositorio contiene múltiples proyectos, la gente a menudo indexa por ramas:

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc

...o por proyecto:

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Indexar por proyecto tiene sentido si los proyectos no están muy relacionados y cada uno se obtiene de forma individual. Para proyectos relacionados donde puede querer obtener todos los proyectos de golpe, o donde los proyectos están unidos y forman un paquete de distribución único, a menudo es mejor indexar por rama. De esta forma sólo tendrá un tronco para obtener, y las relaciones entre sub-proyectos se ven más fácilmente.

Si adopta una aproximación de primer nivel /trunk /tags /branches, no es necesario decir que tendrá que copiar el tronco completo para cada rama y etiqueta, y de alguna forma esta estructura ofrece la mayor flexibilidad.

Para proyectos que no tienen que ver, puede preferir utilizar repositorios separados. Cuando confirma los cambios, lo que cambia es el número de revisión del repositorio completo, no el número de revisión del proyecto. Si tiene 2 proyectos que no tengan que ver compartiendo un repositorio, eso puede llevar a que ocurran grandes lagunas en los números de revisión. Los proyectos Subversion y TortoiseSVN aparecen en el mismo servidor, pero son dos repositorios totalmente separados que permiten un desarrollo independiente, y no hay confusión sobre los números de compilación.

Por supuesto, tiene libertad para ignorar estos patrones comunes. Puede crear cualquier variación, la que mejor le venga a usted o a su equipo. Recuerde que cualquiera que sea la que elija, no es una elección inamovible. Puede reorganizar su repositorio en cualquier momento. Dado que las ramas y las etiquetas son directorios normales, TortoiseSVN puede mover o renombrarlas como desee.

Cambiar de una disposición a otra es sólo una cuestión de ejecutar una serie de movimientos en el lado del servidor; si no le gusta la forma en la que están organizadas las cosas en el repositorio, sólo tiene que ir moviendo los directorios.

Así que si no ha creado todavía una estructura básica de carpetas dentro de su repositorio, debería hacerlo ahora. Hay dos formas de conseguirlo. Si simplemente desea crear una estructura /trunk /tags /branches, puede utilizar el visor de repositorios para crear las tres carpetas (en tres confirmaciones distintas). Si desea crear una jerarquía más profunda, es más fácil crear primero una estructura de carpetas en el disco e importarla en una única confirmación, por ejemplo:

Tenga en cuenta que el nombre de la carpeta que está importando no aparece en el repositorio, sólo sus contenidos. Por ejemplo, cree la siguiente estructura de carpetas:

C:\Temp\New\trunk
C:\Temp\New\branches
C:\Temp\New\tags

Importe C:\Temp\New en la raíz del repositorio, que entonces contendrá:

/trunk
/branches
/tags

Subversion incluye Svnserve - un servidor ligero y autónomo que utiliza un protocolo propio sobre una conexión TCP/IP ordinaria. Es ideal para las instalaciones más pequeñas, o donde no se pueda utilizar un servidor completo Apache.

En la mayoría de los casos svnserve es más fácil de instalar y se ejecuta más rápido que el servidor basado en Apache, aunque no tiene algunas de las características más avanzadas. Y ahora que se incluye soporte SASL es fácil hacerlo seguro también.

Ahora que svnserve está instalado, necesitará ejecutarlo en su servidor. La forma más sencilla es ejecutar lo siguiente desde una ventana DOS o bien crear un acceso directo de Windows:

svnserve.exe --daemon

svnserve ahora se iniciará esperando peticiones entrantes en el puerto 3690. La opción --daemon le dice a svnserve que se ejecute como un servicio, por lo que continuará ejecutándose hasta que manualmente se le mande terminar.

Si aún no ha creado un repositorio, siga las instrucciones dadas en la instalación del servidor basado en Apache “Configuración”.

Para comprobar que svnserve está funcionando, utilice TortoiseSVN → Navegador para ver un repositorio.

Asumiendo que su repositorio está en c:\repos\TestRepo, y que su servidor se llama localhost, introduzca:

svn://localhost/repos/TestRepo

cuando le pregunte el navegador de repositorios.

También puede incrementar la seguridad y ahorrar tiempo introduciendo URLs con svnserve utilizando la opción --root para cambiar la ruta raíz y restringir el acceso a un directorio concreto del servidor:

svnserve.exe --daemon --root unidad:\ruta\al\repositorio

Utilizando el test anterior como guía, se debería ejecutar svnserve así:

svnserve.exe --daemon --root c:\repos

Y en TortoiseSVN la URL del navegador de repositorios se acorta así:

svn://localhost/TestRepo

Tenga en cuenta que la opción --root también se necesita si su repositorio está en una unidad o partición diferente del lugar donde está svnserve en su servidor.

Svnserve podrá servir un número de repositorios arbitrario. Simplemente colóquelos en algún lugar bajo la carpeta raíz que acaba de definir, y acceda a ellos utilizando una URL relativa a esa raíz.

sc create svnserve binpath= "c:\svnserve\svnserve.exe --service 
    --root c:\repos" displayname= "Subversion" depend= tcpip 
    start= auto

sc create svnserve binpath= "
    \"C:\Archivos de programa\Subversion\bin\svnserve.exe\"
    --service --root c:\repos" displayname= "Subversion"
    depend= tcpip start= auto

sc description svnserve "Servidor de Subversion (svnserve)"

obj= "NT AUTHORITY\LocalService"

svnservice -remove

La configuración por defecto de svnserve proporciona acceso anónimo de sólo-lectura. Esto significa que puede utilizar una URL de tipo svn:// para obtener y actualizar, o utilizar el navegador de repositorios en TortoiseSVN para ver el repositorio, pero no podrá confirmar ningún cambio.

Para permitir acceso de escritura en un repositorio, necesitará editar el fichero conf/svnserve.conf en el directorio de su repositorio. Este fichero controla la configuración del servicio svnserve, y también contiene información útil.

Puede habilitar el acceso anónimo para escritura simplemente poniendo:

[general]
anon-access = write

Sin embargo, no sabrá quién ha hecho cambios en el repositorio, dado que la propiedad svn:author estará vacía. Tampoco podrá controlar quién puede hacer cambios en el repositorio. ¡Esta es una configuración algo arriesgada!

Una forma de conseguir esto es crear una base de datos de contraseñas:

[general]
anon-access = none
auth-access = write
password-db = ficherodeusuarios

Donde ficherodeusuarios es un fichero que existe en el mismo directorio que svnserve.conf. Este fichero también puede estar en cualquier otro sitio de su sistema de ficheros (útil cuando tiene múltiples repositorios que necesitan los mismos derechos de acceso) y puede ser referenciado utilizando una ruta absoluta, o una ruta relativa del directorio conf. Si incluye una ruta, debe estar escrita /a/la/forma/de/unix. No funcionará si utiliza \ o letras de unidades. El ficherodeusuarios debería tener una estructura como ésta:

[users]
usuario = contraseña
...

Este ejemplo denegaría cualquier acceso a los usuarios no autentificados (anónimos), y daría acceso de lectura-escritura a los usuarios listados en ficherodeusuarios.

Otra forma de autentificar a los usuarios con un servidor basado en svnserve es utilizar un shell seguro (SSH) para encapsular las peticiones a través suyo. No es tan sencillo de preparar como SASL, pero puede ser útil en algunos casos.

Con esta aproximación, svnserve no se ejecuta como un servicio, en cambio, el shell seguro inicia svnserve por usted, ejecutándolo como el usuario autentificado SSH. Para habilitar esto, necesita un servicio de shell seguro en su servidor.

En Apéndice G, Asegurando Svnserve utilizando SSH tiene un método básico para preparar su servidor. Puede encontrar otros temas SSH en el FAQ buscando “SSH”.

Puede encontrar más información sobre svnserve en el libro Control de versiones con Subversion.

Empezando con Subversion 1.3, svnserve soporta el mismo esquema de autorización basada en rutas que está disponible en el módulo mod_authz_svn de Apache. Necesita editar el fichero conf/svnserve.conf dentro del directorio de su repositorio y añadir una línea refiriéndose a su fichero de autorización.

[general]
authz-db = authz

Aquí, authz es un fichero que debe existir y que define los permisos de acceso. Puede utilizar un fichero separado por cada repositorio, o utilizar el mismo fichero para varios repositorios. Si desea una descripción del formato del fichero, lea “Autorización basada en rutas”.

La configuración más flexible de todas las instalaciones de servidor posibles para Subversion es la que se basa en Apache. Aunque es un poco más complicada de preparar, ofrece beneficios que otros servidores no pueden dar:

La primera cosa que necesita antes de instalar Apache es un ordenador con Windows 2000, Windows XP con SP1, Windows 2003, Vista o Server 2008.

Ahora ya ha preparado Apache y Subversion, pero Apache aún no sabe cómo manejar los clientes de Subversion como TortoiseSVN. Para que Apache sepa qué URL debe utilizarse para los repositorios de Subversion debe editar el fichero de configuración de Apache (normalmente está en C:\Archivos de programa\Apache Group\Apache2\conf\httpd.conf) con cualquier editor de texto que desee (por ejemplo, el Bloc de notas):

Una explicación breve sobre lo que acaba de introducir:

Pero eso es sólo un ejemplo. Hay muchas, muchas más posibilidades de lo que puede hacer con el servidor web Apache.

Si ha utilizado la directiva SVNParentPath no necesita cambiar el fichero de configuración de Apache cada vez que añada un nuevo repositorio de Subversion. Simplemente cree el nuevo repositorio bajo la misma ruta que el primer repositorio, ¡y ya está! En mi compañía, tengo acceso directo a esa carpeta en concreto utilizando SMB (el acceso normal de ficheros de Windows). Por lo que simplemente creo una nueva carpeta allí, ejecuto el comando de TortoiseSVN TortoiseSVN → Crear repositorio aquí... y ya hay un nuevo proyecto que tiene su hogar...

Si está utilizando Subversion 1.3 o posterior, puede utilizar la directiva SVNListParentPath on para permitir que Apache produzca un listado de todos los proyectos disponibles si apunta su navegador a la ruta raíz en vez de a un repositorio en concreto.

El módulo mod_authz_svn le permite un control detallado de los permisos de acceso basado en nombres de usuarios y rutas de repositorio. Esto está disponible si utiliza el servidor de Apache, y desde Subversion 1.3 también está disponible si utiliza svnserve.

Esto sería un fichero de ejemplo:

[groups]
admin = john, kate
devteam1 = john, rachel, sally
devteam2 = kate, peter, mark
docs = bob, jane, miguel
training = zak
# Regla de acceso por defecto para TODOS los repositorios
# Todo el mundo puede leer, los administradores pueden escribir,
# Donpe Ligro está exluído.
[/]
* = r
@admin = rw
donpeligro =
# Permitir a los desarrolladores acceso completo
# al repositorio de su proyecto
[proj1:/]
@devteam1 = rw
[proj2:/]
@devteam2 = rw
[bigproj:/]
@devteam1 = rw
@devteam2 = rw
trevor = rw
# Dar a los documentadores acceso de escritura
# a todas las carpetas de documentación
[/trunk/doc]
@docs = rw
# Dar a los becarios acceso de escritura
# sólo al repositorio de pruebas
[TrainingRepos:/]
@training = rw

Tenga en cuenta que comprobar cada ruta puede ser una operación costosa, particularmente en el caso del registro de revisiones. El servidor toma cada ruta cambiada en cada revisión y comprueba si se puede leer, lo que puede ser lento en revisiones que afecten a un gran número de ficheros.

La autentificación y la autorización son procesos separados. Si un usuario desea tener acceso a una ruta de un repositorio, tiene que cumplir ambos requisitos, los requerimientos usuales de autentificación y los requerimientos de autorización del fichero de acceso.

Como habrá notado necesita introducir una entrada usuario/contraseña en el fichero passwd para cada usuario de forma separada. Y si (por razones de seguridad) quiere que sus usuarios cambien periódicamente sus contraseñas tendrá que hacer el cambio de forma manual.

Pero hay una solución a este problema - al menos si accede al repositorio desde dentro de una LAN con un controlador de dominio de Windows: mod_auth_sspi!

El módulo original de SSPI fue ofrecido por Syneapps incluyendo el código fuente. Pero su desarrollo se detuvo. No se desespere, la comunidad lo ha retomado y mejorado. Tiene un nuevo hogar en SourceForge.

Tenga en cuenta que si se autentifica utilizando SSPI, ya no necesitará la línea AuthUserFile para definir un fichero de contraseñas. En su lugar, Apache autentifica su usuario y contraseña contra su dominio de Windows. También necesitará actualizar la lista de usuarios en su svnaccessfile para referirse a DOMINIO\usuario.

También es posible tener más de un origen de autentificación para su repositorio de Subversion. Para conseguirlo, debe hacer que cada tipo de autentificación sea no-autoritario, para que Apache compruebe múltiples orígenes buscando un par usuario/contraseña que concuerden.

Un escenario común es utilizar tanto la autentificación de dominio de Windows como un fichero passwd, para que pueda dar acceso a SVN a usuarios que no tienen usuario en el dominio de Windows.

Aquí tiene un ejemplo de la configuración completa de Apache para combinar la autentificación de dominio de Windows y el fichero passwd:

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\SVN

  AuthName "Repositorios de Subversion"
  AuthzSVNAccessFile svnaccessfile.txt

# Usuarios de Dominio NT.
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative Off
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On

# Usuarios htpasswd.
  AuthType Basic
  AuthBasicAuthoritative Off
  AuthUserFile passwd

  Require valid-user
</Location>

Incluso aunque Apache 2.2.x tiene soporte para OpenSSL, no está activado por defecto. Necesitará activarlo manualmente.

<Location /svn>
  DAV svn
  SVNParentPath D:\SVN
  SSLRequireSSL
  AuthType Basic
  AuthName "Repositorios de Subversion"
  AuthUserFile passwd
  #AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

Enviado a la lista de correo de TortoiseSVN por Nigel Green. ¡Gracias!

En algunas configuraciones de servidor puede que necesite configurar un único servidor que contenga 2 hosts SSL virtuales: el primero para acceso web público, sin requerimientos de un certificado de cliente; el segundo, seguro requiriendo un certificado de cliente, y ejecutando un servidor Subversion.

Al añadir una directiva SSLVerifyClient Optional en la sección por-servidor de la configuración de Apache (es decir, fuera de cualquier bloque VirtualHost y Directory), se fuerza a Apache a pedir un certificado de cliente en el saludo inicial SSL. Debido a un bug en mod_ssl, es esencial que el certificado se pida en este punto, ya que no funciona si la conexión SSL se re-negocia.

La solución es añadir la siguiente directiva en el directorio del host virtual que quiere bloquear para Subversion:

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

Esta directiva da acceso al directorio sólo si se recibió y verificó correctamente un certificado de cliente.

Para resumir, las líneas relevantes de la configuración de Apache son:

SSLVerifyClient Optional

### Configuración del virtual host para el host PÚBLICO 
### (sin necesidad de un certificado de cliente)

<VirtualHost 127.0.0.1:443>
  <Directory "rutaalaraizdeficherospublicos">
  </Directory>
</VirtualHost>

### Configuración del virtual host para SUBVERSION 
### (necesita un certificado de cliente)
<VirtualHost 127.0.0.1:443>
  <Directory "ruta a la raiz del host de subversion">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /rutaalrepositorio
  </Location>
</VirtualHost>

Figura 4.1. Explorador mostrando iconos sobreimpresionados

Una de las funciones más visibles de TortoiseSVN son los iconos sobreimpresionados que aparecen en los ficheros de su copia de trabajo. Estos le muestran de un vistazo qué ficheros han sido modificados. Lea “Iconos sobreimpresionados” para averiguar qué representa cada icono sobreimpresionado.

Figura 4.2. Menú contextual para un directorio bajo el control de versiones

Todos los comandos de TortoiseSVN se invocan desde el menú contextual del explorador de Windows. La mayoría se ven directamente, cuando hace click con el botón derecho en un fichero o una carpeta. Los comandos disponibles dependen de si el fichero o la carpeta o su carpeta padre está bajo el control de versiones o no. También puede ver el menú de TortoiseSVN como parte del menú archivo del explorador.

En algunos casos puede ver varias entradas de TortoiseSVN. ¡Esto no es un error!

Figura 4.3. Menú archivo del explorador para un acceso directo en una carpeta versionada

Este ejemplo es para un acceso directo sin versionar dentro de una carpeta versionada, y en el menú de archivo del Explorador hay tres entradas para TortoiseSVN. Una es para la carpeta, otra para el acceso directo en sí mismo, y otra para el objeto al que apunta el acceso directo. Para ayudarle a distinguir entre ellos, los iconos tienen un indicador en la esquina inferior derecha para mostrarle que la entrada del menú es para un fichero, una carpeta, un acceso directo o para múltiples ítems seleccionados.

Si está utilizando Windows 2000 verá que los menús contextuales se muestran sólo como texto, sin los iconos de menú mostrados arriba. Sabemos que esto funcionaba en las versiones anteriores, pero Microsoft ha cambiado la forma en la que los iconos de menú funcionan en Vista, y eso nos ha forzado a utilizar una forma para mostrarlos que desafortunadamente no funciona en Windows 2000.

Figura 4.4. Menú de arrastre con el botón derecho para un directorio bajo el control de versiones

Otros comandos están disponibles como manejadores de arrastre, cuando arrastra con el botón derecho ficheros o carpetas a un nuevo destino dentro de copias de trabajo, o cuando arrastra con el botón derecho un fichero o una carpeta no versionados a un directorio que está bajo el control de versiones.

Algunas operaciones comunes tienen atajos de Windows bien conocidos, pero no aparecen en botones o en los menús. Si no puede averiguar cómo hacer algo obvio, como refrescar una vista, mire aquí.

Si el repositorio al que intenta acceder está protegido por contraseña, aparecerá un diálogo de autentificación.

Figura 4.5. Diálogo de autentificación

Introduzca su usuario y contraseña. La casilla le permite que TortoiseSVN almacene las credenciales en el directorio por defecto de Subversion: %APPDATA%\Subversion\auth, en tres subdirectorios:

Si desea eliminar la caché de autentificación para todos los servidores, puede hacerlo desde la página Datos Almacenados del diálogo de configuración de TortoiseSVN. Ese botón borrará todos los datos de autentificación cacheados de los directorios auth de Subversion, así como cualquier dato de autentificación almacenado en el registro por versiones anteriores de TortoiseSVN. Lea “Datos de configuración almacenados”.

If you want to clear authentication for one realm only then you will have to dig into those directories, find the file which contains the information you want to clear and delete the file.

Algunas personas quieren que se eliminen sus datos de autenticación cuando cierran su sesión de Windows, o cuando apagan el sistema. La forma de conseguir esto es utilizar un script de cierre para eliminar el directorio %APPDATA%\Subversion\auth, por ejemplo

@echo off
rmdir /s /q "%APPDATA%\Subversion\auth"

Puede encontrar una descripción sobre cómo instalar este tipo de scripts en windows-help-central.com.

Para más información sobre cómo preparar su servidor para la autentificación y el control de acceso, vea “Accediendo al repositorio”

Muchos de los diálogos de TortoiseSVN tienen montones de información que mostrar, pero a menudo es más útil maximizar sólo la altura o sólo la anchura, mejor que maximizar para ocupar toda la pantalla. Como ayuda existen atajos para esto en el botón Maximizar. Utilice el botón central del ratón para maximizar verticalmente, y el botón derecho del ratón para maximizar horizontalmente.

Si está importando en un repositorio que ya tiene algunos proyectos, entonces la estructura del repositorio ya estará decidida. Si está importando datos a un nuevo repositorio entonces merece la pena tomar el tiempo para pensar en cómo debería organizarse. Lea “Organización del repositorio” para más información.

Esta sección describe el comando importar de Subversion, que fue diseñado para importar una jerarquía de directorios en el repositorio de una vez. Aunque funciona, tiene algunos inconvenientes:

Por estas razones le recomendamos que no utilice el comando importar en absoluto, y en cambio siga el método de dos pasos descrito en “Importar en el sitio”. Pero dado que ya está aquí, así es como funciona el comando importar básico ...

Antes de importar su proyecto en un repositorio debería:

Ahora seleccione la carpeta superior de la estructura de directorios del proyecto en el explorador de Windows, y haga click con el botón derecho para abrir el menú contextual. Seleccione el comando TortoiseSVN → Importar... y aparecerá un cuadro de diálogo:

Figura 4.6. El diálogo Importar

En este diálogo tiene que introducir la URL del lugar del repositorio donde desea importar su proyecto. Es muy importante darse cuenta de que la carpeta local que está importando no aparece en sí misma en el repositorio, sólo su contenido. Por ejemplo, si tiene una estructura:

C:\Proyectos\Widget\source
C:\Proyectos\Widget\doc
C:\Proyectos\Widget\images

e importa C:\Proyectos\Widget en http://mydomain.com/svn/trunk entonces puede que se sorprenda al encontrar que sus subdirectorios van directos a trunk en vez de estar en un subdirectorio Widget. Necesita especificar el subdirectorio como parte de la URL, http://mydomain.com/svn/trunk/Widget-X. Tenga en cuenta que el comando importar automáticamente crea los subdirectorios en el repositorio si no existen.

El mensaje de importación se utiliza como un mensaje de registro.

Por defecto, los ficheros y carpetas que concuerden con los patrones globales de ignorar no se importan. Para cambiar este comportamiento, puede utilizar la casilla Incluir ficheros ignorados. Lea “Configuración general” para más información sobre cómo establecer un patrón global de ignorar.

Tan pronto como presione Aceptar, TortoiseSVN importa el árbol completo de directorios, incluyendo todos los ficheros, en el repositorio. El proyecto ahora está almacenado en el repositorio bajo el control de versiones. Por favor tenga en cuenta que la carpeta que ha importado ¡NO está bajo el control de versiones! Para obtener una copia de trabajo bajo el control de versiones necesita Obtener la versión que acaba de importar. O siga leyendo para averiguar cómo importar una carpeta en el sitio.

Asumiendo que ya tiene un repositorio, y que quiere añadir una nueva estructura de carpetas e él, sólo tiene que seguir estos pasos:

A veces necesitará tener un fichero bajo control de versiones que contenga datos específicos del usuario. Esto significa que tiene un fichero que cada desarrollador/usuario necesita modificar para que se ajuste a su configuración local. Pero versionar ese fichero es dificil, porque cada usuario haría confirmaciones de sus cambios cada vez en el repositorio.

En estos casos le sugerimos que utilice ficheros plantilla. Cree un fichero que contenga todos los datos que sus desarrolladores puedan necesitar, añádalo al control de versiones y haga que sus desarrolladores lo obtengan. Luego, cada desarrollador tendrá que hacer una copia de ese fichero y renombrar esa copia. Después de eso, modificar la copia no vuelve a ser un problema.

Por poner un ejemplo, puede mirar el script de compilación de TortoiseSVN. Se invoca a un fichero llamado TortoiseVars.bat que no existe en el repositorio. Sólo existe el fichero TortoiseVars.tmpl. TortoiseVars.tmpl es el fichero plantilla del que cada desarrollador tiene que hacer una copia y cambiarla de nombre a TortoiseVars.bat. Dentro de ese fichero, hemos añadido comentarios para que los usuarios vean qué lineas tienen que editar y cambiar de acuerdo a sus configuraciones locales para que funcione.

Para no molestar a los usuarios, también hemos añadido el fichero TortoiseVars.bat a la lista de ignorados de su carpeta padre, es decir, hemos cambiado la propiedad de Subversion svn:ignore para incluir ese nombre de fichero. De esta forma no se mostrará como no versionado en cada confirmación.

Puede elegir la profundidad que desea para la obtención, lo que le permite especificar la profundidad de la recusión en las carpetas hijas. Si sólo desea unas pocas secciones de un árbol grande, puede obtener sólo la carpeta de más alto nivel, y luego actualizar las carpetas seleccionadas de forma recursiva.

Si obtiene una copia de trabajo dispersa (por ejemplo seleccionando cualquier otra opción distinta de totalmente recursivo para la profundidad de la obtención), puede conseguir sub-carpetas adicionales utilizando el Navegador de repositorios (“El navegador de repositorios”) o el diálogo Comprobar modificaciones (“Estado local y remoto”).

En el navegador de repositorios, haga click con el botón derecho en la carpeta donde ha ejecutado obtener, y luego utilice TortoiseSVN → Navegador de repositorios para lanzar el diálogo. Localice la subcarpeta que desea añadir a su copia de trabajo, y utilice Menú contextual → Actualizar ítem a la revisión... Este menú sólo será visible si el ítem seleccionado no existe aún en su copia de trabajo, mientras que el ítem padre sí existe.

En el diálogo Comprobar modificaciones, primero haga click en el botón Comprobar repositorio. El diálogo mostrará como añadido remotamente todos los ficheros y carpetas que están en el repositorio pero que aún no se han obtenido. Haga click con el botón derecho sobre la carpeta o carpetas que desea añadir a su copia de trabajo, y luego utilice Menú contextual → Actualizar.

Esta característica es muy útil si sólo desea obtener partes de un árbol más grande, pero desea la facilidad de poder actualizar una única copia de trabajo. Suponga que tiene un gran árbol que tiene subcarpetas desde Proyecto01 a Proyecto99, y sólo desea obtener las carpetas Proyecto03, Proyecto25 y Proyecto76/SubProy. Utilice estos pasos:

Si su copia de trabajo está actualizada y no hay conflictos, ya está preparado para confirmar sus cambios. Seleccione los ficheros y/o carpetas que desee confirmar y seleccione TortoiseSVN → Confirmar....

Figura 4.8. El diálogo de Confirmación

El diálogo de confirmación le mostrará todos los ficheros cambiados, incluso los ficheros añadidos, borrados o no versionados. Si no desea que un fichero cambiado se confirme, símplemente desmarque ese fichero. Si desea incluir un fichero no versionado, márquelo para añadirlo a la confirmación.

Los ítems que han sido cambiados a una ruta de repositorio diferente también se indican utilizando un marcador (s). Puede haber cambiado algo mientras trabaja en una rama y habérsele olvidado volver a cambiarlo al tronco. ¡Este es su signo de advertencia!

Si ha modificado ficheros que han sido incluidos desde un repositorio diferente utilizando svn:externals, esos cambios no pueden ser incluídos en la misma confirmación atómica. Aparecerá un símbolo de advertencia bajo la lista de ficheros que le indicará si esto ha ocurrido, y el texto de ayuda le explicará que esos ficheros externos deben confirmarse de forma separada.

Haciendo doble click en cualquier fichero modificado en el diálogo de confirmación, se lanzará la herramienta externa de diferenciar para mostrarle sus cambios. El menú contextual le proporciona más opciones, como se ve en la captura de pantalla. También puede arrastrar ficheros desde aquí a otra aplicación, como un editor de textos o un IDE.

Puede seleccionar o deseleccionar ítems haciendo click en la casilla a la izquierda del ítem. Para los directorios puede utilizar Mayúsculas-Seleccionar para ejecutar la acción de forma recursiva.

Las columnas que se muestran en el panel inferior son personalizables. Si hace click con el botón derecho en cualquier cabecera de columna verá un menú contextual que le permite seleccionar qué columnas se muestran. También puede cambiar el ancho de la columna utilizando el manejador de arrastre que aparece cuando mueve el cursor sobre el límite de una columna. Estas personalizaciones se mantienen, por lo que verá los mismos encabezados la siguiente vez.

Por defecto cuando confirma los cambios, cualquier bloqueo que tenga en los ficheros se libera automáticamente cuando la confirmación tiene éxito. Si desea mantener esos bloqueos, asegúrese de que la casilla Mantener bloqueos está marcada. El estado por defecto de esta casilla se toma de la opción no_unlock del fichero de configuración de Subversion. Lea “Configuración general” para más información sobre cómo editar el fichero de configuración de Subversion.

El diálogo de confirmación da soporte a las listas de cambios de Subversion para ayudar a agrupar ficheros relacionados. Averigue más sobre esta característica en “Listas de cambios”.

A veces tiene ficheros versionados que cambian con frecuencia pero que realmente no desea confirmar. En ocasiones esto indica un fallo en su sistema de compilación - ¿por qué están esos ficheros versionados? ¿debería utilizar ficheros de plantilla? Pero ocasionalmente es inevitable. Una razón clásica es que su IDE cambie una fecha en el fichero de proyecto cada vez que lo compile. El fichero de proyecto debe estar versionado ya que contiene todas las configuraciones de la compilación, pero no necesita confirmarse sólo porque la fecha haya cambiado.

Para ayudarle en casos tan extraños como estos, hemos reservado una lista de cambios llamada ignore-on-commit. Cualquier fichero añadido a esta lista de cambios se desmarcará automáticamente en el diálogo de confirmación. Aún puede confirmar los cambios, pero tendrá que selecionarlo manualmente en el diálogo de confirmación.

Asegúrese de introducir un mensaje de registro que describa los cambios que está confirmando. Esto le ayudará a saber qué ocurrió y cuando según navegue por los mensajes de registro del proyecto en el futuro. El mensaje puede ser tan extenso o escueto como desee; muchos proyectos tienen directrices sobre qué debe incluirse en ellos, el idioma que debe utilizarse, y a veces incluso un formato estricto.

Puede aplicar formatos sencillos en sus mensajes de registro utilizando una convención similar a la usada en los emails. Para aplicar un estilo a un texto, utilice *texto* para la negrita, _texto_ para el subrayado, y ^texto^ para la cursiva.

Figura 4.9. El corrector ortográfico del diálogo de Confirmación

TortoiseSVN incluye un corrector ortográfico para ayudarle a escribir sus mensajes de registro correctamente. Este corrector señalará cualquier palabra mal escriba. Utilice el menú contextual para acceder a las correcciones sugeridas. Por supuesto, el corrector no conoce todos los términos técnicos que utiliza, así que a veces palabras bien escritas aparecerán como errores. Pero no se preocupe. Puede simplemente añadirlas a su diccionario personal utilizando el menú contextual.

La ventana de mensajes de registro también incluye una facilidad de autocompletar nombres de ficheros y funciones. Esto utiliza expresiones regulares para extraer clases y nombres de funciones de los ficheros (de texto) que está confirmando, y también los propios nombres de ficheros. Si una palabra que está tecleando concuerda con algo en la lista (después de haber tecleado al menos 3 caracteres, o de pulsar Ctrl+Espacio), aparecerá un desplegable que le permitirá seleccionar el nombre completo. Las expresiones regulares suministradas con TortoiseSVN se mantienen en la carpeta bin de la instalación de TortoiseSVN. También puede definir sus propias expresiones regulares y almacenarlas en %APPDATA%\TortoiseSVN\autolist.txt. Por supuesto su lista privada no se sobreescribirá cuando actualice su instalación de TortoiseSVN. Si no está familiarizado con las expresiones regulares, eche un vistazo a la documentación en http://en.wikipedia.org/wiki/Regular_expression, y a la documentación en línea y al tutorial en http://www.regular-expressions.info/.

Getting the regex just right can be tricky, so to help you sort out a suitable expression there is a test dialog which allows you to enter an expression and then type in filenames to test it against. Start it from the command prompt using the command TortoiseProc.exe /command:autotexttest

Puede reutilizar mensajes de registro que haya introducido anteriormente. Tan sólo debe pulsar en Mensajes recientes para ver una lista de los últimos mensajes que ha introducido para esta copia de trabajo. El número de mensajes almacenados se puede personalizar en el diálogo de configuración de TortoiseSVN.

Puede limpiar todos los mensajes de confirmación almacenados desde la página Datos Almacenados de la configuración de TortoiseSVN, o puede eliminar mensajes individuales dentro del diálogo Mensajes recientes utilizando la tecla Supr.

Si desea incluir las rutas marcadas en su mensaje de registro, puede utilizar el comando Menú contextual → Pegar lista de nombres de ficheros en el control de edición.

Otra forma de insertar rutas en el mensaje de registro es simplemente arrastrar los ficheros desde la lista de ficheros al control de edición.

Tras pulsar Aceptar aparece un diálogo mostrando el progreso de la confirmación.

Figura 4.10. El diálogo Progreso mostrando el progreso de una confirmación

El diálogo de progreso utiliza una codificación de colores para resaltar las diferentes acciones de confirmación:

Este es el esquema de colores por defecto, pero puede personalizar dichos colores utilizando el diálogo de configuración. Para más información, lea “Configuración de colores de TortoiseSVN”.

Un conflicto de fichero ocurre cuando uno o más desarolladores han hecho cambios en las mismas líneas de un fichero. Dado que Subversion no sabe nada de su proyecto, delega la resolución de los conflictos en los desarrolladores. Cuando se le informa de un conficto, debería abrir el fichero en cuestión, y buscar líneas que empiecen con el texto <<<<<<<. El área conflictiva se marca así:

	<<<<<<< nombre-del-fichero
		sus cambios
	=======
		código fusionado del repositorio
	>>>>>>> revisión

Además, para cada fichero en conflicto Subversion deja tres ficheros adicionales en su directorio:

Puede o bien lanzar una herramienta externa de fusiones / editor de conflictos con el menú contextual TortoiseSVN → Editar Conflictos o bien utilizar otro editor manualmente para resolver el conflicto. Debe decidir cómo tiene que quedar el código, hacer los cambios necesarios, y grabar el fichero.

Después, ejecute el comando TortoiseSVN → Resolver y confirme sus modificaciones al repositorio. Tome nota de que el comando Resolver realmente no resuelve el conflicto. Simplemente elimina los ficheros filename.ext.mine y filename.ext.r*, dejándole confirmar sus cambios.

Si tiene conflictos con ficheros binarios, Subversion no intentará mezclar dichos ficheros por si mismo. El fichero local se mantendrá sin cambios (exactamente tal y como lo había cambiado usted) y obtendrá unos ficheros nombrefichero.ext.r*. Si desea descartar sus cambios y quedarse con la versión del repositorio, utilice el comando Revertir. Si desea mantener su versión y sobreescribir la versión del repositorio, utilice el comando Resuelto y luego confirme su versión.

Puede utilizar el comando Resuelto para múltiples ficheros si pulsa con el botón derecho en la carpeta padre y selecciona TortoiseSVN → Resuelto... Esto mostrará un diálogo con todos los ficheros en conflicto dentro de esa carpeta, y le permitirá seleccionar cuáles marcar como resueltos.

Un conflicto de árbol ocurre cuando un desarrollador mueve/renombra/elimina un fichero o una carpeta, que otro desarrollador también ha movido/renombrado/borrado, o quizás lo haya modificado. Hay diferentes situaciones que puede resultar en un conflicto de árbol, y todas ellas requiere pasos diferentes para resolver el conflicto.

Cuando se elimina un fichero de forma local en Subversion, el fichero también se elimina del sistema local de ficheros, por lo que incluso si es parte de un conflicto de árbol no se puede mostrar una sobreimpresión de conflicto y no puede hacer clic con el botón derecho sobre él para resolver el conflicto. En este caso, utilice el diálogo Comprobar modificaciones para acceder a la opción Editar conflictos.

TortoiseSVN puede ayudarle a encontrar el lugar correcto para fusionar los cambios, pero puede que necesite realizar un trabajo adicional para arreglar los conflictos. Recuerde que tras una actualización la BASE de trabajo siempre contendrá la revisión de cada ítem tal y como estaba en el repositorio en el momento de la actualización. Si revierte un cambio tras la actualización, se revierte a su estado del repositorio, no a como estaba cuando empezó a hacer sus propios cambios locales.

Figura 4.12. Explorador mostrando iconos sobreimpresionados

Ahora que ha obtenido una copia de trabajo desde un repositorio de Subversion, puede ver sus ficheros en el explorador de Windows con los iconos cambiados. Ésta es una de las razones por las que TortoiseSVN es tan popular. TortoiseSVN añade lo que se llama un icono sobreimpresionado al icono de cada fichero que se superpone al icono original del fichero. Dependiendo del estado en Subversion del fichero, el icono sobreimpresionado es diferente.

Una copia de trabajo recién obtenida tiene una marca verde como sobreimpresión. Esto significa que el estado de Subversion es normal.

En cuanto empiece a editar un fichero, el estado cambia a modificado y el icono sobreimpresionado cambia entonces a una marca de exclamación roja. De esta forma puede ver fácilmente qué ficheros se han cambiado desde la última vez que actualizó su copia de trabajo, y que necesitan ser confirmados.

Si durante una actualización ocurre un conflicto, el icono cambia a un signo de exclamación amarillo.

Si ha establecido la propiedad svn:needs-lock en un fichero, Subversion establece ese fichero como de sólo-lectura hasta que obtenga un bloqueo en él. Estos ficheros tienen esta sobreimpresión para indicarle que debe obtener un bloqueo antes de que pueda editarlo.

Si ha obtenido un bloqueo sobre un fichero, y el estado de Subversion es normal, este icono sobreimpresionado le recordará que debería liberar el bloqueo si no lo está utilizando para permitir a los demás que puedan confirmar sus cambios en el fichero.

Este icono le muestra que algunos ficheros o carpetas dentro de la carpeta actual se han marcado para ser eliminados del control de versiones, o bien que falta un fichero que está bajo el control de versiones dentro de una carpeta.

El signo más le indica que el fichero o carpeta está programado para ser añadido al control de versiones.

La barra le indica que el fichero o carpeta está ignorado para los asuntos de control de versiones. Esta sobreimpresión es opcional.

Este icono muestra los archivos y carpetas que no están bajo el control de versiones pero tampoco han sido ignorados. Esta sobreimpresión es opcional.

De hecho, puede que se encuentre con que no todos estos iconos se utilizan en su sistema. Esto se debe a que el número de sobreimpresiones permitidas por Windows está muy limitado y si está utilizando también una versión antigua de TrotoiseCVS, entonces no hay suficientes huecos de sobreimpresión disponibles. TortoiseSVN intenta ser un “Buen Ciudadano (TM)” y limita su uso de sobreimpresiones para darles una oportunidad al resto de aplicaciones.

Ahora que hay más clilentes Tortoise por ahí (TortoiseCVS, TortoiseHG, ...) el límite de iconos se ha convertido en un problema real. Para evitarlo, el proyecto TortoiseSVN ha introducido un conjunto compartido común de iconos, cargado como una DLL, que puede ser usado por todos los clientes Tortoise. Compruebe con el proveedor de su cliente para ver si esto ya se ha integrado :-)

Si desea una descripción de cómo se corresponden las sobreimpresiones con los estados de Subversion y otros detalles técnicos, lea “Iconos sobreimpresionados”.

Se puede ver la misma información que está disponible en los iconos sobreimpresionados (y mucha más) como columnas adicionales en la Vista Detalles del Explorador de Windows.

Simplemente haga click con el botón derecho en la cabecera de una columna y seleccione Más... en el menú contextual que aparece. Se mostrará un diálogo donde puede especificar las columnas que se mostrarán en la “vista Detalles”, y su orden. Baje hasta que vea las entradas que empiezan por SVN. Marque aquellas que desee mostrar y cierre el diálogo pulsando Aceptar. Las columnas aparecerán a la derecha de las que ya se mostraban. Puede reorganizarlas utilizando arrastrar y soltar, o cambiarlas de tamaño, para que se ajusten a sus necesidades.

Figura 4.13. Comprobar modificaciones

A menudo es muy útil saber qué ficheros ha cambiado y también qué ficheros han cambiado y confirmado los demás. Ahí es donde viene bien el comando TortoiseSVN → Comprobar Modificaciones.... Este diálogo le muestra todos los ficheros que ha cambiado de alguna forma en su copia de trabajo, y además todos los ficheros no versionados que pueda tener.

Si pulsa en el botón Comprobar Repositorio también puede comprobar los cambios en el repositorio. De esa forma puede comprobar antes de hacer una actualización si es posible que haya un conflicto. También puede actualizar ficheros concretos desde el repositorio sin actualizar la carpeta completa. Por defecto, el botón Comprobar Repositorio sólo obtiene el estado remoto con la profundidad obtenida de la copia de trabajo. Si desea ver todos los ficheros y carpetas del repositorio, incluso aquellas que no ha obtenido, entonces tendrá que pulsar la tecla Mays mientras hace click en el botón Comprobar Repositorio.

El diálogo utiliza un código de colores para resaltar el estado.

Este es el esquema de colores por defecto, pero puede personalizar dichos colores utilizando el diálogo de configuración. Para más información, lea “Configuración de colores de TortoiseSVN”.

Los ítems que han sido cambiados a una ruta de repositorio diferente también se indican utilizando un marcador (s). Puede haber cambiado algo mientras trabaja en una rama y habérsele olvidado volver a cambiarlo al tronco. ¡Este es su signo de advertencia!

Desde el menú contextual del diálogo puede mostrar un resumen de los cambios. Compruebe los cambios locales que usted ha hecho utilizando Menú Contextual → Comparar con Base. Compruebe los cambios en el repositorio hechos por los demás utilizando Menú Contextual → Mostrar Diferencias como Diff Unificado.

También puede revertir cambios en ficheros individuales. Si ha borrado un fichero de forma accidental, se mostrará como Falta y puede utilizar

Los ficheros sin versionar y los ignorados se pueden enviar a la papelera de reciclaje desde aquí utilizando Menú Contextual → Eliminar. Si quiere eliminar los ficheros de forma definitiva (sin utilizar la papelera de reciclaje) pulse la tecla Mayúsculas mientras hace click en Eliminar.

Si desea examinar un fichero más en detalle, puede arrastrarlo desde aquí a otra aplicación, tal como un editor de textos o un IDE.

Las columnas son personalizables. Si hace click con el botón derecho en cualquier cabecera de columna verá un menú contextual que le permite seleccionar qué columnas se muestran. También puede cambiar el ancho de la columna utilizando el manejador de arrastre que aparece cuando mueve el cursor sobre el límite de una columna. Estas personalizaciones se mantienen, por lo que verá los mismos encabezados la próxima vez.

Si está trabajando al mismo tiempo en varias tareas sin relacion entre ellas, también puede agrupar los ficheros juntos en listas de cambios. Para más información, lea “Listas de cambios”.

En la parte inferior del diálogo puede ver un sumario del rango de revisiones del repositorio en uso en su copia de trabajo. Estas son revisiones confirmadas, no las revisiones actualizadas; representan el rango de revisiones donde estos ficheros fueron confirmados por última vez, no las revisiones a las que se han actualizado. Tenga en cuenta que el rango de revisiones mostrado se aplica sólo a los ítems mostrados, no a la copia de trabajo completa. Si quiere ver esa información para la copia de trabajo completa debe seleccionar la casilla Mostrar ficheros no modificados.

A menudo querrá mirar dentro de sus ficheros, para echar un vistazo a lo que ha cambiado. Puede llevar esto a cabo seleccionando un fichero que haya cambiado, y seleccionando Diferenciar desde el menú contextual de TortoiseSVN. Esto inicia el visor externo de diferencias, que comparará el fichero actual con la copia prístina (revisión BASE), que se guardó tras su obtención o tras la última actualización.

Figura 4.15. El diálogo de Registro de revisiones

Hay varios lugares desde los que puede mostrar el diálogo de Registro:

Si el repositorio no está disponible verá el diálogo ¿Desea trabajar sin conexión?, descrito en “Modo sin conexión”.

El panel superior tiene una columna Acciones que contiene iconos que resumen qué se ha hecho en esa revisión. Hay cuatro iconos diferentes, cada uno mostrado en su propia columna.

Si una revisión modificó un fichero o un directorio, se muestra el icono modificado en la primera columna.

Si en una revisión se añadió un fichero o directorio, se muestra el icono añadido en la segunda columna.

Si en una revisión se eliminó un fichero o directorio, se muestra el icono eliminado en la tercera columna.

Si una revisión reemplazó un fichero o un directorio, se muestra el icono reemplazado en la cuarta columna.

Figura 4.16. El panel superior del diálogo de Registro de revisiones con el menú contextual

El panel superior del diálogo de Registro tiene un menú contextual que le permite acceder a mucha más información. Algunas de las entradas de este menú aparecen sólo cuando se muestra el registro de un fichero, y algunas sólo cuando se muestra el registro de una carpeta.

Figura 4.17. Menú contextual del panel superior para 2 revisiones seleccionadas

Si selecciona dos revisiones a la vez (utilizando el modificador habitual Ctrl), el menú contextual cambia y le ofrece menos opciones:

Si selecciona dos o más revisiones (utilizando los modificadores habituales Ctrl o Mayúsculas), el menú contextual incluirá una entrada para revertir todos los cambios que se hicieron en ese rango de revisiones. Ésta es la forma más sencilla para deshacer un grupo de revisiones de golpe.

También puede elegir fusionar en otra copia de trabajo las revisiones seleccionadas, como se describió más arriba.

Si todas las revisiones seleccionadas tienen el mismo autor, puede editar el autor de todas esas revisiones de un golpe.

Figura 4.18. El panel inferior del diálogo de Registro con el menú contextual

El panel inferior del diálogo Registro también tiene un menú contextual que le permite

El diálogo Registro no siempre le muestra todos los cambios que se hayan hecho alguna vez por unos cuantos motivos:

Si desea ver más mensajes de registro, pulse Siguientes 100 para obtener los siguientes 100 mensajes de registro. Puede repetir ésto tantas veces como sea necesario.

Al lado de este botón hay un botón multifunción que recuerda la última opción que utilizó. Pulse en la flecha para ver las otras opciones ofrecidas.

Utilice Mostrar rango ... si desea ver un rango específico de revisiones. Aparecerá un diálogo que le preguntará por la revisión de inicio y de fin.

Utilice Mostrar Todos si desea ver todos los mensajes de registro desde HEAD hasta la revisión 1.

Dado que el diálogo de registro le muestra el registro desde HEAD, no desde la revisión actual de la copia de trabajo, a veces ocurre que se muestran mensajes de registro para contenidos que aún no han sido actualizados en su copia de trabajo. Para ayudar a mostrar esto más claro, el mensaje de confirmación que corresponde a la revisión que tiene en su copia de trabajo se muestra en negrita.

When you show the log for a folder the revision highlighted is the highest revision found anywhere within that folder, which requires a crawl of the working copy. The crawl takes place within a separate thread so as not to delay showing the log, but as a result highlighting for folders may not appear immediately.

Subversion 1.5 y posteriores almacenan un registro de las fusiones utilizando propiedades. Esto nos permite obtener una historia más detallada de los cambios fusionados. Por ejemplo, si desarrolla una nueva característica en una rama y luego la fusiona en el tronco, la característica desarrollada aparecerá en el historial de registro del tronco como una única confirmación para la fusión, incluso aunque haya habido 1000 confirmaciones durante el desarrollo de la rama.

Figura 4.19. El diálogo de registro mostrando revisiones con registro de fusión

Si desea ver el detalle de qué revisiones se fusionaron como parte de esa confirmación, utilice la casilla Incluir revisiones fusionadas. Esto obtendrá los mensajes de registro de nuevo, pero también intercalará los mensajes de registro desde las revisiones que se fusionaron. Las revisiones fusionadas se muestran en gris porque representan cambios hechos en una parte diferente del árbol.

¡Por supuesto que fusionar nunca es sencillo! Durante el desarrollo de la rama habrá probablemente fusiones ocasionales desde el tronco para mantener la rama en sincronía con la línea principal del código. Por eso la historia de fusiones de la rama también incluirá otra capa de historia de fusiones. Estas capas se muestran en el diálogo de registro utilizando niveles de indentación.

Las propiedades de revisión son completamente diferentes de las propiedades Subversion de cada ítem. Las propiedades de revisión (revprops) son ítems descriptivos que están asociados con un número de revisión en concreto en el repositorio, como el mensaje de registro, la fecha de confirmación o el nombre del confirmador (autor).

A veces querrá cambiar un mensaje de registro que introdujo en su día, quizás porque hay un error ortográfico en él o porque quiere mejorar el mensaje o cambiarlo por otras razones. O quizás quiera cambiar el autor de una confirmación porque se le olvidó preparar la autentificación, o ...

Subversion le permite cambiar las propiedades de la revisión en cualquier momento. Pero como estos cambios no se pueden deshacer (estos cambios no se versionan), esta característica está deshabilitada por defecto. Para hacer que ésto funcione, debe preparar un gancho pre-revprop-change. Por favor consulte el capítulo sobre Scripts gancho en el Libro de Subversion para tener más detalles sobre cómo hacerlo. Lea “Scripts gancho en el lado del servidor” para encontrar más notas sobre cómo implementar ganchos en una máquina Windows.

Una vez que haya preparado su servidor con los ganchos necesarios, puede cambiar tanto el autor como el mensaje de registro (o cualquier otra propiedad de revisión) de cualquier revisión, utilizando el menú contextual del panel superior del diálogo Registro. También puede editar un mensaje de registro utilizando el menú contextual del panel del medio.

Si desea restringir los mensajes de registro para mostrar sólo en los que está interesado en vez de tener que navegar en una lista de cientos, puede utilizar los controles de filtro en la parte superior del Diálogo de Registro. Los controles de fecha de inicio y de fin le permite restringir la salida a un rango de fechas conocido. La caja de texto de búsqueda le permite mostrar sólo los mensajes que contengan una frase en particular.

Click on the search icon to select which information you want to search in, and to choose regex mode. Normally you will only need a simple sub-string search, but if you need to more flexible search terms, you can use regular expressions. If you hover the mouse over the box, a tooltip will give hints on how to use the regex functions, or the sub-string functions. The filter works by checking whether your filter string matches the log entries, and then only those entries which match the filter string are shown.

Simple sub-string search works in a manner similar to a search engine. Strings to search for are separated by spaces, and all strings must match. You can use a leading - to specify that a particular sub-string is not found (invert matching for that term), and you can use ! at the start of the expression to invert matching for the entire expression. You can use quote marks to surround a string which must contain spaces, and if you want to search for a literal quotation mark you can use two quotation marks together as a self-escaping sequence. Note that the backslash character is not used as an escape character and has no special significance in simple sub-string searches. Examples will make this easier:

Alice Bob -Eve

searches for strings containing both Alice and Bob but not Eve

!Alice Bob

searches for strings which do not contain both Alice and Bob

!-Alice -Bob

do you remember De Morgan's theorem? NOT(NOT Alice AND NOT Bob) reduces to (Alice OR Bob).

"Alice and Bob"

searches for the literal expression “Alice and Bob”

""

searches for a double-quote anywhere in the text

"Alice says ""hi"" to Bob"

searches for the literal expression “Alice says "hi" to Bob”

Describing the use of regular expression searches is beyond the scope of this manual, but you can find online documentation and a tutorial at http://www.regular-expressions.info/.

Tenga en cuenta que estos filtros actúan sobre los mensajes ya obtenidos. Ellos no controlan la descarga de mensajes desde el repositorio.

You can also filter the path names in the bottom pane using the Show only affected paths checkbox. Affected paths are those which contain the path used to display the log. If you fetch the log for a folder, that means anything in that folder or below it. For a file it means just that one file. Normally the path list shows any other paths which are affected by the same commit, but in grey. If the box is checked, those paths are hidden.

A veces sus prácticas de trabajo requerirán que los mensajes de registro sigan un formato particular, lo que significa que el texto que describe los cambios no es visible desde el sumario abreviado mostrado en el panel superior. La propiedad tsvn:logsummary puede utilizarse para extraer una porción del mensaje de registro que se mostrará en el panel superior. Lea “Propiedades de projecto TortoiseSVN” para saber cómo se utiliza esta propiedad.

El botón Estadísticas lanza un cuadro de diálogo que muestra algunas informaciones interesantes sobre las revisiones que se muestran en el diálogo Registro. Le muestra cuántos autores han estado trabajando, cuántas confirmaciones han hecho, el progreso por semanas, y mucho más. Ahora puede ver de un vistazo quién ha trabajado duro y quién se ha tocado la barriga ;-)

Página de confirmaciones por autor

Figura 4.20. Histograma de confirmaciones por autor

Este gráfico le muestra qué autores han estado activos en el proyecto como un simple histograma, un histograma apilado o un gráfico de tarta.

Figura 4.21. Gráfico de tarta de confirmaciones por autor

Cuando hay unos pocos autores muy activos y muchos pequeños contribuyentes, el número de segmentos pequeños puede hacer que el gráfico sea más dificil de leer. El selector deslizante en la parte inferior le permite establecer un límite (el porcentaje sobre el total de confirmaciones) bajo el cual cualquier actividad se agrupa en una categoría Otros.

Página de confirmaciones por fecha

Figura 4.22. Gráfico de confirmaciones por fecha

Esta página proporciona una representación gráfica de la actividad del proyecto en términos del número de confirmaciones y autor. Esto da una idea de cuándo se ha trabajado en un proyecto, y quién estaba trabajando en cada momento.

Cuando hay varios autores, puede obtener muchas líneas en el gráfico. Hay dos vistas disponibles aquí: normal, en la que la actividad de cada autor se refiere a la línea base, y apilado, donde la actividad de cada autor se refiere a la línea subyacente. La última opción evita que se crucen las líneas, lo que puede permitir un gráfico más sencillo de leer, pero es menos fácil ver la salida de cada autor.

Por defecto el análisis distingue mayúsculas y minúsculas, por lo que los usuarios PeterEgan y PeteRegan se tratan como autores diferentes. Sin embargo, en muchos casos los nombres de usuario no distinguen mayúsculas y minúsculas, y a veces se introducen de forma inconsistente, por lo que puede querer que DavidMorgan y davidmorgan se traten como la misma persona. Utilice la casilla Autores sin importar mayús/minús para controlar este comportamiento.

Tenga en cuenta que las estadísticas cubren el mismo período que el diálogo Registro. Si sólo se está mostrando una revisión, las estadísticas no le dirán mucho.

Figura 4.23. Go Offline Dialog

If the server is not reachable, and you have log caching enabled you can use the log dialog and revision graph in offline mode. This uses data from the cache, which allows you to continue working although the information may not be up-to-date or even complete.

Here you have three options:

La casilla de opción Hacer este el default evita que este diálogo reaparezca y siempre elegirá la opción que usted escoja a continuación. En cualquier momento, usted puede cambiar (o remover) el default despues de llevar a cabo esta acción desde TortoiseSVN → Settings.

Si desea comprobar el servidor de nuevo para obtener los mensajes de registro más recientes, puede simplemente refrescar la vista utilizando F5. Si está utilizando la caché de registro (habilitada por defecto), esto buscará en el repositorio los mensajes más recientes y traerá sólo los nuevos. Si la caché de registro estaba en modo desconectado, esto intentará volver a ponerla en línea.

Si está utilizando la caché de registros y cree que el contenido del mensaje o el autor han podido cambiar, puede utilizar Mays-F5 o Ctrl-F5 para re-obtener los mensajes mostrados desde el servidor y actualizar la caché de registro. Tenga en cuenta que esto sólo afecta a los mensajes que se están mostrando actualmente y que por tanto no invalida la caché completa de ese repositorio.

Si ha configurado una herramienta de diferenciado de terceros, puede utilizar Mayúsculascuando seleccione el comando Diferenciar para utilizar la herramienta alternativa. Lea “Configuración de programas externos” para saber más sobre configurar otras herramientas de diferenciación.

A veces en la vida de un proyecto puede querer cambiar los fines de línea de CRLF a LF, o puede querer cambiar la indentación de una sección. Desafortunadamente esto marcará un gran número de líneas como modificadas, incluso aunque no haya cambios en el significado del código. Estas opciones le ayudarán a administrar estos cambios cuando se comparan y aplican diferencias. Verá estas opciones en los diálogos Fusionar y Autoría, además de en la configuración de TortoiseMerge.

Ignorar finales de línea excluye los cambios que sólo se deban a diferencias en el estilo de fin de línea.

Comparar espacios en blanco incluye todos los cambios en la indentación y en los espacios en blanco interiores como líneas añadidas/eliminadas.

Ignorar cambios en espacios en blanco excluye los cambios que sólo se deben a un cambio en la cantidad o tipo de espacios en blanco, como por ejemplo cambios en la indentación o cambio de tabuladores a espacios. Añadir espacios en blanco donde antes no había, o eliminar completamente espacios en blanco aún se mostrará como un cambio.

Ignorar todos los espacios en blanco excluye todos los cambios que sólo se deban a espacios en blanco.

Naturalmente, cualquier línea cuyo contenido haya cambiado se incluye siempre en la diferenciación.

Figura 4.24. El diálogo Comparar Revisiones

Cuando seleccione dos árboles dentro del navegador de repositorios, o cuando seleccione dos revisiones de una carpeta en el diálogo de registro, puede Menú contextual → Comparar revisiones.

Este diálogo muestra una lista de todos los ficheros que han cambiado y le permite comparar o ver la autoría de cada uno individualmente utilizando el menú contextual.

Puede exportar un árbol de cambios, lo que es útil si necesita enviar a alguien la estructura de su árbol de proyecto, pero conteniendo sólo los ficheros que han cambiado. Esta operación trabaja sólo sobre los ficheros seleccionados, por lo que necesitará seleccionar los ficheros de interés - normalmente eso significa todos - y luego Menú contextual → Exportar selección a.... Se le preguntará por una ruta donde guardar el árbol de cambios.

También puede exportar la lista de ficheros cambiados a un fichero de texto utilizando Menú contextual → Guardar lista de ficheros seleccionados a....

Si desea exportar la lista de ficheros y también las acciones (modificado, añadido, borrado), puede hacerlo utilizando Menú contextual → Copiar la selección al portapapeles.

El botón en la parte superior le permite cambiar la dirección de la comparación. Puede mostrar los cambios necesarios para ir de A a B, o si lo prefiere, de B a A.

Los botones con los números de revisión pueden utilizarse para cambiar a un rango de revisiones diferente. Cuando cambia el rango, la lista de ítems que difieren entre las dos revisiones se actualizará automáticamente.

Si la lista de nombres de ficheros es muy larga, puede utilizar la caja de búsqueda para reducir la lista a los nombres de ficheros que contengan un texto específico. Tenga en cuenta que se utiliza una búsqueda de texto simple, así que si desea restringir la lista a ficheros de código fuente C debería introducir .c en vez de *.c.

Hay muchas herramientas disponibles para diferenciar ficheros de texto, incluyendo nuestro propio TortoiseMerge, pero a veces nos encontramos en la situación de querer ver también cómo ha cambiado un fichero de imagen. Por eso es por lo que hemos creado TortoiseIDiff.

Figura 4.25. El visor de diferencias de imágenes

TortoiseSVN → Diff para cualquiera de los formatos de imágenes comunes iniciará TortoiseIDiff para mostrar las diferencias entre las imágenes. Por defecto las imágenes se muestran una al lado de la otra, pero puede utilizar el menú Ver o la barra de herramientas para cambiar a una vista arriba-abajo, o si lo prefiere, puede superponer las imágenes y simular que está usando una caja de luces.

Naturalmente, también puede acercar y alejar el zoom y moverse por la imagen. También puede desplazarse por la imagen símplemente arrastrando con el botón izquierdo. Si selecciona la opción Unir las imágenes, los controles de desplazamiento (barras de desplazamiento, rueda del ratón) de ambas imágenes quedan unidos.

Un cuadro de información de imagen le muestra detalles sobre el fichero de imagen, tales como el tamaño en pixeles, la resolución y la profundidad de color. Si la caja le molesta, utilice Ver → Información de imagen para ocultarla. Puede obtener la misma información en una etiqueta de ayuda si pasa el cursor por encima de la barra de título de la imagen.

Cuando las imágenes se superponen, la intensidad relativa de las imágenes (alpha blend) se controla mediante un control deslizante en el lado izquierdo. Puede pulsar en cualquier parte del deslizador para establecer el blend directamente, o puede arrastrar el deslizador para cambiar el blend de forma interactiva. Ctrl+Mayúsculas-Rueda para cambiar el blend.

El botón debajo del deslizador cambia entre fusión 0% y 100%, y si hace doble click en el botón, la fusión cambia automáticamente cada segundo hasta que pulse el botón de nuevo. Esto puede ser útil cuando busca múltiples cambios pequeños.

A veces quiere ver una diferencia en vez de un fundido. Puede que tenga las imágenes de dos revisiones de una placa de circuito impreso y desea ver qué pistas han cambiado. Si deshabilita el modo alpha blend, la diferencia se mostrará como un XOR de los valores de color del pixel. Las áreas sin cambios se mostrarán en blanco y los cambios se colorearán.

Si las herramientas que le proporcionamos no son lo que necesita, pruebe alguno de los muchos programas de código abierto o comerciales disponibles. Cada uno tiene sus propios favoritos, y esta lista por supuesto no está completa, pero aquí hay algunas que debería considerar:

Lea “Configuración de programas externos” para más información sobre cómo preparar TortoiseSVN para utilizar estas herramientas.

El patrón de ignorados de Subversion hace uso de la expansión de comodines en los nombres de los ficheros, una técnica que originariamente se utilizaba en Unix para especificar ficheros utilizando meta-caracteres como son los comodines. Los siguientes caracteres tienen un significado especial:

La concordancia de patrones distingue entre mayúsculas y minúsculas, lo que puede causar problemas en Windows. Puede forzar que no se distingan a lo bruto, emparejando los caracteres; es decir, por ejemplo, para ignorar *.tmp sin tener en cuenta las mayúsculas y minúsculas, puede utilizar un patrón como *.[Tt][Mm][Pp].

Si desea una definición oficial de la expansión de comodines en los nombres de ficheros, puede encontrarla en las especificaciones de la IEEE para el lenguaje de comandos del shell Notación de Patrones de Concordancia.

Utilice TortoiseSVN → Eliminar para eliminar ficheros o carpetas de Subversion.

Cuando TortoiseSVN → Elimina un fichero, se elimina de su copia de trabajo inmediatamente, a la vez que se marca para su borrado en el repositorio para la próxima confirmación. La carpeta padre del fichero muestra un icono sobreimpresionado de “eliminado”. Hasta que confirme el cambio, puede recuperar el fichero utilizando TortoiseSVN → Revertir sobre la carpeta padre.

Cuando se utiliza TortoiseSVN → Eliminar sobre una carpeta, ésta continúa en su copia de trabajo, pero la sobreimpresión cambia para indicarle que está marcada para ser eliminada. Hasta que confirme el cambio, puede recuperar la carpeta utilizando TortoiseSVN → Revertir sobre la propia carpeta. Esta diferencia en el comportamiento entre ficheros y carpetas es parte de Subversion, no de TortoiseSVN.

Si desea eliminar un ítem del repositorio, pero mantenerlo localmente como un fichero o carpeta no versionados, utilice Menú contextual extendido → Eliminar (mantener local). Debe mantener pulsada la tecla Mayús mientras hace click con el botón derecho sobre el ítem en el panel de lista de exploración (panel derecho) para ver esto en el menú contextual extendido.

Si se borra un fichero utilizando el Explorador en vez de usar el menú contextual de TortoiseSVN, el diálogo de confirmación le muestra esos ficheros y le deja eliminarlos del control de versiones antes de confirmar. Sin embargo, si actualiza su copia de trabajo, Subversion se dará cuenta de que falta un fichero y lo reemplazará con la última versión del repositorio. Si necesita borrar un fichero bajo control de versiones, utilice siempre TortoiseSVN → Eliminar para que Subversion no tenga que averiguar qué es lo que realmente quiere hacer usted.

Si se borra una carpeta utilizando el Explorador en vez de utilizar el menú contextual de TortoiseSVN, su copia de trabajo se romperá y no podrá confirmar. Si actualiza su copia de trabajo, Subversion reemplazará la carpeta que falta con la última versión del repositorio, y luego podrá eliminarla de la forma correcta, utilizando TortoiseSVN → Eliminar.

Si desea simplemente renombrar en el sitio un fichero o una carpeta, utillice Menú contextual → Renombrar... Introduzca el nuevo nombre para el ítem, y ya está.

Si quiere mover ficheros dentro de una copia de trabajo, quizás a una subcarpeta distinta, utilice el manejador de arrastrar-y-soltar con el botón derecho del ratón:

Another way of moving or copying files is to use the Windows copy/cut commands. Select the files you want to copy, right-click and choose Context Menu → Copy from the explorer context menu. Then browse to the target folder, right-click and choose TortoiseSVN → Paste. For moving files, choose Context Menu → Cut instead of Context Menu → Copy.

También puede utilizar el navegador de repositorios para mover ítems. Lea “El navegador de repositorios” para saber más.

Hacer cambios sólo en las mayúsculas/minúsculas de un nombre de fichero es complicado en Subversion sobre Windows, porque durante un corto periodo de tiempo durante el renombrado, ambos nombres de fichero deben existir. Dado que Windows tiene un sistema de ficheros que no distingue mayúsculas y minúsculas, esto no funciona utilizando el habitual comando Renombrar.

Afortunadamente hay (al menos) dos soluciones posibles para renombrar un fichero sin perder su historia de registro. Es importante renombrarlo dentro de Subversion. ¡Renombrarlo únicamente en el explorador corromperá su copia de trabajo!

Solución A) (recomendada)

Solución B)

En el caso de que tenga dos ficheros en el repositorio con el mismo nombre pero diferenciándose únicamente en las mayúsculas (por ejemplo, TEST.TXT y test.txt), ya no podrá actualizar u obtener el directorio padre en un cliente de Windows. Aunque Subversion soporta los nombres de ficheros que se distinguen en las mayúsculas, Windows no.

Esto ocurre a veces cuando dos personas confirman, desde copias de trabajo separadas, ficheros tales que tienen el mismo nombre pero con las mayúsculas/minúsculas diferentes. Esto también puede ocurrir cuando se confirman los ficheros desde un sistema con un sistema de ficheros que distingue mayúsculas/minúsculas, como Linux.

En ese caso, necesita decidir cuál desea mantener y borrar (o renombrar) el otro en el repositorio.

A veces su amistoso IDE renombrará ficheros por usted como parte de un ejercicio de refactorización, y por supuesto no se lo dirá a Subversion. Si intenta confirmar sus cambios, Subversion verá el nombre de fichero antiguo como faltante y el nuevo nombre como fichero no versionado. Podría simplemente confirmar el nuevo nombre de fichero para añadirlo, pero entonces perdería la traza de la historia, ya que Subversion no sabe la relación entre los ficheros.

Una forma mejor es notificar a Subversion de que el cambio es realmente un renombrado, y puede hacer esto dentro de los diálogos Confirmar y Comprobar modificaciones. Simplemente seleccione tanto el nombre de fichero antiguo (faltante) como el nuevo nombre (no versionado) y utilice Menú contextual → Reparar movimiento para emparejar los dos ficheros como un renombrado.

Normalmente especifica un la lista de ignorados tal que todos los ficheros generados se ignoran en Subversion. Pero ¿y si lo que quiere es limpiar todos esos ítems ignorados para producir una compilación limpia? Normalmente lo haría en su makefile (fichero de instrucciones de compilación), pero si está depurando el makefile, o cambiando el sistema de compilación, es útil tener una forma de barrer la casa.

TortoiseSVN proporciona exactamente esa opción utilizando Menú contextual extendido → Eliminar ítems no versionados.... Debe mantener pulsada la tecla Mayús mientras hace click con el botón derecho sobre el ítem en el panel de lista de exploración (panel derecho) para ver esto en el menú contextual extendido. Esto mostrará un diálogo que lista todos los ficheros no versionados en cualquier lugar de su copia de trabajo. Ahí podrá seleccionar o deseleccionar ítems para ser eliminados.

Cuando dichos ítems se eliminan, se utiliza la papelera de reciclaje, por lo que si comete un error aquí y borra un fichero que debería haber estado versionado, aún puede recuperarlo.

Figura 4.32. Página de propiedades de Subversion

Puede leer y establecer las propiedades de Subversion desde el diálogo de propiedades de Windows, pero también desde TortoiseSVN → Propiedades y dentro de las listas de estado de TortoiseSVN, desde Menú contextual → Propiedades.

Puede añadir sus propias propiedades, o algunas propiedades con un significado especial en Subversion. Éstas empiezan con svn:. svn:externals es una de esas propiedades; vea cómo manejar externos en “Ítems externos”.

Puede encontrar más información sobre las propiedades en Subversion en Propiedades especiales.

Añadiendo y editando propiedades

Figura 4.33. Añadiendo propiedades

Para añadir una nueva propiedad, primero pulse en Añadir.... Seleccione el nombre de la propiedad deseado del cuadro desplegable, o escriba un nombre de su elección, y luego introduzca un valor en la caja de texto que hay debajo. Para las propiedades que admiten múltiples valores, como una lista de ignorados, éstos se pueden introducir en múltiples líneas. Pulse en Aceptar para a

Si desea aplicar una propiedad a muchos ítems a la vez, seleccione los ficheros/carpetas en el explorador, y luego seleccione Menú contextual → propiedades

Si desea aplicar la propiedad a cada fichero y carpeta en la jerarquía debajo de la carpeta actual, seleccione la casilla Recursivo.

Algunas propiedades, por ejemplo svn:needs-lock, pueden aplicarse únicamente a ficheros, por lo que ese nombre de propiedad no aparece en la lista desplegable para las carpetas. Aún así puede aplicar dicha propiedad recursivamente a todos los ficheros en una jerarquía, pero tendrá que escribir el nombre de la propiedad usted mismo.

Si desea editar una propiedad existente, primero seleccione dicha propiedad de la lista de propiedades existentes, y luego pulse en Editar....

Si desea eliminar una propiedad existente, seleccione dicha propiedad de la lista de propiedades existentes, y luego pulse en Eliminar.

La propiedad svn:externals se puede utilizar para traer otros proyectos del mismo repositorio o de otro completamente distinto. Para más información, lea “Ítems externos”.

TortoiseSVN tiene unas pocas propiedades especiales para sí mismo, y estas empiezan con tsvn:.

Algunas propiedades tsvn: necesitan un valor true/false (verdadero/falso). TortoiseSVN también entiende yes (sí) como un sinónimo de true y no como un sinónimo de false.

TortoiseSVN puede integrarse con algunas herramientas de control de errores. Esto utiliza propiedades de proyecto que comienzan con bugtraq:. Para más información, lea “Integración con sistemas de control de errores / seguimiento de incidencias”.

También puede integrarse con algunos visores de repositorios basados en web, utilizando propiedades de proyecto que comienzan con webviewer:. Para más información, lea “Integración con visores de repositorios basados en web”.

When you add new sub-folders to a working copy using TortoiseSVN, any project properties present in the parent folder will automatically be added to the new child folder too.

Supongamos que usted obtiene una copia de trabajo de /proyecto1 a D:\dev\proyecto1. Seleccione la carpeta D:\dev\proyecto1, haga clic con el botón derecho y seleccione Menú de Windows → Propiedades del menú contextual. El diálogo Propiedades aparecerá. Vaya a la pestaña de Subversion. Allí puede establecer las propiedades. Haga clic en Añadir.... Seleccione la propiedad svn:externals del desplegable y escriba en el cuadro de edición la URL del repositorio con el formato nombre url o bién, si desea especificar una revisión en concreto, -rREV url. Puede añadir múltiples proyectos externos, uno por línea. Suponga que ha establecido estas propiedades en D:\dev\project1:

http://sounds.red-bean.com/repos
http://graphics.red-bean.com/repos/fast%20graphics
-r21 http://svn.red-bean.com/repos/skin-maker

Ahora haga clic en Establecer y confirme sus cambios. Cuando usted (o cualquier otro usuario) actualice su copia de trabajo, Subversion creará una subcarpeta D:\dev\proyecto1\sonidos y obtendrá el proyecto sonidos, otra subcarpeta D:\dev\proyecto1\gráficas rápidas que contendrá el proyecto gráficas, y finalmente una subcarpeta anidada D:\dev\proyecto1\skins\toolkit que contiene la revisión 21 del proyecto skin-maker.

Los URLs deberán de estar adecuadamente escapados o de lo contrario, no funcionarán, por ejemplo: usted debe de reemplazar cada espacio con %20, tal y como se muestra en el segundo ejemplo anterior.

Si usted desea que la ruta local incluya espacios u cualquier otro caracter especial, puede encerrarlo con comillas dobles, o bién, utilizar el \ símbolo de barras hacia atrás como un caracter de escape al estilo del shell de Unix, precediendo a cualquier caracter especial. Por supuesto que esto significa también que deberá de usar el símbolo / (barra hacia delante) como delimitador de ruta. Este comportamiento es nuevo en Subversión 1.6 y no funcionará en clientes anteriores.

If the external project is in the same repository, any changes you make there will be included in the commit list when you commit your main project.

Si los proyectos externos están en repositorios diferentes, cualquier cambio que haga en el proyecto externo se notificará cuando cnofirme el proyecto principal, pero tendrá que confirmar esos cambios externos de forma separada.

Si utiliza URLs absolutas en las definiciones svn:externals y tiene que relocalizar su copia de trabajo (por ejemplo si la URL de su repositorio cambia), entonces sus externos no cambiarán y puede que no funcionen más.

Para evitar dichos problemas, los clientes de Subversion versión 1.5 y superior soportan URLs externas relativas. Hay cuatro formas para especificar una URL relativa. En los siguientes ejemplos, asumimos que tenemos dos repositorios: uno en http://example.com/svn/repos-1 y otro en http://example.com/svn/repos-2. Tenemos una copia de trabajo de http://example.com/svn/repos-1/project/trunk en C:\Working y la propiedad svn:externals está establecida en trunk.

Si usted lo requiere, también puede especificar una revisión en particular despues del URL, p. ej.: http://sounds.red-bean.com/repos@19

Si necesita más información sobre cómo TortoiseSVN maneja las Propiedades, lea “Configuración del proyecto”.

Para averiguar los diferentes métodos para acceder a subproyectos comunes lea “Incluir un sub-proyecto común”.

Desde Subversion 1.6 puede añadir un fichero suelo externo a su copia de trabajo utilizando la misma sintaxis que se usa para carpetas. Sin embargo, hay algunas restricciones.

Un fichero externo se comporta como cualquier otro fichero versionado en muchos aspectos, pero no pueden ser movidos o eliminados utilizando los comandos normales; en vez de eso, debe modificarse la propiedad svn:externals.

Si ha importado su proyecto con la estructura de directorios recomendados, crear una rama o una etiqueta es muy simple:

Figura 4.34. El diálogo Rama/Etiqueta

Seleccione la carpeta en su copia de trabajo de la que desea hacer una rama o una etiqueta, y luego seleccione el comando TortoiseSVN → Rama/Etiqueta....

La URL de destino por defecto para la nueva rama será la URL de origen en la que se basa su copia de trabajo. Necesitará editar esa URL con la nueva ruta para su rama/etiqueta. Así que en vez de

    http://svn.collab.net/repos/NombreDelProyecto/trunk

querrá ahora usar algo como

    http://svn.collab.net/repos/NombreDelProyecto/tags/Version_1.10

Si no puede recordar la convención de nombres que usó la última vez, pulse el botón a la derecha para abrir el navegador de repositorios, para que pueda ver la estructura actual del repositorio.

Ahora debe elegir el origen de la copia. Aquí tiene tres opciones:

Si desea que su copia de trabajo se cambie automáticamente a la rama recién creada, utilice la casilla Cambiar la copia de trabajo a la nueva rama/etiqueta. Pero si lo hace, asegúrese primero de que su copia de trabajo no contenga modificaciones. Si las tiene, esos cambios se mezclarán en la copia de trabajo de la rama cuando se haga el cambio.

Pulse Aceptar para confirmar la nueva copia al repositorio. No se olvide de proporcionar un mensaje de registro. Tenga en cuenta que la copia se crea dentro del repositorio.

Tenga en cuenta que, salvo que haya optado por cambiar su copia de trabajo a la rama recién creada, crear una etiqueta o una rama no afecta a su copia de trabajo. Incluso si creó la rama desde su copia de trabajo, estos cambios se confirmarán en la rama nueva, no en el tronco, así que su copia de trabajo todavía se marcará como modificada respecto al tronco.

You can also create a branch or tag without having a working copy. To do that, open the repository browser. You can there drag folders to a new location. You have to hold down the Ctrl key while you drag to create a copy, otherwise the folder gets moved, not copied.

You can also drag a folder with the right mouse button. Once you release the mouse button you can choose from the context menu whether you want the folder to be moved or copied. Of course to create a branch or tag you must copy the folder, not move it.

Yet another way is from the log dialog. You can show the log dialog for e.g. trunk, select a revision (either the HEAD revision at the very top or an earlier revision), right-click and choose create branch/tag from revision...

...esa (realmente no) es la cuestión. Mientras que obtener descarga todo de la rama elegida a su directorio de trabajo, TortoiseSVN → Cambiar... sólo transfiere los datos cambiados a su copia de trabajo. Bueno para la carga de la red, bueno para su paciencia. :-)

Para poder trabajar con su rama o etiqueta recién generada tiene varias opciones. Puede:

Figura 4.35. El diálogo Cambiar

Aunque Subversion por sí mismo no hace ninguna distinción entre etiquetas y ramas, la forma en la que normalmente se usan difiere un poco.

Figura 4.36. El asistente de fusionado - Seleccionar el rango de revisiones

En el campo Desde: introduzca la URL completa de la carpeta de la rama o la etiqueta que contiene los cambios que desea portar a su copia de trabajo. También puede pulsar ... para navegar el repositorio y encontrar la rama deseada. Si ha fusionado desde esta rama antes, entonces utilice la lista desplegable que le muestra una historia de las URLs utilizadas anteriormente.

En el campo Rango de revisiones a fusionar introduzca la lista de revisiones que desea fusionar. Puede ser una única revisión, una lista de revisiones específicas separadas por comas, un rango de revisiones separado por un guión, o cualquier combinación de éstas.

La manera más sencilla de seleccionar el rango de revisiones que necesita es pulsar en Mostrar Registro, dado que esto mostrará los cambios recientes con sus comentarios de registro. Si desea fusionar los cambios de una única revisión, seleccione esa revisión. Si desea fusionar los cambios de varias revisiones, entonces seleccione ese rango (utilizando el modificador habitual Mayúsculas). Pulse Aceptar y la lista de números de revisión a fusionar se rellenará automáticamente.

Si desea fusionar los cambios de nuevo fuera de su copia de trabajo, para revertir un cambio que ya ha sido confirmado, seleccoine las revisiones a revertir y asegúrese de que la casilla Fusión inversa está marcada.

Si ya ha fusionado algunos cambios desde esta rama, esperemos que haya apuntado la última revisión fusionada en el mensaje de registro cuando confirmó ese cambio. En ese caso, puede utilizar Mostrar Registro en la Copia de Trabajo para buscar ese mensaje de registro. Recordando que estamos pensando en las revisiones como conjuntos de cambios, debería utilizar la revisión siguiente al punto final de la última fusión como punto de inicio para esta fusión. Por ejemplo, si la última vez fusionó las revisiones de la 37 a la 39, entonces el punto de inicio de esta fusión sería la revisión 40.

Si está utilizando las características de registro de fusiones de Subversion, no necesita recordar qué revisiones ya han sido fusionadas - Subversion lo apuntará por usted. Si deja el rango de revisiones en blanco, se incluirán todas las revisiones que no hayan sido aún fusionadas. Lea “Registro de fusión” para saber más.

Si hay otras personas que puedan estar confirmando cambios, entonces tenga cuidado al utilizar la revisión HEAD. Puede que no se refiera a la revisión que usted cree si alguien más ha hecho una confirmación después de su última actualización.

Haga click en Siguiente y vaya a “Opciones de fusión”

Figura 4.37. El asistente de fusión - Fusionar reintegración

Para fusionar una rama de la característica en el tronco necesita iniciar el asistente de fusión desde una copia de trabajo del tronco.

En el campo Desde la URL: introduzca la URL completa de la carpeta que quiere fusionar. También puede pulsar ... para navegar el repositorio.

Hay algunas condiciones que se aplican a la fusión de reintegración. En primer lugar, el servidor debe soportar el registro de fusiones. La copia de trabajo debe ser de profundidad infinita (sin obtenciones parciales), y no debe tener ninguna modificación local, ítems apuntando a otra ruta o ítems que hayan sido actualizados a otras revisiones distintas de HEAD. Todos los cambios del tronco hechos durante el desarrollo de la rama deben haberse fusionado en la rama (o marcados como que ya han sido fusionados). El rago de revisiones para la fusión se calculará automáticamente.

Figura 4.38. El asistente de fusión - Fusión de árboles

Si está utilizando este método para fusioanr una rama de característica de nuevo en el tronco, necesitará iniciar el asistente de fusión desde una copia de trabajo del tronco.

En el campo Desde: introduzca la URL completa del tronco (trunk). Esto puede sonar erróneo, pero recuerde que el tronco es el punto de inicio al que desea añadir los cambios de la rama. También puede pulsar ... para navegar el repositorio.

En el campo A: introduzca la URL completa de la rama de la característica.

En los dos campos Desde la Revisión y Hasta la Revisión, introduzca el último número de revisión en el que se sincronizaron los dos árboles. Si está seguro de que nadie más está haciendo confirmaciones puede utilizar HEAD en ambos casos. Si hay alguna posibilidad de que alguien haya hecho una confirmación desde esa sincronización, utilice el número de revisión específico para evitar perder cambios más recientes.

También puede usar Mostrar registro para seleccionar la revisión.

Esta página del asistente le permite especificar opciones avanzadas antes de empezar el proceso de fusión. La mayoría de las veces puede simplemente utilizar las opciones por defecto.

Puede especificar la profundidad de la fusión, es decir, cuántos niveles debe bajar la fusión en su copia de trabajo. Los términos de profundidad se describen en “Profundidad de obtención”. La profundidad por defecto es Copia de trabajo, que utiliza la configuración de profundidad existente, y que casi siempre es lo que quiere hacer.

La mayoría del tiempo deseará que la fusión tenga en cuenta el historial de un fichero, para que se fusionen los cambios relativos a un ancestro en común. A veces puede necesitar fusionar ficheros que quizás estén relacionados, pero no en su repositorio. Por ejemplo, puede haber importado las versiones 1 y 2 de una biblioteca de terceros en dos directorios separados. Aunque están relacionados de forma lógica, Subversion no tiene conocimiento de ello porque sólo ve los ficheros que ha importado. Si intenta fusionar las diferencias entre estos dos ficheros vería un borrado completo seguido de un adición completa. Para hacer que Subversion utilice únicamente las diferencias basadas-en-ruta en vez de diferencias basadas-en-historial, seleccione la casilla Ignorar ancestros. Puede leer más sobre este tema en el libro de Subversion; Teniendo en cuenta o ignorando los ancestros

Puede especificar la forma en la que se manejan los cambios en los finales de línea y en los espacios en blanco. Estas opciones se describen en “Opciones de fín de línea y espacios en blanco”. El comportamiento por defecto es tratar todos los espacios en blanco y las diferencias en los finales de líneas como cambios reales que deben fusionarse.

The checkbox marked Force the merge is used to avoid a tree conflict where an incoming delete affects a file that is either modified locally or not versioned at all. If the file is deleted then there is no way to recover it, which is why that option is not checked by default.

Si está utilizando el registro de fusiones y desea marcar una revisión como que ya se ha fusionado, sin hacer realmente efectiva la fusión aquí, marque la casilla Sólo registrar la fusión. Hay dos posibles razones por las que puede querer hacer esto. Puede ser que la fusión es demasiado complicada para los algoritmos de fusión, por lo que hace los cambios en el código a mano, y luego marca el cambio como fusionado para que el algoritmo de registro de fusión se de por enterado. O quizás quiera evitar que una revisión en concreto se fusione. Marcándola como ya fusionada evitará que la fusión se produzca con los clientes manejan la información de registro de fusión.

Now everything is set up, all you have to do is click on the Merge button. If you want to preview the results Test Merge simulates the merge operation, but does not modify the working copy at all. It shows you a list of the files that will be changed by a real merge, and notes files where conflicts may occur. Because merge tracking makes the merge process a lot more complicated, there is no guaranteed way to find out in advance whether the merge will complete without conflicts, so files marked as conflicted in a test merge may in fact merge without any problem.

El diálogo de progreso de fusión muestra cada etapa de la fusión, con los rangos de revisiones involucrados. Esto puede indicar un número de revisión más del que esperaba. Por ejemplo, si pidió fusionar la revisión 123, el diálogo de progreso mostrará “Fusionando de r122 a r123”. Para entenderlo debe recordar que Fusionar está íntimamente relacionado con Diferenciar. El proceso de fusión funciona generando una lista de diferencias entre dos puntos del repositorio, y posteriormente aplicando esas diferencias a su copia de trabajo. El diálogo de progreso está simplemente mostrando los puntos de inicio y fin de la diferenciación.

La fusión ya ha concluído. Es una buena idea observar la fusión y comprobar si el resultado es el esperado. Normalmente fusionar es un proceso complicado. A menudo aparecen conflictos cuando la rama se ha desviado mucho del tronco.

Los clientes y servidores de Subversion anteriores a la versión 1.5 no almacenan la información de fusión, y las revisiones fusionadas deben ser registradas de forma manual. Cuando haya comprobado los cambios y vaya a confirmar esta revisión, su mensaje de registro de confirmación debería incluir siempre los números de revisión que han sido portados en la fusión. Si desea aplicar otra fusión más tarde, necesitará saber lo que ya ha fusionado, porque no querrá portar un cambio más de una vez. Puede encontrar más información sobre esto en Las mejores prácticas para fusionar en el libro de Subversion.

Si su servidor y todos los clientes están ejecutando Subverison 1.5 o superior, las facilidades de registro de fusiones apuntarán las revisiones fusionadas y evitarán que una revisión se fusione más de una vez. Esto le facilita mucho la vida ya que puede simplemente fusionar el rango entero de revisiones cada vez y saber qué sólo las nuevas revisiones serán realmente fusionadas.

El manejo de las ramas es importante. Si desea mantener esta rama actualizada respecto al tronco, debería asegurarse de fusionar a menudo para que la rama y el tronco no se alejen mucho. Por supuesto, sigue debiendo evitar fusiones repetidas de cambios, como se explicó anteriormente.

Subversion 1.5 introdujo facilidades para el registro de fusiones.. Cuando fusiona cambios de un árbol en otro, los números de revisión fusionados se almacenan, y esta información se puede utilizar para diferentes propósitos.

La información de registro de fusiones se almacena en la propiedad svn:mergeinfo por parte del cliente cuando realiza la fusión. Cuando la fusión se confirma, el servidor almacena dicha información en una base de datos, y cuando le pide información de la fusión, registro o autoría, el servidor puede responer apropiadamente. Para que el sistema funcione correctamente debe asegurarse de que el servidor y todos los clientes estén actualizados. Los clientes antiguos no almacenarán la propiedad svn:mergeinfo y los servidores anteriores no proporcionarán la información que piden los nuevos clientes.

Averigue más sobre el registro de fusión desde la Documentación de registro de fusión de Subversion.

Las fusiones no siempre van bien. A menudo ocurre algún conflicto, y si está fusionando múltiples rangos, generalmente querrá resolver el conflicto antes de que comience la fusión del siguiente rango. TortoiseSVN le ayuda durante este proceso mostrándole el diálogo información de conflicto de fusión.

Figura 4.39. El diálogo Información de conflicto de fusión

Cuando ocurre un conflicto durante la fusión, tiene tres formas de manejarlo.

Si no desea utilizar esta llamada interactiva, hay una casilla en el diálogo de progreso de fusión Fusión no-interactiva. Si esto se marca para una fusión y la fusión resulltaría en un conflicto, el fichero se marca como en conflicto y la fusión continua. Tendrá que resolver los conflictos después de que se complete la fusión. Si no se marca, entonces tendrá la oportunidad de resolver el conflicto durante la fusión antes de que se marque como en conflicto. Esto tiene la ventaja de que si un fichero tiene múltiplas fusiones (múltiples revisiones que aplican un cambio sobre ese fichero), puede que las siguientes fusiones sean satisfactorias dependiendo de qué líneas se vean afectadas. Pero por supuesto no puede irse a tomar café mientras se ejecuta la fusión ;)

Si desea fusionar todos los cambios desde una rama de característica al tronco, entonces puede utilizar el comando TortoiseSVN → Fusionar reintegración... desde el menú contextual extendido (mantenga pulsada la tecla Mayúsculas mientras hace click con el botón derecho en el fichero).

Figura 4.40. El diálogo Fusionar reintegración

Este diálogo es muy sencillo. Todo lo que tiene que hacer el establecer las opciones para la fusión, como se describe en “Opciones de fusión”. El resto se hace por TortoiseSVN automáticamente utilizando el registro de fusiones.

Cuando desarrolla una nueva característica en una rama separada es una buena idea mantener una política de re-integración cuando la característica está completa. Si se está modificando a la vez trunk (el tronco), puede que encuentre que las diferencias se vuelven significativas según pasa el tiempo, y la fusión se convierte en una pesadilla.

Si la característica es relativamente simple y el desarrollo no llevará mucho tiempo, puede adoptar un camino más simple, que es mantener la rama totalmente separada hasta que la característica se completa, y luego fusionar los cambios de la rama de nuevo en el tronco. En el asistente de fusión esto sería un simple Fusionar un rango de revisiones, donde el rango de revisiones es la rango de revisiones de la rama.

Si la característica va a llevar más tiempo y necesita tener en cuenta los cambios en trunk, entonces necesita mantener las ramas sincronizadas. Esto simplemente significa que periódicamente fusionará el tronco en la rama, para que la rama contenga todos los cambios de la rama además de la nueva característica. El proceso de sincronización utiliza Fusionar un rango de revisiones. Cuando la característica esté completa, podrá fusionarla de nueva en trunk utilizando o bien Reintegrar una rama o Fusionar dos árboles distintos.

Por defecto, nada se bloquea y todo el mundo que tiene acceso de confirmación puede confirmar cambios a cualquier fichero en cualquier momento. Los demás actualizarán sus copias de trabajo periódicamente y los cambios en el repositorio se fusionarán con los cambios locales.

Si Obtiene un Bloqueo en un fichero, entonces sólo usted puede confirmar ese fichero. Las confirmaciones de los demás se bloquearán hasta que quite el bloqueo. Un fichero bloqueado no puede ser modificado de ninguna forma en el repositorio, por lo que no puede ser siquiera borrado o renombrado, excepto por el dueño del bloqueo.

Sin embargo, los demás usuarios no necesariamente saben que usted ha obtenido un bloqueo. A menos que ellos comprueben el estado de bloqueo regularmente, la primera vez que sabrán sobre él es cuando sus confirmaciones fallen, lo que muchas veces no es muy útil. Para hacer más fácil el manejo de bloqueos, hay una nueva propiedad de Subversion svn:needs-lock. Cuando se establece esta propiedad (a cualquier valor) en un fichero, siempre que el fichero se obtiene o actualiza, la copia local se deja como sólo-lectura a menos que la copia de trabajo tenga un bloqueo para ese fichero. Esto actúa como una advertencia de que no debería modificar el fichero a menos que obtenga un bloqueo. Los ficheros que están versionados y marcados como sólo-lectura se marcan con un icono de sobreimpresión especial en TortoiseSVN para indicar que necesita obtener un bloqueo antes de editar.

Los bloqueos se graban con el lugar de la copia local y también con el propietario. Si tiene varias copias de trabajo (en casa, en el trabajo) entonces sólo puede obtener un bloqueo en una de esas copias de trabajo.

Si uno de sus compañeros de trabajo obtiene un bloqueo y luego se va de vacaciones sin quitarlo, ¿qué hace? Subversion proporciona un método para forcar bloqueos. Quitar un bloqueo que tiene otra persona se define como Romper el bloqueo, y obtener forzosamente un bloqueo que tiene otro se define como Robar el bloqueo. Naturlamente estas no son cosas que hacer a la ligera si desea continuar siendo amigo de sus compañeros de trabajo.

Los bloqueos se guardan en el repositorio, y se crea un token de bloqueo en su copia local de trabajo. Si hay una discrepancia, por ejemplo si alguien ha roto el bloqueo, el token local se convierte en inválido. El repositorio siempre es la referencia definitiva.

Seleccione el fichero o ficheros en su copia de trabajo para los que desee obtener un bloqueo, y seleccione el comando TortoiseSVN → Obtener Bloqueo....

Figura 4.41. El diálogo Bloquear

Aparece un diálogo, que le permite introducir un comentario, para que los demás vean por qué ha bloqueado el fichero. El comentario es opcional, y de momento sólo se utiliza con repositorios basados en Svnserve. Si (y sólo si) necesita robar el bloqueo de alguien, marque la casilla Robar bloqueo, y luego pulse Aceptar.

Si selecciona una carpeta y luego utiliza TortoiseSVN → Obtener Bloqueo... se abrirá el diálogo de bloquear con todos los ficheros en todas las subcarpetas seleccionados para bloquearlos. Si realmente quiere bloquear una jerarquía completa, ésta es la forma de conseguirlo, pero puede ganarse la antipatía de sus compañeros de trabajo si les bloquea todo el proyecto. Utilícelo con cuidado...

Para asegurarse de que no se olvida de quitar un bloqueo que no necesita más, los ficheros bloqueados se muestran en el diálogo de confirmar y se seleccionan por defecto. Si continúa con la confirmación, los bloqueos que tenga sobre los ficheros seleccionados se quitan, incluso si los ficheros no se han modificado. Si no desea quitar el bloqueo en algunos ficheros, puede desmarcarlos (si no están modificados). Si desea mantener los bloqueos en un fichero que ha modificado, tiene que habilitar la casilla Mantener bloqueos antes de confirmar sus cambios.

Para quitar un bloqueo manualmente, seleccione el fichero o ficheros de su copia de trabajo para los que desee quitar el bloqueo, y luego seleccione el comando TortoiseSVN → Quitar Bloqueo. No hay nada más que introducir por lo que TortoiseSVN contactará con el repositorio y quita los bloqueos. También puede utilizar este comando en una carpeta para quitar todos los bloqueos recursivamente.

Figura 4.42. El diálogo Comprobar modificaciones

Para ver qué bloqueos tiene usted y los de los demás, puede utilizar el comando TortoiseSVN → Comprobar Modificaciones.... Los tokens de bloqueos que se tienen localmente se muestran inmediatamente. Para comprobar los bloqueos que tienen los demás (y para ver si alguno de sus bloqueos se han roto o han sido robados) necesita pulsar Comprobar Repositorio.

Desde el menú contextual aquí, también puede obtener y quitar bloqueos, además de romper y robar bloqueos que tienen otros.

Como se menciona arriba, la manera más efectiva de utilizar los bloqueos es establecer la propiedad svn:needs-lock en los ficheros. Consulte “Configuración del proyecto” para obtener instrucciones sobre cómo establecer propiedades. Los ficheros con esta propiedad establecida siempre se obtendrán y actualizarán con la marca de sólo-lectura a menos que su copia de trabajo tenga un bloqueo.

Como recordatorio, TortoiseSVN utiliza un icono de sobreimpresión especial para indicarlo.

Si opera una política donde todos los ficheros han de ser bloqueados, puede que encuentre más fácil utilizar la característica de Subversion auto-props para establecer la propiedad automáticamente cada vez que añada nuevos ficheros. Para más información, lea “Establecer propiedades automáticamente”.

Cuando crea un nuevo respositorio con Subversion 1.2 o superior, se crean cuatro plantillas en el directorio hooks del repositorio. Éstos se llaman antes y después de obtener un bloqueo, y antes y después de quitar un bloqueo.

Es una buena idea instalar un script gancho post-lock y post-unlock en el servidor que envíe un email indicando el fichero que se ha bloqueado. Poniendo este script en su sitio, todos sus usuarios serán informados si alguien bloquea/quita el bloqueo de un fichero. Puede encontrar un script gancho de ejemplo hooks/post-lock.tmpl en su carpeta del repositorio.

También puede utilizar ganchos para no permitir romper o robar bloqueos, o quizás para limitarlo a un administrador designado para ello. O quizás desea enviar un email al propietario cuando uno de sus bloqueos se haya roto o robado.

Para más información, lea la “Scripts gancho en el lado del servidor”.

Primero necesita hacer y probar sus cambios. Luego en vez de utilizar el comando TortoiseSVN → Confirmar... sobre la carpeta padre, seleccione TortoiseSVN → Crear Parche...

Figura 4.43. El diálogo Crear parche

ahora puede seleccionar los ficheros que desea incluir en el parche, del mismo modo a como lo haría con una confirmación completa. Esto producirá un único fichero que contendrá un resumen de todos los cambios que ha hecho a los ficheros seleccionados desde la última vez que se actualizó desde el repositorio.

Las columnas en este diálogo pueden ser personalizadas de la misma forma que las columnas en el diálogo Comprobar modificaciones. Para más detalles, lea “Estado local y remoto”.

Puede producir parches separados que contengan cambios a diferentes conjuntos de ficheros. Por supuesto, si crea un fichero de parche, hace algunos cambios más a los mismos ficheros y luego crea otro parche, el segundo fichero de parche incluirá ambos conjuntos de cambios.

Simplemente grabe el fichero utilizando un nombre de fichero de su elección. Los ficheros de parche pueden tener la extensión que desee, pero por convención se suele utilizar las extensiones .patch o .diff extension. Ya está preparado para enviar su fichero de parches.

También puede almacenar el parche en el portapapeles en vez de en un fichero. Puede querer hacer esto para poder pegarlo en un email de forma que lo revisen otros. O si tiene dos copias de trabajo en una máquina y quiere transferir cambios de una a otra, un parche en el portapapeles es una forma cómoda de hacerlo.

Los ficheros de parches se aplican en su copia de trabajo. Esto debe hacerse desde el mismo nivel de carpetas que se utilizó para crear el parche. Si no está seguro de cuál es, mire la primera línea del fichero de parche. Por ejemplo, si el primer fichero en el que se trabajó era doc/source/english/chapter1.xml y la primera línea en el fichero de parche es Index: english/chapter1.xml entonces necesita aplicar el parche en la carpeta english. Sin embargo, suponiendo que esté en la copia de trabajo correcta, si ha seleccionado un nivel de carpeta erróneo, TortoiseSVN se dará cuenta y le sugerirá el nivel correcto.

Para aplicar un fichero de parche en su copia de trabajo, necesita al menos acceso de lectura al repositorio. La razón para esto es que el programa de fusión debe referenciar los cambios sobre la revisión contra la que se hicieron por el desarrollador remoto.

From the context menu for that folder, click on TortoiseSVN → Apply Patch... This will bring up a file open dialog allowing you to select the patch file to apply. By default only .patch or .diff files are shown, but you can opt for “All files”. If you previously saved a patch to the clipboard, you can use Open from clipboard... in the file open dialog. Note that this option only appears if you saved the patch to the clipboard using TortoiseSVN → Create Patch.... Copying a patch to the clipboard from another app will not make the button appear.

Alternativamente, si el fichero de parche tiene una extensión .patch o .diff, puede hacer click con el botón derecho en él directamente y seleccioanr TortoiseSVN → Aplicar Parche.... En este caso se le preguntará la ruta de la copia de trabajo.

Estos dos métodos le ofrecen formas diferentes de hacer lo mismo. Con el primer método selecciona la copia de trabajo y busca el fichero de parche. Con el segundo selecciona el fichero de parche y busca la copia de trabajo.

Una vez que haya seleccionado el fichero de parche y la ruta de la copia de trabajo, se ejecuta TortoiseMerge para fusionar los cambios del fichero de parche contra su copia de trabajo. Una pequeña ventana le muestra los ficheros que han sido cambiados. Haga doble click por turnos en cada uno de ellos, compruebe los cambios y grabe los ficheros fusionados.

El parche del desarrollador remoto ya ha sido aplicado a su copia de trabajo, por lo que necesita confirmar para que todos los demás accedan a los cambios desde el repositorio.

Figura 4.44. El diálogo Anotar / Autoría

Si no está interesado en cambios de revisiones anteriores puede establecer la revisión desde la cual debe empezar la autoría. Ponga este valor a 1 si desea ver la autoría de cada revisión.

Por defecto, el fichero de autoría se ve utilizando TortoiseBlame, que remarca las diferentes revisiones para hacerlas más fáciles de leer. Si desea imprimir o editar el fichero de autoría, seleccione Utilizar visor de texto para ver autorías

Puede especificar la forma en la que se manejarán los cambios en los finales de línea y en los espacios en blanco. Estas opciones se describen en “Opciones de fín de línea y espacios en blanco”. El comportamiento por defecto es tratar todas las diferencias en los espacios en blanco y en los finales de línea como cambios reales, pero si desea ignorar un cambio en la indentación y encontrar al autor original, puede elegir la opción apropiada aquí.

Una vez que pulse Aceptar, TortoiseSVN empieza a recoger la información para crear el fichero de autoría. Tenga ésto en cuenta: esto puede llevar varios minutos para completarse, dependiendo en cuánto haya cambiado el fichero y por supuesto de su conexión de red con el repositorio. Una vez que el proceso de autoría ha terminado, el resultado se escribe en un fichero temporal y puede ver los resultados.

Figura 4.45. TortoiseBlame

TortoiseBlame, que se incluye con TortoiseSVN, hace más fáciles de leer los ficheros de autoría. Cuando pasa el ratón por encima de una línea en la columna de información de autoría, todas las líneas con la misma revisión se señalan con un fondo más oscuro. Las líneas de otras revisiones que fueron cambiadas por el mismo autor se señalan con un fondo claro. Los colores pueden no funcionar de forma muy eficiente si su pantalla está en el modo de 256 colores.

Si hace click en una línea, todas las líneas con la misma revisión se señalan, y las líneas de otras revisiones del mismo autor se señalan en un color más claro. Este señalado se mantiene, permitiéndole mover el ratón sin perder los señalados. Pulse en esa revisión de nuevo para desactivar el señalado.

Los comentarios de la revisión (mensaje de registro) se muestra en un texto de ayuda cuando se pasa el cursor sobre la columna de información de autoría. Si quiere copiar el mensaje de registro de esa revisión, utilice el menú contextual que aparece cuando hace click con el botón derecho sobre la columna de información de autoría.

Puede buscar dentro del informe de Autoría utilizando Edición → Buscar.... Esto le permite buscar por números de revisión, autores y por el contenido del fichero en si mismo. Los mensajes de registro no se incluyen en la búsqueda - deberá utilizar el diálogo de Mostrar Registro para buscar en ellos.

También puede ir directamente a un número de línea concreto utilizando Editar → Ir a la línea....

Cuando el ratón se coloca encima de las columnas de información de autoría, tiene disponible un menú contextual que le ayuda a comparar revisiones y examinar la historia, utilizando el número de revisión bajo el ratón como referencia. Menú contextual → Ver autoría de la revisión anterior genera un informe de autoría para el mismo fichero, pero utilizando la revisión anterior como límite superior. Esto le da el informe de autoría para el estado del fichero justo antes de que la línea que está viendo cambiara. Menú contextual → Mostrar cambios inicia su visor de diferencias, mostrándole lo que cambió en la revisión referenciada. Menú contextual → Mostrar registro le muestra el diálogo de registro de revisiones empezando en la revisión referenciada.

Si necesita un indicador visual mejor de dónde están los cambios más antiguos y más nuevos, seleccione Ver → Colorear la antigüedad de las líneas. Esto utilizará un gradiente de color para mostrar las líneas más nuevas en rojo y las más antiguas en azul. La paleta de color por defecto es bastante suave, pero puede cambiarla utilizando la configuración de TortoiseBlame.

Si está utilizando Registro de fusiones, donde las líneas hayan cambiado como resultado de una fusión desde otra ruta, TortoiseBlame le mostrará la revisión y el autor del último cambio en el fichero original, en vez de la revisión en la que se realizó la fusión. Estas líneas se muestran con la revisión y el autor en cursiva. Si no desea que las líneas fusionadas se muestren de esta forma, desmarque la casilla Incluir información de fusión.

Si quiere ver las rutas involucradas en la fusión, seleccione Ver → Rutas de fusión.

Las configuraciones para TortoiseBlame se pueden acceder utilizando TortoiseSVN → Configuración... en la pestaña TortoiseBlame. Para más información, vea “Configuración de TortoiseBlame”.

Una de las limitaciones del informe de Autoría es que sólo muestra el fichero tal y como estaba en una revisión en concreto, y muestra la última persona que cambió cada línea. A veces querrá saber qué cambio se hizo, y también quién lo hizo. Lo que necesita aquí es una combinación de los informes de diferencias y autoría.

El diálogo del historial de revisiones incluye varias opciones que le permiten hacerlo.

Cada nodo de gráfico de revisión representa una revisión en el repositorio donde algo cambió en el árbol que está viendo. Los diferentes tipos de nodos se pueden distinguir por forma y color. Las formas son fijas, pero los colores se pueden cambiar utilizando TortoiseSVN → Configuración

Tenga en cuenta que por defecto el gráfico sólo muestra los puntos en los que se añadieron, copiaron o borraron ítems. Mostrar cada revisión de un proyecto generará un gráfico muy grande para casos no triviales. Si realmente desea ver todas las revisiones en las que se hicieron cambios, hay una opción para conseguirlo en el menú Ver y en la barra de herramientas.

La vista por defecto (sin agrupación) pone los nodos con su posición vertical en estricto orden de revisión, para que tenga una pista visual del órden en el que se hicieron las cosas. Cuando dos nodos están en la misma columna, el órden es muy obvio. Cuando dos nodos están en columnas contiguas la separación es mucho menor porque no hay necesidad de evitar que los nodos se sobrepongan, y como resultado el órden es un poco menos obvio. Estas optimizaciones son necesarias para mantener gráficos complejos en un tamaño razonable. Por favor tenga en cuenta que esta ordenación utiliza el borde del nodo en el lado más antiguo como referencia, es decir, el borde inferior del nodo cuando el gráfico se muestra con el nodo más antiguo en la parte inferior. El borde de referencia es importante porque no todas las formas de los nodos tienen la misma altura.

Dado que los gráficos de revisiones son a menudo complejos, hay un número de funcionalidades que pueden utilizarse para ajustar la vista a lo que desea obtener. Estas opciones están disponibles en el menú Ver y en la barra de herramientas.

Para hacer más fácil la navegación en un gráfico grande, utilice la ventana sobreimpresionada. En ella se muestra el gráfico completo en una pequeña ventana, con la parte que se muestra actualmente iluminada. Puede arrastrar el área iluminada para cambiar la región que se muestra.

La fecha de la revisión, el autor y los comentarios se muestran en una caja de ayuda cuando se mueve el ratón encima de una caja de revisión.

Si selecciona dos revisiones (mediante Ctrl-click con el botón izquierdo), puede utilizar el menú contextual para mostrar las diferencias entre esas revisiones. Puede elegir mostrar las diferencias en los puntos de creación de las ramas, pero normalmente querrá mostrar las diferencias en los puntos finales de las ramas, esto es, en la revisión HEAD.

Puede ver las diferencias como un fichero de Diff Unificado, que le muestra todas las diferencias en un fichero único con contexto mínimo. Si opta por Menú Contextual → Comparar Revisiones se le presentará una lista de ficheros cambiados. Haga doble click en un nombre de fichero para obtener ambas revisiones y compararlas utilizando una herramienta de diferencias visual.

Si hace click con el botón derecho en una revisión, puede utilizar Menú Contextual → Mostrar registro para ver la historia.

También puede fusionar cambios de la(s) revision(es) seleccionada(s) en una copia de trabajo distinta. Un diálogo de selección de carpeta le permitirá elegir la copia de trabajo donde desea fusionar, pero después de eso no hay diálogo de confirmación, ni oportunidad de probar la fusión sin ejecutarla realmente. Es una buena idea fusionar en una copia de trabajo sin cambios, ¡y así poder revertir los cambios si no funcionan! Esta es una funcionalidad útil si desea fusionar las revisiones seleccionadas de una rama a otra.

Si desea comprobar el servidor de nuevo para obtener la información más reciente, puede simplemente refrescar la vista utilizando F5. Si está utilizando la caché de registro (habilitada por defecto), esto buscará en el repositorio las confirmaciones más recientes y traerá sólo las nuevas. Si la caché de registro estaba en modo desconectado, esto intentará volver a ponerla en línea.

Si está utilizando la caché de registros y cree que el contenido del mensaje o el autor han podido cambiar, debería utilizar el diálogo de registro para refrescar los mensajes que necesita. Dado que el gráfico de revisiones trabaja desde la raíz del repositorio, tendríamos que invlidar la caché completa de registro, y recargarla podría llevar muchísimo tiempo.

Un árbol grande puede ser dificil para navegar y a veces querrá ocultar partes de él, o partirlo en un bosque de árboles más pequeños. Si mueve el ratón sobre el punto donde un enlace de nodo entra o sale del nodo, verá que aparecen uno o más botones que le permitirán hacer esto.

Pulse en el botón menos para colapsar el subárbol adjunto.

Pulse el botón más para expandir un árbol colapsado. Cuando un árbol se ha colapsado, este botón permanece visible para indicar un subárbol oculto.

Pulse en el botón cruz para separar el subárbol adjunto y mostrarlo como un árbol separado en el gráfico.

Pulse en el botón círculo para readjuntar un árbol separado Cuando se ha separado un árbol, este botón permanece visible para indicar que hay un subárbol separado.

Click on the graph background for the main context menu, which offers options to Expand all and Join all. If no branch has been collapsed or split, the context menu will not be shown.

A veces tiene una copia de trabajo que desea reconvertir en una carpeta normal sin los directorios .svn. Lo que realmente necesita es un comando exportar-en-el-sitio, que simplemente elimine las carpetas de control, en vez de generar un nuevo árbol limpio.

La respuesta es sorprendentemente sencilla - ¡exporte el árbol en si mismo! TortoiseSVN detecta este caso especial y le pregunta si quiere convertir su copia de trabajo en no-versionada. Si responde sí, los directorios de control se eliminan y tendrá un simple árbol sin directorios de control.

Puede integrar una herramienta de control de errores de su elección con TortoiseSVN. Para hacerlo, necesita definir algunas propiedades, que empiezan por bugtraq:. Deben establecerse sobre las carpetas: (“Configuración del proyecto”)

Hay dos formas de integrar TortoiseSVN con los programas de control de incidencias. Una se basa en simples cadenas de texto, la otra se basa en expresiones regulares. Las propiedades que se utilizan en ambos casos son: