Sistema para la administración de versiones de los sistemas académicos y contable de la PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS Y COMPUTACIÓN

Disertación de Grado Previa la obtención del título de Ingeniería en Sistemas

SISTEMA PARA LA ADMINISTRACIÓN DE VERSIONES DE LOS SISTEMAS ACADÉMICO Y CONTABLE DE LA PUCE SD

AUTORES: CARLOS FERNANDO MORENO CHAVEZ SAMUEL RAFAEL MARÍN DELGADO

DIRECTOR: ING. VISCARRA GUZMÁN VICTOR HUGO

SANTO DOMINGO- ECUADOR, 2012

ii

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO APROBACIÓN DE LA DISERTACION DE GRADO SISTEMA PARA LA ADMINISTRACIÓN DE VERSIONES DE LOS SISTEMAS ACADÉMICO Y CONTABLE DE LA PUCE SD AUTORES: CARLOS FERNANDO MORENO CHAVEZ, SAMUEL RAFAEL MARÍN DELGADO

TRIBUNAL

ING. VISCARRA GUZMÁN VICTOR HUGO

ING. FRANKLIN ANDRES CARRASCO RAMIREZ

ING. FAUSTO ERNESTO OROSCO IGUASNIA

Santo Domingo, febrero de 2012

iii

AGRADECIMIENTOS Agradecemos a la Pontificia Universidad Católica del Ecuador Sede Santo Domingo por permitirnos realizar este proyecto en sus instalaciones, de igual forma queremos agradecer a las personas que laboran en el área de software del CITIC por su colaboración y gran apertura, y también agradecemos a nuestro director por su guía incondicional en la elaboración de este proyecto.

iv

RESUMEN Desde una amplia investigación, hemos encontrado que la forma más óptima de llevar el control de las versiones de software en desarrollo es utilizando Subversion1, que usado conjuntamente con Trac2 y TortoiseSVN3 nos permite llevar un repositorio de los archivos de código fuente para luego traerlos a nuestro ordenador, modificarlos, distribuirlos con los compañeros de trabajo a través de la red LAN o Internet, y por supuesto recuperar versiones previas de dichos archivos.

La flexibilidad de esta cultura de trabajo se ve complementada con una comunicación centralizada en una plataforma Wiki con una interfaz Web, la cual también permite gestionar las incidencias en el proceso de desarrollo.

La idea central es que se pueda contar con un respaldo de lo que se programa a través del tiempo, para evitar la pérdida de código ya sea si se reemplaza a un miembro del equipo de desarrollo o si se daña un equipo de cómputo, o si se desea recuperar un código previo del ya modificado.

La finalidad de este proyecto es implementar un sistema de control de versiones en el departamento de software del CITIC de la PUCE SD, para dar soporte en el desarrollo de los sistemas académico y contable, en base a una estructura organizada de desarrollo de software.

Finalizado el trabajo, se ha logrado reducir el tiempo de desarrollo en equipo, garantizando que nada de lo que se desarrolle se pierda y se implantó un nuevo orden en el trabajo.

Este proyecto es de sumo interés para todo desarrollador de software que quiera realizar un trabajo profesional, ideal para el desarrollo en grupo y válido para los procesos de auditoría informática.

1

Sistema de control de versiones, de código libre y multiplataforma.

Sistema basado en Web para la gestión de proyectos de desarrollo de software.

3 Software cliente de Subversion implementado como una extensión al sistema operativo.

2

v

ABSTRACT From a wide research, We have found that the most optimal way to take control of software versioning on development is using Subversion4, that used with Trac5 and TortoiseSVN6 it allow us to take a repository of source code files and then bring them back to our PC, modify them, distribute them to colleagues through the Network or Internet, and of course recover previous versions of this files.

The flexibility of this work culture is supplemented with a centralized communication on a Wiki platform in a Web Interface, which also provides manage development issues.

The central idea is that you can have a programming backup over time, to avoid the loss of code whether its replace a member of the development team or if is damaged a computer equipment, or if you want to retrieve a previous code yet modified.

The purpose of this project is to implement this version control system in the software department of CITIC of the PUCE SD, to support the development of academic and accounting systems, based on a well structured software development.

The completed work has been able to reduce development time as a team, ensured that nothing get lost in the development process and implemented a new work order.

This project is of great interest to every software developer who wants to do a professional job, ideal for group development and suitable for computer audit processes.

This project is of great interest to every software developer that wants to do a professional job, ideal for development on team and applies for computer audit process.

4

Version control system, open source and multiplatform.

Web-based system for managing software development projects.

6 Subversion client software, implemented as an extension to the operating system.

5

vi

ÍNDICE DE CONTENIDOS

INTRODUCCIÓN .............................................................................................................10 Objetivo general...............................................................................................................11 Objetivos específicos .......................................................................................................11 1

MARCO TEÓRICO ...................................................................................................12

1.1

SISTEMAS DE CONTROL DE VERSIONES ........................................................12

1.1.1

CVS – Sistema de Versiones Concurrentes.......................................................13

1.1.2

SVN - Subversion ..............................................................................................14

1.1.3

Git......................................................................................................................16

1.1.4

Mercurial ............................................................................................................17

1.1.5

Bazaar ...............................................................................................................18

1.1.6

Libre Source ......................................................................................................19

1.1.7

Monotone ..........................................................................................................20

1.2

ANÁLISIS DE LOS DISTINTOS SISTEMAS DE CONTROL DE VERSIONES ......21

1.2.1

Comparación entre CVS y SVN .........................................................................21

1.2.2

Comparación entre Git y Mercurial ....................................................................23

1.2.3

Comparación entre Git y Bazaar ........................................................................25

1.2.4

Comparación entre Git y Monotone ...................................................................25

1.2.5

Comparación entre Git y SVN ............................................................................26

1.3

SELECCIÓN DEL SISTEMA DE CONTROL DE VERSIONES A UTILIZAR..........28

1.4

ARQUITECTURA DE SUBVERSION ....................................................................28

2

METODOLOGÍA .......................................................................................................36

2.1

COMPONENTES DEL SISTEMA ..........................................................................36

2.1.1

VisualSVN Server ..............................................................................................36

2.1.2

TortoiseSVN ......................................................................................................37

vii

2.1.3

Trac ...................................................................................................................38

2.2

MODELO DEL SISTEMA ......................................................................................39

2.3

ESTABILIZACIÓN DEL SISTEMA.........................................................................40

2.4

IMPLEMENTACIÓN DEL SISTEMA ......................................................................41

2.4.1

Instalación de VisualSVN Server .......................................................................41

2.4.2

Instalación de TortoiseSVN ...............................................................................45

2.4.3

Instalación de Trac en Windows ........................................................................48

2.5

SOCIALIZACIÓN DEL SISTEMA ..........................................................................60

3

PROPUESTA ...........................................................................................................61

4

CONCLUSIONES Y RECOMENDACIONES ............................................................64

BIBLIOGRAFÍA ................................................................................................................66 GLOSARIO ......................................................................................................................68 ANEXOS..........................................................................................................................72 ANEXO 1: GUÍA DE INSTALACIÓN EN WINDOWS .......................................................73 ANEXO 2: GUÍA DE INSTALACIÓN EN UBUNTU - LINUX .............................................89 ANEXO 3: MANUAL DE USUARIO DE TORTOISE SVN ................................................97 ANEXO 4: MANUAL DE USUARIO DE TRAC ...............................................................214 ANEXO 5: GUIA PARA EMPEZAR A TRABAJAR CON ORACLE .................................273

viii

LISTA DE FIGURAS

Figura 1: TortoriseCVS ....................................................................................................14 Figura 2: Página Web de Subversion ...............................................................................15 Figura 3: GitHub ..............................................................................................................16 Figura 4: Interfaz Web de Mercurial .................................................................................17 Figura 5: Flujo de trabajo .................................................................................................18 Figura 6: Comunidad Bazaar ...........................................................................................19 Figura 7: Comunidad LibreSource ...................................................................................19 Figura 8: Página Web de Monotone.................................................................................20 Figura 9: Arquitectura de Subversion ...............................................................................29 Figura 10 Un sistema típico cliente/servidor .....................................................................30 Figura 11 El problema a evitar .........................................................................................31 Figura 12 Bloquear-modificar-desbloquear ......................................................................32 Figura 13 La solución copiar-modificar-fusionar ...............................................................33 Figura 14 La solución copiar-modificar-fusionar (continuado) ..........................................34 Figura 15: Componentes del Sistema ..............................................................................36 Figura 16: Modelo del Sistema ........................................................................................39 Figura 17 VisualSVN Server ............................................................................................41 Figura 18 Pantalla de Bienvenida ....................................................................................42 Figura 19 Términos del Acuerdo de la licencia.................................................................42 Figura 20 Opciones por defecto .......................................................................................43 Figura 21 Repositorios para el sistema académico y contable .........................................44 Figura 22 Pantalla de bienvenida a TortoiseSVN .............................................................45 Figura 23 Paquetes de instalación ...................................................................................45

ix

Figura 24 Instalación de TortoiseSVN ..............................................................................46 Figura 25 Importación de los proyectos al repositorio ......................................................46 Figura 26 Importando a la URL del repositorio del sistema académico ............................47 Figura 27 Autenticación ...................................................................................................47 Figura 28 Pantalla de bienvenida a Trac ..........................................................................53 Figura 29 Vista del repositorio en Trac ............................................................................54 Figura 30 Bitácora de cambios en los códigos .................................................................55 Figura 31 Gantt Calendar ................................................................................................58 Figura 32 Diagrama de Gantt...........................................................................................59 Figura 33 Diagrama de Gantt con varios Tickets .............................................................59

10

INTRODUCCIÓN

En la actualidad grandes empresas, corporaciones o instituciones en general, necesitan de un sistema informático que de soporte a sus actividades tanto técnicas como comerciales, por lo que es imprescindible para una empresa el contar con un departamento que se encargue del desarrollo de estos sistemas, el departamento de software.

En el departamento de software trabajan varias personas con habilidades de programación especializadas, es decir, una persona puede encargarse del desarrollo de las interfaces, otra persona de las consultas a la base de datos, y otra se encarga de la planificación o funcionamiento general del sistema, o de la realización de pruebas en busca de errores. Por lo tanto, para el desarrollo de un sistema informático se debe trabajar en equipo y de forma coordinada.

Estos desarrolladores deben tener en cuenta la necesidad de una herramienta que les ayude a evitar el problema de alterar accidentalmente el código realizado de algún compañero, para esto cada uno debe tener una copia exacta del proyecto en su ordenador, y al mismo tiempo todos deben tener las modificaciones que los demás realicen, además esta herramienta debe poder recuperar algún código que haya sido borrado con anterioridad. A esta herramienta se la denomina Sistema de Control de Versiones.

Actualmente la PUCE SD cuenta con técnicos desarrolladores que laboran en el área de software del CITIC y utilizan Oracle Developer para el desarrollo de sus sistemas académico y contable, pero hasta ahora no se había implementado un sistema para llevar el control de los cambios realizados en el código fuente, lo cual conlleva varios problemas ya que los desarrolladores no saben qué cambios ha realizado su compañero, y como tampoco cuentan con un repositorio, no pueden volver atrás en el desarrollo cuando se presenta un incidente.

El principal problema que tienen los técnicos es que se presentan algunos errores en el sistema cuando se cambia algo del código, ya que esto afecta a lo desarrollado por su compañero.

Esto se resuelve con el uso de un sistema de control de versiones, que es la base de este proyecto, pues estos sistemas utilizan un repositorio en donde se puede almacenar

11

una o varias copias de uno o varios proyectos, en el que se puede saber exactamente qué cambio se realizó y cuando fue hecho. Esto es especialmente útil cuando se quiere volver atrás para arreglar alguna situación, ya que de otra forma se tendría que volver a desarrollar.

Otro aspecto importante de este proyecto es que los técnicos también tendrán la posibilidad de realizar un seguimiento del estado de su software, de esta forma podrán analizar el historial completo de desarrollo.

No se han encontrado desarrollos similares a este proyecto en otras universidades del Ecuador, por lo tanto este trabajo no tiene precedentes y se lo considera original de sus autores.

Al trabajar con un sistema de control de versiones los desarrolladores podrán avanzar con mayor rapidez y sin riesgo a cometer errores, lo cual se deduce en un mejor rendimiento y mayor productividad.

Para este proyecto se ha investigado a fondo todo lo relacionado con los sistemas de control de versiones para la gestión de desarrollo de software, consultando varias alternativas, e incluso probándolas en varias plataformas como Windows y Linux, tratando de encontrar la mejor solución.

Objetivo general Optimizar el proceso de desarrollo respecto de cambios efectuados en los sistemas académico y contable de la PUCE SD.

Objetivos específicos 1. Montar un sistema de control de versiones en una máquina del departamento de software del CITIC de la PUCE SD, para que ayude en la gestión de desarrollo de los sistemas académico y contable.

2. Instalar y configurar un software que sirva de interface entre el sistema de control de versiones y los desarrolladores, para que se adapte a sus necesidades y a los de sus sistemas en desarrollo.

12

1

1.1

MARCO TEÓRICO

SISTEMAS DE CONTROL DE VERSIONES

El control de versiones es el arte de administrar los cambios que sufre la información. Es una actividad cuyo objetivo primordial es facilitar, informar y mantener estructurados los avances, retrocesos, y modificaciones que sufre, en el caso de la informática, el software mientras es desarrollado.

Un sistema de control de versiones es una herramienta que ayuda a los desarrolladores de software a gestionar la elaboración de los códigos fuentes de una forma organizada y clara, teniendo presente todos los cambios que se realicen en ellos, por ejemplo se puede conocer qué desarrollador del equipo de trabajo realizó un cambio sobre un archivo específico, y qué había antes de ese cambio, así como saber en qué fecha lo realizó.

El control de versiones debe proporcionar: 

Un mecanismo de almacenaje de los elementos que deba gestionar.



Posibilidad de realizar cambios sobre los elementos almacenados.



Registro histórico de las actividades.



Elaborar informes con los cambios producidos o generados entre versión y versión.

Un aspecto que contiene la administración de versiones, y que es una de sus poderosas características, es el repositorio.

El repositorio es básicamente un medio de almacenamiento para las versiones que se generen. Debe proporcionar la siguiente información: 

Fecha y hora del almacenamiento.



Número de versión.



Fecha y hora de la última modificación.



Lista de usuarios que han trabajado en el archivo.

13

En el mercado existen varias herramientas para el control de versiones, pero vamos a escoger de entre las mejores que sean de código abierto (open source), de esta forma la PUCE SD podrá ahorrar en la compra de licencias anuales, además, el uso de sistemas open source en las instituciones es un requisito requerido por el régimen actual.

Entre las mejores herramientas para el control de versiones analizadas tenemos: 

CVS



SVN



Git



Mercurial



Bazaar



LibreSource



Monotone

Cabe recalcar que la herramienta deberá funcionar en Sistemas Operativos Windows así como en Linux, y se debe poder complementarse con otras aplicaciones que puedan cubrir todas las necesidades de los desarrolladores, de tal forma que se pueda construir una cultura de desarrollo en un ambiente funcional.

1.1.1

CVS – Sistema de Versiones Concurrentes

CVS es el abuelo de los sistemas de control de versiones. Fue lanzado por primera vez en 1986, es el estándar de facto y se instala en todas partes. Sin embargo, la base de código no tiene todas las funcionalidades como las tiene SVN u otras soluciones.

La curva de aprendizaje no es demasiado empinada para CVS, y es un sistema muy simple para hacer que los archivos y las revisiones se mantengan hasta la fecha. Aunque CVS puede ser una tecnología antigua, sigue siendo muy útil para cualquier programador que quiera realizar copias de seguridad y compartir archivos.

14

7

Figura 1: TortoriseCVS

TortoiseCVS es un gran cliente8 de CVS en Windows, además existen muchos entornos de desarrollo diferentes que usan CVS, tales como Xcode (Mac), Eclipse, NetBeans y Emacs.

1.1.2

SVN - Subversion

Subversion puede funcionar tanto en sistemas Windows, Linux o Mac, y cuenta con una gran comunidad de desarrolladores que lo soporta, además de ser gratuito y libre. Existen varias aplicaciones cliente que le ayudan al desarrollador a mantener sus códigos de forma ágil y segura, así como varios plugins que se adaptan a los distintos entornos de trabajo como .NET o eclipse.

Subversion es un sistema de control de versión libre y de código abierto. Subversion maneja archivos y directorios, y los cambios realizados en ellos, todo el tiempo. Esto le

7

Fuente de la imagen: http://tortoisecvs.org Cliente: Aplicación o programa software que sirve de interfaz gráfica de usuario (GUI) entre la Shell del Sistema de Control de Versiones y el Sistema Operativo.

8

15

permite a usted recuperar versiones viejas de sus datos o examinar la historia de cómo sus datos cambiaron. En este recuadro muchas personas piensan de un sistema de control de versiones como una pequeña “máquina del tiempo”.9

10

Figura 2: Página Web de Subversion

Algunos sistemas de control de versiones son también sistemas Software para la gestión de Configuración (SCM). Estos sistemas son especialmente diseñados para manejar árboles de código fuente y poseen muchas propiedades que son específicos para el desarrollo de software. Subversion sin embargo no es uno de estos sistemas. Es un sistema general que puede ser usado para manejar cualquier colección de archivos.

Subversion es probablemente el sistema de control de versiones con más amplia adopción. La mayoría de los proyectos de código abierto usan Subversion como repositorio, porque otros proyectos de mayor envergadura, tales como SourceForge, Apache, Python, Ruby y muchos otros, lo utilizan también. Por ejemplo Google Code utiliza Subversion exclusivamente para distribuir el código.

Debido a la popularidad de Subversion, diversos clientes de Subversion están disponibles. Un usuario de Windows puede usar TortoiseSVN el cual es un gran explorador de archivos para ver, editar y modificar su base de código de Subversion. Un usuario de Mac puede utilizar Versions el cual es un elegante cliente que provee una

9

Collins-Sussman, Version Control with Subversion, 2008 Fuente de la imagen: http://subversion.tigris.org/

10

16

placentera forma de trabajar con Subversion. Xcode es el cliente de Subversion que usan los desarrolladores de Apple y que se incluye en Leopard11.

1.1.3

Git

Git es la nueva estrella de los sistemas de control de versiones. Inicialmente desarrollado por el creador del Kernel de Linux, Linus Torvalds, Git ha tomado a la comunidad de desarrollo Web rápidamente. Git ofrece un tipo de control de versión muy diferente, se trata de un sistema control de versión distribuido, es decir, no hay un solo código base centralizado para sacar el código. Las diferentes ramas tienen diferentes partes del código, esto quiere decir que cada rama que se crea en Git es un universo paralelo para el código fuente creado. Otros sistemas de control de versiones, como CVS y SVN, utilizan el control de versión centralizado, lo que significa que sólo una copia maestra del software es utilizada.

Git se enorgullece de ser un sistema rápido y eficaz, y muchos grandes proyectos de código abierto usan Git para potenciar sus repositorios, proyectos como: Linux Kernel, WINE, Fedora, entre otros.

12

Figura 3: GitHub

11 12

Leopard: Sistema Operativo de los ordenadores Mac Fuente de la imagen: https://github.com/timeline

17

GitHub ha ayudado recientemente a establecer a Git como un gran sistema de control de versiones, proveyendo de una hermosa interfaz para muchos proyectos, tales como Rails y Prototype. Sin embargo, Git no es de fácil uso como lo son CVS o SVN, así que es mucho más difícil de usar para un principiante.

1.1.4

Mercurial

Mercurial es otro sistema de control de versiones distribuido de código abierto, como Git. Fue diseñado para grandes proyectos, muy probablemente fuera del alcance de desarrolladores Web independientes. Eso no quiere decir que los equipos de desarrollo pequeños no pueden o no deben usarlo. Mercurial es extremadamente rápido, y los creadores del software han incorporado al rendimiento como la característica más importante. El nombre “Mercurial” es un adjetivo que significa “Relativo a, o que tenga características (elocuencia, rapidez, inteligencia) atribuidas al Dios Mercury”

13

Figura 4: Interfaz Web de Mercurial

13

Fuente de la imagen: http://mercurial.selenic.com/wiki/

18

Aparte de ser muy rápido y estable, Mercurial es un sistema mucho más simple que Git, por lo que atrae a algunos desarrolladores. No hay muchas funciones para aprender, y las funciones son similares a la de otros CVSs14. También viene equipado con una sola interfaz Web, y una extensa documentación para entender Mercurial.

1.1.5

Bazaar

Bazaar es otro sistema de control de versiones distribuidor, como Mercurial o Git, que ofrece una experiencia de usuario muy amigable. Se llama a sí mismo “El control de versiones para los seres humanos”. Es compatible con muchos tipos diferentes de flujos de trabajo, desde solitario a centralizado hasta descentralizado, con muchas variaciones entre ellos.

15

Figura 5: Flujo de trabajo

Una de las principales características de Bazaar es el gran detalle de control que se tendrá sobre la configuración. Como se muestra en la figura 5, se puede utilizar para adaptarse a casi cualquier escenario de los usuarios y configuraciones. Este es un sistema de control de revisiones ideal para casi cualquier proyecto porque es muy fácil de modificar. También es integrable, por lo que se puede añadir a los proyectos existentes.

14 15

CVS: Sistema de Control de Versiones (Control Version System) Fuente de la imagen: http:// doc.bazaar.canonical.com

19

16

Figura 6: Comunidad Bazaar

Bazaar tiene una comunidad fuerte, que mantiene plugins y muchas herramientas de otros fabricantes, como software GUI para añadir una interfaz gráfica al sistema.

1.1.6

Libre Source

LibreSource es un portal Web para la gestión de proyectos de colaboración. Se basa en Java/J2EE y es más un conjunto de herramientas visuales de colaboración para ayudar a facilitar proyectos y equipos. Mientras que los otros sistemas analizados hasta ahora se han diseñado en un nivel de “líneas de comandos”, LibreSource se centra más en las herramientas que no tienen una gran curva de aprendizaje.

17

Figura 7: Comunidad LibreSource

16 17

Fuente de la imagen: http://wiki.bazaar.canonical.com/Download Fuente de la imagen: http://dev.libresource.org/

20

Cuenta con funciones integradas tales como las páginas wiki, foros, seguidores, sincronizadores, repositorios de Subversion, archivos, áreas de descarga, buzones, formularios, mensajes instantáneos y más. LibreSource es más como un centro de colaboración para el desarrollo del proyecto.

LibreSource es perfecto para el desarrollador que no quiere aprender mucho lenguaje técnico y quiere centrarse más en la comunicación con los miembros del proyecto. Sólo tiene que instalar el paquete y empezar a colaborar, sin hacer frente a gran parte de una curva de aprendizaje.

1.1.7

Monotone

Monotone es el más reciente de los sistemas de control de versiones distribuidos.

Mientras que muchos se centran en el rendimiento de Monotone, Monotone pone mayor valor a la integridad que al rendimiento. De hecho, puede tomar algo de tiempo para que el nuevo usuario de Monotone pueda descargar el repositorio inicial, debido a la extensiva validación y autenticación requerida.

18

Figura 8: Página Web de Monotone

18

Fuente de la imagen: http://www.monotone.ca/

21

Monotone es bastante fácil de aprender si se está familiarizado con los sistemas de CVS, y también se puede importar proyectos de CVS anteriores. Sin embargo, no es tan popular como los otros sistemas de control de versiones.

1.2

ANÁLISIS DE VERSIONES

LOS

DISTINTOS

SISTEMAS

DE

CONTROL

DE

Al analizar individualmente cada uno de los mejores sistemas de control de versiones open source, se ha encontrado que existen dos tipos de sistemas de control de versiones, los centralizados y los distribuidos.

Encontrando que los primeros sistemas en desarrollarse fueron los centralizados, y luego se pasaron a desarrollar los sistemas distribuidos. 

Centralizados: CVS, SVN, LibreSource



Distribuidos: Git, Mercurial, Bazaar, Monotone

Debido a que LibreSource en realidad usa Subversion como repositorio se obviará en el análisis, y se analizará por los dos grupos eligiendo al mejor.

1.2.1

Comparación entre CVS y SVN

En el formato del repositorio CVS se basa en archivos de versiones de control RCS. Cada archivo vinculado con CVS es un archivo ordinario conteniendo alguna información adicional. Es muy natural que el árbol de estos archivos se replique en el directorio local.

Es decir que no hay que preocuparse por la pérdida de datos, pues se puede corregir fácilmente en los archivos RCS si fuera necesario. En cambio SVN se basa en una base de datos relacional (BerkleyDB) o conjunto de archivos binarios (FS_FS). Por un lado esto trae algunos problemas, por ejemplo, en el acceso simultaneo a través del archivo compartido, pero permite nuevas funcionalidades como transacciones en operaciones de rendimiento.

Sin embargo, el almacenamiento de datos ya no es transparente, es decir que el usuario no puede intervenir directamente, pero cuenta con utilidades para la curación o recuperación del repositorio que el mismo sistema provee.

Respecto a la velocidad, CVS trabaja más lentamente que SVN, debido a algunas soluciones constructivas de SVN. SVN logra transmitir menos información a través de la

22

red y soporta más operaciones en el modo fuera de línea. Sin embargo, el aumento de la velocidad se logra básicamente a expensas de tener una copia de seguridad completa en el propio ordenador.

En lo referente a etiquetas19 y ramas20 CVS lo aplica correctamente, pero SVN ha sustituido el concepto de etiquetas y ramas por la capacidad de realizar copias de archivos o directorios en el repositorio con el guardado del historial de cambios. Esto provoca que se requiera de una numeración universal para los archivos, es decir el repositorio completo obtiene un número de revisión y no cada archivo por separado.

CVS permite almacenar únicamente archivos, en cambio SVN permite conectar a un archivo cualquier meta dato.

CVS inicialmente fue pensado para almacenar datos de texto. Esto provoca que se realicen ajustes tanto en el servidor como en el cliente cuando se requiera almacenar archivos binarios, en cambio SVN maneja cualquier tipo de archivo y no requiere de instrucciones especiales.

Referente al retroceso, CVS permite deshacer (rollback) cualquier compromiso (commit) en el repositorio, aunque esto requiere cierto tiempo, en cambio SVN no permite hacer rollback de commits pero se puede hacer una copia del repositorio de buen estado hasta el final para reemplazar el commit erróneo. Sin embargo el commit erróneo permanecerá en el repositorio con su respectivo número de revisión.

En CVS el soporte a las transacciones de “todo o nada” está totalmente ausente, es decir que si al transferir todos los archivos del servidor y algunos archivos presentaran conflictos y no se transfirieran, al corregir y repetir la transacción se debieran transferir, pero este no es el caso. Sin embargo SVN tiene operaciones de soporte para el principio del “todo o nada”.

19

Etiqueta: Darle a alguna versión de cada uno de los ficheros del módulo en desarrollo en un momento preciso un nombre común ("etiqueta" o "rótulo") para asegurarse de reencontrar ese estado de desarrollo posteriormente bajo ese nombre.

20 Rama: Un módulo puede ser branched o bifurcado (“rama”) en un momento de tiempo de forma que, desde ese momento en adelante, dos copias de esos ficheros puedan ser desarrolladas a diferentes velocidades o de diferentes formas, de modo independiente.

23

Inicialmente CVS fue escrito como muchos scripts en torno a RCS21 ejecutable, por lo que la estructura interna del código es pobre y tiene muchas correcciones históricas, por lo que extender la funcionalidad de CVS no ha tenido éxito. En cambio SVN tiene una arquitectura interna donde realmente se pasó tiempo permitiendo realizar mejoras, el código es muy ampliable.

Después de este análisis entre CVS y SVN, se llegó a la conclusión de que SVN es el mejor sistema de control de versiones centralizado, pero a pesar de tener puntos en contra, estos se pueden contrarrestar con las alternativas que provee el mismo sistema, además de que SVN maneja cualquier tipo de archivo, lo que es importante para este proyecto debido a que los sistemas académico y contable de la PUCE SD están desarrollados en Oracle, es decir archivos binarios, y CVS causaría muchos inconvenientes.

A continuación observaremos las características de los sistemas de control de versiones distribuidos, se realizará en parejas para lograr una mayor profundidad.

1.2.2

Comparación entre Git y Mercurial

Ambos Git y Mercurial se iniciaron aproximadamente en el mismo tiempo y con objetivos similares, la de reemplazar al sistema BitKeeper que se estaba utilizando para los requerimientos de control de versiones en proyecto del kernel de Linux. El proyecto del kernel de Linux decidió usar Git en lugar de Mercurial, pero Mercurial ahora es utilizado por muchos otros proyectos.

Las principales metas del diseño de Mercurial incluyen un alto rendimiento, escalabilidad22, independencia de un servidor, ser totalmente distribuido, contar con avanzada capacidad de ramificación y mezcla, detectar archivos de texto y binarios, sin dejar de ser conceptualmente simple. Incluye una interfaz Web integrada.

En cambio las metas principales del diseño de Git fueron la velocidad y la eficiencia de las operaciones. Otros criterios del diseño incluyen fuertes salvaguardias contra la corrupción, ya sea accidental o maliciosa.

21

RCS: Sistema de Control de Revisiones (Revision Control System), es una implementación software del control de versiones que automatiza las tareas de guardar, recuperar, registrar, identificar y mezclar versiones de archivos.

22 Escalable: Sistema que puede crecer según se incrementen los requerimientos.

24

Mercurial fue escrito inicialmente para ejecutarse en Linux. Ha sido portado a Windows, Mac OS X, y la mayoría de sistemas parecidos a Unix. Mercurial es un sistema principalmente de línea de comandos. De igual forma Git también fue desarrollado principalmente en Linux, y puede ser utilizado en otros Sistemas Unix como BSD y Solaris. También se ejecuta en Windows.

Git no es un sistema monolítico, posee una gran variedad de herramientas individuales, que van del alto al bajo nivel23, es decir con Git se puede hacer trabajar muy bien, Git incluye: Wiki, seguimiento de incidencias, sistemas de archivos, herramientas de administrador de sistemas, etc. En cambio Mercurial si es un sistema monolítico e incapaz de ajustarse a las necesidades.

Entre las ventajas de Mercurial sobre Git es que tiene una excelente documentación, mejor limpiador de comandos, comandos intuitivos, y un completo cliente para Windows.

Las desventajas es que la forma en que se nombran a las ramas es deplorable, y la manera de crear una rama es clonando todo el repositorio, lo que no hace viable el trabajo entre ramas. También la reescritura del historial es difícil, en cambio Git lo puede hacer fácilmente y sin tantos mensajes inútiles. La fortaleza de Git es que permite crear nuevas ramas en cualquier momento, además de permitir alternar entre ellas en una copia de trabajo. Otra fortaleza es que permite ramas remotas, es decir, puede enviar y recibir cambios de varios repositorios públicos. Esto es útil cuando se tenga que publicar más de una rama, así otros pueden descargar los cambios. Sin embargo, Git es más confuso, hay más comandos por defecto, y son difíciles de seguir en un primer momento.

En conclusión Git es más flexible y se tendrán ventajas al trabajar en un equipo grande, en cambio Mercurial es más fácil de usar y será más fácil de tratar si se trabaja en proyectos pequeños. Por lo que se seguirá el análisis con Git ya que Mercuarial no es muy bueno creando ramas para las funciones que se desarrollen, además no hace un buen trabajo en el empuje de cambios desde repositorios públicos.

23

Desde programas con características adecuadas a la capacidad cognitiva humana, hasta programas de instrucciones aritmeticológicas.

25

1.2.3

Comparación entre Git y Bazaar

A nivel de comandos Git es más difícil de usar que Bazaar, ya que utiliza terminología similar para hacer cosas diferentes, lo que causa confusión, en cambio Bazaar usa una terminología mucho más natural, similar a la de SVN. Lo bueno de Git es que siempre se trabaja en el mismo directorio principal, por lo que uno no tiene que preocuparse de trabajar en la rama correcta, solo hay que preocuparse de escribir bien el código y del sistema de versionado, en cambio Bazaar puede provocar a menudo errores al comenzar un cambio de rama, lo que causaría que se tengan que copiar las modificaciones y luego revertir, convirtiéndose en una tarea tediosa.

El soporte de Git para Windows no es tan bueno, y la aplicación cliente gitHub aún no está muy desarrollada, en cambio Bazaar funciona en todas las plataformas incluyendo Windows.

Respecto a la velocidad, Git es más rápido que Bazaar, aunque Bazaar funciona suficientemente rápido para una amplia gama de proyectos, pero se vuelve lento cuando el historial se agranda a más de diez mil cambios.

En los repositorios con un largo historial, Git es más eficiente en el almacenamiento de datos que Bazaar. El repositorio de Git puede ser empaquetado de forma eficiente y con ajustes inteligentes.

Una diferencia clave entre Git y Bazaar es que las ramas son directorios en Bazaar, mientras que estos son nombres internos en el repositorio en Git. En conclusión, Bazaar es una buena elección si se desea trabajar en Windows, y es más fácil de usar, pero al pasar el tiempo se tornará lento por la cantidad de cambios en el historial, en cambio Git es más rápido y eficiente, sin importar el número de cambios en el tiempo, aunque tenga un poco de problemas en Windows, por lo que se continuará el análisis con Git.

1.2.4

Comparación entre Git y Monotone

Monotone tiene una filosofía diferente a los otros sistemas de control de versiones distribuidos, es decir, de los cambios destinados a un depósito (cuya comunicación se realiza mediante un protocolo propio llamado netsync), Monotone recoge los cambios

26

desde varias fuentes. Luego, cada desarrollador hace commit de los cambios deseables en su propio repositorio privado sobre certificados RSA, entre otros parámetros.

Monotone identifica las versiones de archivos y directorios mediante la comprobación de suma SHA1. Por lo tanto, puede identificar cuando un archivo fue copiado o movido, si la firma es idéntica y fusiona las dos copias. También tiene un conjunto de comandos que tratan de imitar al CVS tanto como sea posible.

A pesar de que la arquitectura de Monotone hace la implementación de muchas características más fácil, no deja de tener defectos, además es lento y no escala bien para grandes bases de códigos, no así Git, que puede escalar y es rápido.

Como se ha revisado anteriormente, Git es la mejor herramienta respecto de los sistemas de control de versiones distribuidos, es el más rápido, eficiente y escalable que los demás, a pesar de ser difícil de manejar a nivel de consola, y de ser un poco lento en sistemas Windows.

Ahora se realizará el análisis entre Git y SVN tanto de sus características como sistemas de control de versiones como de su forma de funcionamiento, centralizado y distribuido, y posteriormente se llegará a la solución más factible para la PUCE SD.

1.2.5

Comparación entre Git y SVN

Git es mucho más rápido que Subversion. Pero Subversion permite realizar chekout24 de un subárbol del repositorio, en cambio Git requiere clonar todo el repositorio, incluyendo el historial, y crear una copia de trabajo que refleje por lo menos un subconjunto de los elementos bajo el control de versión.

Los repositorios Git son mucho más pequeños que los de Subversion, una de las razones por las que el tamaño en SVN es mayor, es que contiene dos copias de cada archivo, uno para el usuario, para el espacio de trabajo; y otro en un directorio oculto en .svn/ para operaciones de ayuda. A diferencia de un directorio de trabajo Git solo requiere un pequeño archivo de índice que almacena cerca de 100 bytes de datos por archivo de seguimiento. En proyectos con un gran número de archivos, puede haber una diferencia sustancial en el espacio de disco requerido, por copia de trabajo.

24

Checkout: Traer una copia del código en el repositorio al espacio de trabajo.

27

Git fue diseñado para ser totalmente distribuido desde el inicio, permitiendo a cada desarrollador tener el control local completo.

Las ramas en Git son más simples y menos pesadas que con Subversion, aparte de que llevan en ellas toda su historia, y proporciona una mejor auditoría.

Los formatos de archivos en Git son simples, hacen que la reparación sea simple y la corrupción25 es rara.

Sin embargo sacar una copia de seguridad del repositorio es mucho más fácil en Subversion que en Git. Aunque los repositorios clones de Git actúan como completas copias de seguridad del repositorio.

La interfaz de usuario de Subversion es más madura que la de Git, y la navegación entre versiones es más simple en Subversion, ya que utiliza secuencias de revisión, en cambio Git usa hash SHA-1, los cuales son impredecibles, lo que hace que la navegación sea muy difícil.

Tanto Subversion como Git pueden detectar si el archivo con el que trabajan es binario o de texto, pero si se realiza un cambio aparentemente menor en el archivo, Git podría interpretarlo como un archivo nuevo, dividiendo el contenido del historial. En cambio Subversion rastrea por archivo, la historia de esos cambios se mantiene.

Dado que Subversion sólo admite un único repositorio, hay poca duda de donde se almacena algo. Una vez que el usuario conoce la URL del repositorio, se puede asumir que todos los materiales y todas las ramas relacionados al proyecto estarán siempre disponibles en esa ubicación. También las copias de seguridad se facilitan, pues es solo una única ubicación la que necesita ser respaldada regularmente.

Como Git es distribuido por naturaleza, es decir, no todo lo relacionado con un proyecto se puede almacenar en el mismo lugar, puede haber un cierto grado de confusión sobre dónde obtener una rama en particular, a menos que la ubicación del repositorio esté siempre explícitamente especificada. También puede haber cierta confusión acerca de cuál repositorio fue respaldado y cual no lo fue.

Como Subversion tiene un único repositorio central, es posible especificar controles de acceso de lectura y escritura en una sola ubicación, y se aplica a todo el proyecto.

25

Corrupción: Archivos dañados.

28

1.3

SELECCIÓN DEL SISTEMA DE CONTROL DE VERSIONES A UTILIZAR

En conclusión tanto Subversion como Git, son excelentes herramientas con las cuales trabajar, sin embargo hay que tomar en cuenta en donde se las va a utilizar para elegir la mejor opción, en cuanto a este proyecto se ha elegido a Subversion como el sistema de control de versiones a utilizar, por las siguientes razones: 

El modelo de Subversion se ajusta más a la infraestructura de la PUCE SD que el modelo de Git, por cuanto al uso de un servidor para la administración y respaldo del repositorio.



Como los desarrolladores se encuentran en una misma área local, la velocidad de transferencia de los archivos desde cada ordenador al repositorio central es alta.

A pesar de que Git es más rápido, no es tanta la diferencia si se trabaja en un entorno local.



Dado que los archivos con los que los desarrolladores trabajan son binarios (archivos de Oracle), se elige Subversion pues maneja mucho mejor estos archivos que Git.



La curva de aprendizaje de Subversion es más rápida que la de Git, por lo que se ajusta más a los desarrolladores actuales de la PUCE SD, pues no tienen experiencia en el uso de sistemas de control de versiones. Git sería una opción en el futuro, cuando estos adquieran más experiencia con el uso de Subversion.



Subversion trabaja bien tanto en Linux como en Windows, y como los desarrolladores trabajan actualmente en sistemas Windows, se elige Subversion, debido a que Git tiene un poco de problemas de velocidad al trabajar en Windows.

Git sin embargo sería una excelente opción si se trabajara en proyectos open source, donde se involucraría a desarrolladores independientes, que estuvieran en diferentes partes del mundo, una estructura no tan “corporativa” como la actual en la PUCE SD.

1.4

ARQUITECTURA DE SUBVERSION

La figura 9 ilustra una amplia vista del diseño de Subversion, donde en un extremo se encuentra el repositorio, el cual soporta todos sus datos versionados. Y en el otro extremo encontramos a los programas clientes de Subversion, los cuales manejan

29

reflejos locales de partes de esos datos versionados, llamados “copias de trabajo”. Entre estos extremos encontramos múltiples rutas a través de varias capas de acceso al repositorio. Algunas de estas rutas se realizan a través redes de computadoras, e incluso a través de redes de servidores.

26

Figura 9: Arquitectura de Subversion

En el núcleo de Subversion se encuentra un repositorio, el cual es un almacén de datos.

El repositorio almacena la información en forma del árbol de un sistema de archivos.

Cualquier cantidad de aplicaciones clientes pueden conectarse al repositorio y leer o escribir en estos archivos. Al escribir los datos, la aplicación cliente hace disponible la información para otros; al leer la aplicación cliente recibe la información de los otros.

En la figura 10 “Un sistema típico cliente/servidor” suena como la definición típica de un servidor de archivos. Sin embargo lo que hace a Subversion especial es que puede

26

Fuente de la imagen: http://svnbook.spears.at/nightly/es/svn-book.html

30

recordar cada cambio escrito en él, cualquier cambio a cualquier archivo o directorio, así como añadir, eliminar o reorganizar los archivos o directorios.

27

Figura 10 Un sistema típico cliente/servidor

Cuando un cliente lee datos del repositorio, normalmente sólo ve la última versión del árbol de archivos. Sin embargo, el cliente también tiene la posibilidad de ver estados previos del sistema de archivos.

Todos los sistemas tienen que resolver el mismo problema fundamental: ¿Cómo pueden estos sistemas permitir a los usuarios compartir información pero previniendo que accidentalmente se choquen los códigos de unos con los de otros? Es muy fácil que accidentalmente un usuario sobreescriba en los cambios de otro programador en el repositorio.

Considerando el escenario mostrado en la siguiente figura 11 “El problema a evitar”, supone a dos desarrolladores: Carlos y Samuel. Ambos deciden editar el mismo archivo del repositorio al mismo tiempo. Si Carlos guarda su archivo en el repositorio primero, es posible que Samuel en unos momentos después lo sobre escriba con su nueva versión del archivo accidentalmente.

27

Fuente de la imagen: http://svnbook.spears.at/nightly/es/svn-book.html

31

28

Figura 11 El problema a evitar

Si bien es cierto que la versión del archivo de Carlos no se ha perdido para siempre, ya que el sistema recuerda cada cambio, cualquier cambio que Carlos haya hecho no va a aparecer en la nueva versión del archivo de Samuel, porque él nunca vio los cambios de Carlos para comenzar. El trabajo de Carlos sigue perdido o al menos ausente de la última versión del archivo. Y este es el problema a evitar.

Muchos sistemas de control de versiones utilizan el modelo bloquear-modificardesbloquear, para solventar este problema, que tienen muchos desarrolladores con el trabajo de otros.

En un modelo como este, el repositorio permite a una sola persona modificar un archivo a la vez. Esta política usa exclusivamente bloqueos.

Carlos debe bloquear un archivo antes de poder comenzar a realizar cambios. Bloquear un archivo se parece mucho a pedir prestado un libro a una biblioteca; si Carlos ha bloqueado un archivo, entonces Samuel no podrá bloquearlo porque el repositorio rechazará la petición, y por tal razón tampoco podrá editarlo. Todo lo que él puede hacer es leer el archivo y esperar a que Carlos termine de realizar sus cambios y deshaga su

28

Fuente de la imagen: http://svnbook.spears.at/nightly/es/svn-book.html

32

bloqueo. Después de que Carlos desbloquee el archivo, Samuel podrá tomar su turno de bloquear el archivo y comenzar a editar en él.

El problema con el modelo bloquear-modificar-desbloquear es que es un poco restrictivo y a veces se vuelve un camino sin salida para los desarrolladores.

Subversion, CVS y muchos otros sistemas de control de versiones usan el modelo copiarmodificar-fusionar, es una alternativa al bloqueo. En este modelo cada programa cliente del usuario contacta al proyecto del repositorio y crea una copia de trabajo, un reflejo local de los archivos y directorios del repositorio. Los usuarios pueden entonces trabajar simultánea e independientemente, modificando su copia privada. Finalmente, las copias privadas son fusionadas juntas en una nueva versión final. El sistema de control de versiones frecuentemente asisten con la fusión, pero al final un humano es responsable de que esto ocurra correctamente. La figura 12 “Bloquear-modificar-desbloquear” ilustra una demostración de esto.

29

Figura 12 Bloquear-modificar-desbloquear

29

Fuente de la imagen: http://svnbook.spears.at/nightly/es/svn-book.html

33

En este ejemplo Carlos y Samuel realizan una copia de trabajo del mismo proyecto (copiado del repositorio). Ellos trabajan concurrentemente y hacen cambios en el mismo archivo A con sus copias. Samuel guarda sus cambios al repositorio primero. Luego, cuando Carlos intenta guardar sus cambios, el repositorio le informa que su archivo A está fuera de fecha. En otras palabras, el archivo A en el repositorio de alguna manera ha cambiado desde que él la copió por última vez. Así que Carlos le pide al programa cliente que fusione cualquier nuevo cambio desde el repositorio en su copia de trabajo del archivo A. Existe la posibilidad de que los cambios de Samuel no solapen con los de Carlos. Una vez que ambos tengan los cambios integrados, él podrá guardar su copia de trabajo de regreso en el repositorio. La figura 13 “La solución copiar-modificar-fusionar” y la figura 14 “La solución copiar-modificar-fusionar (continuado)” muestran este proceso.

30

Figura 13 La solución copiar-modificar-fusionar

30

Fuente de la imagen: http://svnbook.spears.at/nightly/es/svn-book.html

34

31

Figura 14 La solución copiar-modificar-fusionar (continuado)

¿Pero qué pasa si los cambios de Samuel sí solapan los cambios de Carlos? Esta situación se llama Conflicto, y es usual, sin embargo un problema. Cuando Carlos le pide a su programa cliente que fusione los últimos cambios del repositorio en su copia de trabajo, su copia del archivo A es de alguna forma cambiada al estado de Conflicto. Note que todas las herramientas no pueden automáticamente resolver estos conflictos; sólo los humanos son capaces de entender y realizar las decisiones inteligentes necesarias. Una vez que Carlos ha resuelto manualmente los cambios de solape, luego de discurtirlo con Samuel, puede con seguridad guardar el archivo fusionado de regreso en el repositorio.

El modelo de copiar-modificar-fusionar puede sonar un poco caótico, pero en la práctica, corre extremadamente bien. Los desarrolladores pueden trabajar en paralelo. Nunca esperar por el otro. Cuando ellos trabajan en un mismo archivo, resulta que la mayoría de sus concurrentes cambios no solapan para nada; los conflictos son poco frecuentes. Y la

31

Fuente de la imagen: http://svnbook.spears.at/nightly/es/svn-book.html

35

cantidad de tiempo que lleva resolver un Conflicto es usualmente menos que el tiempo perdido mediante el modelo de bloqueos.

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.

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 Carlos o Samuel perderán sus cambios.

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

Por lo tanto en lo que respecta a este proyecto, los desarrolladores deberán usar el modelo de Subversion de bloquear-modificar-desbloquear, puesto que los archivos que trabajan son binarios (archivos de Oracle) y no se podrán fusionar. Sin embargo estará presente la solución de copiar-modificar-fusionar en caso de que en el futuro la PUCE SD decidiera pasar sus sistemas a desarrollos en archivos de texto plano.

36

2

METODOLOGÍA

El equipo de trabajo utilizó el método sistémico en la elaboración de este proyecto, porque fue necesario estudiar las componentes que compondrían al sistema y como se relacionarían entre sí, para lograr una sinergia que de soporte al control de desarrollo de los sistemas académico y contable de la PUCE SD.

2.1

COMPONENTES DEL SISTEMA

Con el fin de cubrir todas las necesidades de los desarrolladores, se requieren de herramientas complementarias que ayuden a Subversion a extender su funcionalidad. Es por esto que se presentan las mejores herramientas que permitirán sacarle el mayor provecho a Subversion.

Trac Interfaz Web

VisualSVN Server

TortoiseSVN Aplicación Cliente 32

Figura 15: Componentes del Sistema

2.1.1

VisualSVN Server

VisualSVN Server permite instalar y administrar fácilmente un servidor de Subversion totalmente funcional en la plataforma Windows.

Está basado en estándares abiertos y ofrece estabilidad y facilidad de uso, además de seguridad y rendimiento.

Es distribuido como un único paquete de instalación, con las últimas versiones de todos los componentes necesarios. El proceso de instalación es extremadamente simple y permite configurar un sistema completo y listo para usar en unos pocos clics. Las actualizaciones a nuevas versiones son también simples.

32

Fuente de la imagen: Diseñado por los disertantes

37

VisualSVN Server proporciona una amigable consola de gestión denominada VisualSVN Server Manager, que permite: 

Crear, importar y eliminar repositorios.



Crear y eliminar carpetas en el repositorio.



Mostrar el estado del servidor de Subversion.



Administrar la política de seguridad de Subversion.



Iniciar, detener y reiniciar el servicio.



Navegar entre los repositorios.



Administrar usuarios y grupos.



Modificar las ramas de Subversion.

También permite usar cualquier cliente de Subversion para acceder al servidor o con un navegador Web, para conducirce rápidamente a través de los repositorios.

Las principales características de VisualSVN Server son: 

Listo para funcionar.



Potente gestión de consola.



Autenticación integrada de Windows.



Administración remota del servidor.



Registro operacional y de acceso.

2.1.2

TortoiseSVN

TortoiseSVN es un cliente Subversion, implementado como una extensión al shell de Windows. Es un software realmente fácil de usar para la revisión de control, control de versiones o control de código fuente.

38

TortoiseSVN proporciona una agradable y fácil interfaz de usuario para Subversion.

Está liberado bajo la licencia GNU GPL. Lo que significa que es completamente gratis, incluyendo el código fuente.

TortoiseSVN puede utilizarse sin ningún tipo de restricciones y con cualquier herramienta de desarrollo.

Las principales características de TortoiseSVN son: 

Integración con la línea de comandos de Windows.



Puede ser usado sin un entorno de desarrollo.



Pequeñas imágenes decoran los íconos de los archivos y carpetas mostrando qué archivos o carpetas necesitan ser enviados al repositorio.



Disponible en 28 idiomas diferentes.



Muestra la diferencia de documentos de Office tales como los creados con Microsoft Word.

2.1.3

Trac

Trac es una herramienta de gestión de proyectos, principalmente de software, que unifica un sistema wiki con un sistema de seguimiento (issue tracking) con claras ventajas a la hora de trabajar con un repositorio de Subversion.

Trac es una propuesta minimalista para la gestión de proyectos software basados en web. Su meta es simplificar el rastreo efectivo y el manejo de problemas de software, mejoras y procesos totales.

Al trabajar con desarrolladores, trac les permite rastrear fácilmente los cambios en los códigos, así como dar soporte a las metas de desarrollo. Todos los aspectos de Trac han sido diseñados con la simple meta de ayudar a los desarrolladores a escribir software avanzado e imponiendo tan poco como sea posible en un grupo ya establecido, procesos y una cultura de desarrollo.

39

En trac viene incorporado una wiki para los desarrolladores, el cual les permite comunicarse entre ellos, llevar documentación del proyecto, en general realizar cualquier tipo de anotación.

Trac también permite el manejo de tickets que sirve para el rastreo de incidencias tal como lo hace Bugzilla o Jira, aunque no tan avanzado pero resulta bastante más sencillo de utilizar, sin embargo también puede trabajar en conjunto con estas aplicaciones gracias a que se le pueden añadir plugins.

Existe toda una gama de plugins para Trac, que permiten mejorar su funcionamiento de acuerdo a las necesidades de los desarrolladores, desde realizar gráficos de flujos hasta llevar un calendario en diagramas de gantt sobre los progresos en el desarrollo.

2.2

MODELO DEL SISTEMA

En la figura 15 se observa el modelo funcional del sistema y la relación entre sus componentes y los usuarios.

VisualSVN Server

retroalimentación /feedback

Sincronización Trac escritura/commits

lectura/updates

Usuarios

Revisiones

Desarrolladores

TortoiseSV N Sist. en desarrollo

Puesta en marcha

Sistemas en producción

Interacción

33

Figura 16: Modelo del Sistema

33

Fuente de la imagen: Diseñado por los disertantes

40

En este modelo los desarrolladores de los sistemas accederán al servidor de Subversion a través del cliente TortoiseSVN, para la lectura o escritura de los archivos de código fuente hacia el repositorio desde sus ordenadores.

Los desarrolladores podrán acceder también al repositorio desde la interfaz Web Trac, la cual se sincroniza con Subversion, para la revisión de la estructura de los proyectos, diferenciar las modificaciones entre versiones de archivos, y retroalimentar al sistema con las incidencias que los usuarios podrían encontrar en los sistemas puestos en producción al momento de interactuar con ellos.

El modelo presentado corresponde al enfoque sistémico, donde se identifica el rol de cada componente así como su interacción con las demás partes, procurando que el objetivo final sea la producción de un sistema óptimo.

2.3

ESTABILIZACIÓN DEL SISTEMA

En septiembre de 2009, se puso a prueba el sistema de control de versiones durante un año, implementándolo en la Corporación Nacional de Electricidad regional Santo Domingo, donde uno de los miembros del equipo labora como analista programador.

Durante ese año, el sistema ha sido capaz de adaptarse a las necesidades de la Corporación, bajo el mismo modelo presentado pero con la solución copiar-modificarfusionar, debido a que los archivos de código fuente con los que trabajan son de texto plano.

La principal adaptación del sistema durante el periodo de prueba, fue que se requería que personal externo a la Corporación pudiera acceder al repositorio para obtener actualizaciones del sistema que los desarrolladores habían realizado. Por lo que simplemente se movió el sistema a un servidor con IP pública donde el personal externo pudo tener acceso, y se creó un usuario con permisos únicamente al proyecto que necesitaban. De esta forma se observa que el sistema puede ser cerrado o abierto según las necesidades de la dirección.

También se notó la flexibilidad del sistema, cuando durante el periodo de prueba se requirió que el sistema fuera adaptado como un repositorio de documentos de ofimática, donde los empleados pudieran respaldar documentos importantes en caso de algún daño en sus equipos.

Hasta la fecha presente, el sistema sigue siendo usado llevando cerca de año y medio de funcionamiento y sin presentar inconvenientes, por lo que se considera al sistema estable en el tiempo.

Cumplido el año de prueba del sistema y verificado su estabilidad, se procedió a implementarlo en la PUCE SD.

41

2.4

IMPLEMENTACIÓN DEL SISTEMA

En noviembre de 2010 se procedió a instalar cada una de los componentes del sistema, en el departamento de software del CITIC de la PUCE SD. Como actualmente los sistemas académico y contable se encuentran desarrollados en Oracle, se instaló en un entorno Windows, material que se encuentra también en el anexo Guía de instalación en Windows.

Si en caso de que la PUCE SD decidiera implementar el sistema para proyectos futuros en un entorno Linux se podrán referir al anexo Guía de instalación en Ubuntu. Material que se hizo disponible al administrador del departamento, así como demás manuales y programas aquí planteados.

2.4.1

Instalación de VisualSVN Server

VisualSVN Server pesa menos de 6 MB y puede ser descargado de la siguiente dirección Web: http://www.visualsvn.com/server/

34

Figura 17 VisualSVN Server

34

Fuente de la imagen: http://www.visualsvn.com/server/

42

Una vez descargado VisualSVN Server de la página Web, se procede con la instalación, primero aparecerá la pantalla de bienvenida:

35

Figura 18 Pantalla de Bienvenida

Se presiona Next y se aceptan los términos en el acuerdo de la licencia:

36

Figura 19 Términos del Acuerdo de la licencia

35 36

Fuente de la imagen: Diseñado por los disertantes Fuente de la imagen: Diseñado por los disertantes

43

Se presiona siguiente y se dejan intactas las opciones por defecto:

37

Figura 20 Opciones por defecto

Luego procede a instalar al presionar el botón Install, y finalmente iniciar el servicio.

En seguida se aparecerá la consola, en donde se crearán los repositorios que se necesiten, dando clic derecho en la palabra “Repositories” y seleccionando “Create New Repository…”; se ingresa el nombre del repositorio, en este caso pucesd, no se selecciona la opción para crear la estructura por defecto (Trunk, Branches, Tags) y se acepta.

No se selecciona la opción de crear la estructura por defecto debido a que es más de un proyecto los que se van a ingresar en el repositorio, y se deberá crear esta estructura manualmente una vez se tengan creados los directorios para los sistemas académico y contable.

37

Fuente de la imagen: Diseñado por los disertantes

44

38

Figura 21 Repositorios para el sistema académico y contable

Se puede acceder al repositorio vía navegador, mediante la URL que muestra la consola en el estado del servidor.

También se puede copiar la URL de un repositorio específico dando clic derecho en el repositorio y seleccionando “Copy URL to Clipboard”, esto es útil para importar el proyecto al repositorio mediante TortoiseSVN. Respecto del acceso a la consola, se debe establecer la contraseña para el usuario administrador, el cual es el mismo al de inicio de sesión para Windows.

También se deben registrar a los demás usuarios que harán uso del repositorio, los cuales pueden ser administrados por grupos. Es posible establecer permisos de accesos a las carpetas del repositorio, por usuario o grupos de trabajo, dando clic derecho a una de las carpetas dentro del repositorio, seleccionando Properties permisos de acceso por cada usuario o grupo.

38

Fuente de la imagen: Diseñado por los disertantes

y estableciendo los

45

2.4.2

Instalación de TortoiseSVN

Se descarga el instalador de la página de TortoiseSVN: http://tortoisesvn.net/downloads Aparecerá la pantalla de bienvenida a TortoiseSVN al instalar:

39

Figura 22 Pantalla de bienvenida a TortoiseSVN

Se aceptan los términos del acuerdo de licencia, y los paquetes a instalar:

40

Figura 23 Paquetes de instalación

Se presiona instalar y finalizar, después el sistema operativo deberá reiniciarse:

39 40

Fuente de la imagen: Diseñado por los disertantes Fuente de la imagen: Diseñado por los disertantes

46

41

Figura 24 Instalación de TortoiseSVN

Hecho esto se procede a importar los espacios de trabajo de los dos proyectos en los repositorios correspondientes. Para ello hay que ubicarse en los directorios de los proyectos, en el explorador de Windows, clic derecho en la carpeta principal, seleccionar la opción TortoiseSVN, y clic en Import…, como en la figura 24.

42

Figura 25 Importación de los proyectos al repositorio

41 42

Fuente de la imagen: Diseñado por los disertantes Fuente de la imagen: Diseñado por los disertantes

47

Se abrirá una ventana en donde deberá ingresarse la URL del repositorio más el nombre del proyecto y más la palabra “trunk”, el cual es el lugar en donde se llevara el versionado del desarrollo, además se debe ingresar una breve descripción de lo que se ha hecho, lo cual es útil para búsquedas en el futuro, como se observa en la figura 25.

43

Figura 26 Importando a la URL del repositorio del sistema académico

Deberá autenticarse, con los datos que se establecieron en la consola administrativa:

44

Figura 27 Autenticación

48

Luego se comenzarán a copiar los archivos, carpetas y subcarpetas al repositorio, al terminar presionar el botón de OK. Se repite el proceso para ambos sistemas, con mismo repositorio.

Hecho esto, los archivos ya estarán en el repositorio, pero para trabajar con ellos se necesita crear una copia de trabajo, para lo cual deben borrarse de forma segura las carpetas de los proyectos, o moverlas a otra ubicación y realizar checkout ahí mismo.

El checkout permite copiar los archivos del repositorio al directorio actual, y trabajar sobre este, luego cualquier cambio realizado en los códigos se verá reflejado en el repositorio, simplemente dando clic derecho sobre un archivo o carpeta y pulsando update para actualizar la copia de trabajo o commit para actualizar el repositorio con los cambios realizados.

2.4.3

Instalación de Trac en Windows

Para instalar trac en Windows se necesitan algunos programas que tendrán que ser descargados de Internet, de las siguientes direcciones web (no realice ninguna instalación): Python 2.5 http://python.org/ftp/python/2.5.2/python-2.5.2.msi Trac http://ftp.edgewall.com/pub/trac/Trac-0.11.2.1.win32.exe SVN Python http://www.tigris.org/files/documents/15/45607/svn-python-1.6.1.win32-py2.5.exe Setuptools http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c7.win32py2.5.exe#md5=395a81d709766f3a0d6084964cb98b5a

43 44

Fuente de la imagen: Diseñado por los disertantes Fuente de la imagen: Diseñado por los disertantes

49

Genshi http://ftp.edgewall.com/pub/genshi/Genshi-0.5.1.win32-py2.5.exe Se procede a instalar, pero en el siguiente orden establecido: 1. Python 2. SVN Python 3. Setuptools 4. Genshi, y 5. Trac Luego se registran las variables de entorno, en las propiedades de Mi PC, en la pestaña “Opciones Avanzadas”, dirigirse a “Variables de entorno”, seleccionar “Path” y hacer clic en “modificar”, al final de la línea se ingresa lo siguiente: c:\Python25;C:\Python25\Scripts Esto evitará el estar ingresando la dirección absoluta a los scripts de trac, luego de esto se deberá reiniciar el sistema operativo.

2.4.3.1 Creación de un nuevo entorno en Trac Con los siguientes pasos se obtendrá una mínima configuración funcional de Trac para el funcionamiento del proyecto.

Crear una carpeta con el nombre “proyectos”, en la unidad C: Luego crear la carpeta trac, quedando de la siguiente manera: c:\proyectos\trac En el intérprete de comando (command prompt) para DOS de Windows, dirigirse al directorio anterior (c:\proyectos\trac\), y escribir lo siguiente: trac-admin pucesd initenv Esto instalará trac en el directorio: C:\proyectos\trac\pucesd

50

Pedirá cierta información. Primero el nombre del Proyecto, referente a este proyecto se ha ingresado “Sistemas Académico y Contable”.

Luego pedirá un string de conexión hacia una base de datos (como mysql u oracle), en este caso no se ingresa nada (por default es sqlite), y presiona enter.

Preguntará sobre el tipo de sistema de control de versiones a utilizar, ingresar svn y presionar enter.

Finalmente pedirá la dirección absoluta al directorio del repositorio. Ingresar C:/Repositories/pucesd (Notar que se ingresa con slash y no con backslash), y presionar enter.

Enseguida inicia la instalación.

Ejemplo: Project Name [My Project]> Sistemas Académico y Contable + [Enter] Database connecting string [sqlite:db/trac.db]> [Enter] Repository type [svn]>svn [Enter] Path to repository [/path/to/repos]> C:/Repositories/pucesd + [Enter] Al terminar, el nuevo entorno se habrá sincronizado con el repositorio de Subversion de la ruta establecida en “Path to repository”.

2.4.3.2 Personalización del entorno El entorno de Trac permite la personalización de su diseño para adaptarlo a la imagen de la institución.

En el archivo C:\proyectos\trac\pucesd\conf\trac.ini se encuentran etiquetas como [header_logo] que permitirá cambiar el logotipo y poner la dirección url hacia el logotipo de la PUCE SD, o como [project] para fijar el nombre del proyecto, entre otros.

Además en el directorio C:\proyectos\trac\pucesd\templates se pueden añadir plantillas personalizadas que tendrán preferencia sobre las del sistema. Existen plantillas que también se pueden instalar como plugins, listas para usar en:

51

http://trac-hacks.org/ 2.4.3.3 Estableciendo permisos de acceso Como el entorno de Trac se ejecuta en una interfaz Web que puede ser accedida a través de la red LAN o Internet, se deben establecer permisos de acceso al repositorio para que solo los miembros del equipo de desarrollo tengan acceso.

En el block de notas escribir las siguientes líneas de código: --from optparse import OptionParser import md5 # build the options usage = "usage: %prog [options]" parser = OptionParser(usage=usage) parser.add_option("-u", "--username",action="store", dest="username", type = "string", help="the username for whom to generate a password") parser.add_option("-p", "--password",action="store", dest="password", type = "string", help="the password to use") (options, args) = parser.parse_args() # check options if (options.username is None) or (options.password is None): parser.error("You must supply both the username and password") # Generate the string to enter into the htdigest file realm = 'trac' kd = lambda x: md5.md5(':'.join(x)).hexdigest() print ':'.join((options.username, realm, kd([options.username, realm, options.password])))

--Guarda en el directorio Scripts con el nombre: C:\Python25\Scripts\trac-digest.py Es un programa desarrollado con phyton que servirá para crear usuarios de trac, con sus respectivas contraseñas encriptadas con md5.

52

En el command prompt, con la siguiente instrucción se ejecuta el programa anterior: trac-digest.py -u "admin" -p adminpassword >> C:\proyectos\users.txt Donde admin es el nombre de usuario y adminpassword es su contraseña.

Repetir este proceso para registrar a todos los usuarios del sistema.

Todos los usuarios con sus contraseñas quedarán registrados en el archivo users.txt en el directorio C:\proyectos Se establece al usuario admin como el administrador de trac: trac-admin c:\proyectos\trac\pucesd permission add "admin" TRAC_ADMIN (Esto no retornará ninguna línea.)

Este usuario es el único que le aparecerá el menú "Admin" en la interfaz de Trac, para gestionar la configuración, plugins y permisos.

En el archivo C:\proyectos\trac\pucesd\conf\trac.ini, en la etiqueta [trac], ingresar lo siguiente: authz_file = C:\Repositories\authz (archivo de accesos de usuarios al repositorio) authz_module_name = pucesd (nombre del repositorio a acceder) Estas dos líneas aseguran los permisos de acceso a los archivos de acuerdo a los usuarios o grupos de trabajo.

2.4.3.4 Iniciando Trac Para iniciar el servicio de Trac, en el command prompt se escribe lo siguiente: tracd-script.py -p 80 --auth="*",C:\proyectos\users.txt,trac c:\proyectos\trac\pucesd Nota: Si no está disponible el puerto 80, cambiar por otro, por ejemplo el puerto: 8080. Si aparece la ventana del firewall de Windows, desbloquear.

53

La ventana del prompt debe quedar abierta. Si se cierra esta ventana, Trac también se cerrará. Esto se debe a que es una aplicación Standalone, de otra forma se ejecutaría junto a otro software como Apache para funcionar.

En el navegador Web ingresar a la siguiente URL: http://localhost/ (o http://localhost:8080, si se está usando ese puerto) Aparecerá un enlace con el nombre del proyecto que se le ha dado en la configuración, en este caso “Sistema Académico y Contable”. Al presionar ese enlace, entrará a la interfaz de trac. Presentará la página de bienvenida, como en la figura 27.

45

Figura 28 Pantalla de bienvenida a Trac

Esta pantalla muestra la Wiki, donde una vez que se haya iniciado sesión podrá modificarse, añadir enlaces y detalles de actualizaciones, que sirve para la comunicación sobre los cambios entre los integrantes del equipo.

También pueden agregar plugins que permiten al editor del Wiki insertar texto enriquecido, se pueden ingresar a través de códigos Genshi (ver anexo Manual de Usuario de Trac).

54

En la pestaña Browse Source, se encuentra el repositorio con los respectivos proyectos, como muestra la figura 28.

46

Figura 29 Vista del repositorio en Trac

Se muestra el sistema de archivos, Size (tamaño de los archivos), Rev (número de revisión), Age (Edad de los archivos), Last Change (autor: y acción del último cambio).

Al presionar el botón View changes, se verán los cambios con respecto de las versiones anteriores, diferenciándolos por su número de revisión.

Todos los módulos de Trac cuentan con información para su manejo, en la parte inferior está un enlace hacia las páginas de ayuda.

Para visualizar una versión anterior, ingresar su número de revisión en View revisión.

45 46

Fuente de la imagen: Diseñado por los disertantes Fuente de la imagen: Diseñado por los disertantes

55

Si no se recuerda del número de revisión para visualizar la versión anterior, también cuenta con el Timeline. En la pestaña Timeline se encuentra la bitácora de cambios, en donde se mostrará la fecha y hora, además de quién modificó tal archivo, como se muestra en la figura 29:

47

Figura 30 Bitácora de cambios en los códigos

En la pestaña New Ticket se van registrando las incidencias que los usuarios de los sistemas académico y contable pudieran encontrar, o para registrar nuevas mejoras que se vayan a realizar.

Cada ticket debe tener un inicio y un fin, un responsable y una prioridad, se asigna de acuerdo a los hitos o de acuerdo a los componentes.

Un ticket puede ser asignado por defecto en el software, por una actualización o por una tarea.

47

Fuente de la imagen: Diseñado por los disertantes

56

También posee un porcentaje de completado que se puede ir modificando para informar a los demás miembros del equipo de desarrollo de que tanto estamos trabajando por arreglar la incidencia, incluso se pueden adjuntar archivos a los tickets que ayuden a reconstruir la escena del por qué ocurrió dicha incidencia.

2.4.3.5 Instalación del plugin Gantt Calendar para Trac Uno de los requerimientos que se pedía para este proyecto por parte de uno de los miembros del equipo de desarrollo, fue que les permitiera observar en diagramas de Gantt el progreso de lo que han desarrollado, esto se soluciona con este plugin "Gantt Calendar", que puede ser encontrado en: http://trac-hacks.org/ Primero, debe parar el servicio de Trac, simplemente cerrando la ventana del intérprete de comandos en el que corre Trac. Luego en otro command prompt, en el directorio raíz de la unidad C: escribir lo siguiente: svn co http://recurser.com/svn/ganttcalendar/trunk/ ganttcalendar Esto hará una copia del repositorio especificado, en la carpeta ganttcalendar, que se crea en la raíz de la unidad C. Esto se puede hacer gracias a que se tiene instalado TortoiseSVN, esta es la forma de utilizar en líneas de comandos.

Antes de instalar, descargar el archivo easy setup de la siguiente dirección: http://peak.telecommunity.com/dist/ez_setup.py Este archivo se debe guardar en el directorio de los scripts de python: C:\Python25\Scripts\ Luego en el command prompt, escribir ez_setup.py, esto instalará varias dependencias que necesita Gantt Calendar para instalarse.

Por medio del intérprete de comandos ingresar a la carpeta C:\ganttcalendar y escribir: python setup.py install

57

Ingresar a travĂŠs del command prompt al directorio dist, C:\ganttcalendar\dist, y escribir lo siguiente: easy_install TracGanttCalendarPlugin-0.1-py2.6.egg En el explorador de Windows, abrir el archivo trac.ini ubicado el directorio C:\proyectos\trac\pucesd\conf, e ingresar el siguiente texto, justo antes de la etiqueta [header_logo]: [components] ganttcalendar.ticketcalendar.ticketcalendarplugin = enabled ganttcalendar.ticketgantt.ticketganttchartplugin = enabled Y debajo de la etiqueta [ticket], lo siguiente: [ticket-custom] complete = select complete.label = % Complete complete.options = 0|5|10|15|20|25|30|35|40|45|50|55|60|65|70|75|80|85|90|95|100 complete.order = 3 due_assign = text due_assign.label = Start (YYYY/MM/DD) due_assign.order = 1 due_close = text due_close.label = End (YYYY/MM/DD) due_close.order = 2 Guardar y cerrar.

Finalmente se ejecuta de nuevo el servidor para iniciar trac:

58

tracd-script.py -p 80 --auth="*",C:\proyectos\users.txt,trac c:\proyectos\trac\pucesd No olvidar cambiar a otro número de puerto, si no está libre el puerto 80. En el navegador Web se actualiza la página de la interfaz de Trac, se verá que se han añadido dos pestañas más, Calendar y Gantt Ticket, como en la figura 21:

48

Figura 31 Gantt Calendar

En Calendar se irán mostrando los tickets asignados por todos los miembros del equipo, o sólo los que el propio usuario haya creado. Filtra por hitos de trabajos y por fechas de asignación.

Llevar tickets es importante para la gestión de las incidencias, si se van a hacer mejoras al código, o arreglos.

En la siguiente figura, se muestra el diagrama de Gantt respecto de la fecha de asignación y de terminación de cada ticket.

48

Fuente de la imagen: Diseñado por los disertantes

59

49

Figura 32 Diagrama de Gantt

Como se ve no hay nada registrado, pero con el paso del tiempo, y de acuerdo a los progresos en el desarrollo, se obtendría un cuadro como el siguiente:

50

Figura 33 Diagrama de Gantt con varios Tickets

Este gráfico muestra de forma rápida cuánto falta para llegar a la fecha límite para la terminación del arreglo de una incidencia, extensión o desarrollo de un componente.

49 50

Fuente de la imagen: Diseñado por los disertantes Fuente de la imagen: http://recursive-design.com/blog/2008/11/26/gantt-calendar-plugin-for-trac/

60

2.5

SOCIALIZACIÓN DEL SISTEMA

Posterior a la implementación, se procedió con la socialización del sistema de control de versiones con todos los miembros del equipo de desarrollo del departamento de software del CITIC de la PUCE SD. Se entregaron las guías, manuales y programas descritos en este trabajo. Además de una guía rápida para empezar a trabajar con los archivos de Oracle. Se resolvieron inquietudes por parte de los desarrolladores, y se dio soporte a ciertos inconvenientes resueltos de forma satisfactoria. Quedando el sistema de control de versiones de los sistemas académico y contable instalado, y en pleno funcionamiento para el uso de los desarrolladores.

61

3

PROPUESTA

En este proyecto quedan plasmados los conceptos, teorías, modelos, procedimientos y programas para llevar a cabo el levantamiento de un sistema de control de versiones que no sólo funciona en Windows, sino también en Ubuntu Linux, así como los manuales de usuario para el uso diario de los componentes del sistema, además de una guía rápida para empezar a trabajar con archivos de Oracle en conjunto con el sistema de control de versiones.

Lista de resultados: 1. Guías de instalación Se entregan 2 guías de instalación en digital, una para Windows (ver Anexo 1) y otra para Ubuntu-Linux (ver Anexo 2), en donde se detalla paso a paso los procesos a seguir para el correcto levantamiento del sistema de control de versiones en ambos entornos.

También se entrega una guía rápida donde se explica de forma práctica para empezar a trabajar con Oracle (ver Anexo 5) usando el sistema de control de versiones, además muestra lo que se debe hacer en caso de encontrar incidencias.

2. Manuales de usuario Se entrega el manual de usuario en digital de TortoiseSVN (ver Anexo 3), en donde se detallan todos los aspectos de este programa para el uso diario por parte del equipo de trabajo, respecto de la gestión de los desarrollos de código fuente y sistemas de archivos en el área de trabajo de cada integrante y su trabajo en red.

Se entrega el manual de usuario de Trac en digital (ver Anexo 4), en donde se describen las características de todos sus módulos, tanto para el uso de la wiki, el timeline de cambios, la búsqueda de archivos de código fuentes actuales o de versiones anteriores, así como de la gestión de incidencias, entre otros, para trabajar tanto on-line o en Intranet desde un navegador Web. 3. Programas

62

Se entregaron todos los programas que se listan en la guía de instalación en Windows para el levantamiento del sistema de control de versiones, así como los dos scripts que se usan para la instalación, y un ejecutable para correr Trac de forma rápida. Todo el software utilizado en el sistema es libre (open source) y gratuito.

4. Sistema de control de versiones Como resultado final se instaló, configuró y se socializó un sistema de control de versiones en el departamento de software del CITIC de la PUCE SD a satisfacción de los integrantes del equipo de desarrollo del área. Contando con todos los complementos descritos en este trabajo. Una interfaz Web donde los desarrolladores pueden llevar una bitácora de los cambios en el software, realizar un seguimiento de los cambios en el código fuente, retroalimentar el desarrollo mediante las incidencias encontradas en los sistemas puestos en producción, y analizar el progreso del desarrollo en diagramas de Gantt. Además el sistema de control de versiones se puede adaptar a sistemas operativos Windows y Linux, al trabajo en Internet o en redes de área local, y a cualquier lenguaje de programación tanto de archivos binarios (Ej. Oracle, .NET) como archivos de texto plano (Ej. Java, PHP).

El llevar un sistema de control de versiones en el desarrollo de software es un proceso que “no sabes que lo necesitas hasta que conoces de él”, una vez que se conocen sus capacidades y el tiempo que ahorra, brinda seguridad, organización y productividad al realizar el trabajo de desarrollo de software.

No son sólo códigos, son horas y horas que pasan al frente del ordenador tratando de crear algo de la nada, y llevar un sistema que garantice el no tener que volver a escribir un código borrado anteriormente porque parecía que no era necesitario, ahorra bastante.

Conocer el porcentaje avanzado total del proyecto, cuánto falta por recorrer, el poder tratar las incidencias con profesionalismo, y dar soporte de forma inmediata marca un rango de diferencia grandísimo entre un programador y un desarrollador profesional.

Por esto, el proyecto presentado es de suma importancia para aquellas personas que quieran desempeñarse como desarrolladores de software, para poder realizar su trabajo de una forma profesional y organizada.

Respecto de los resultados obtenidos en este proyecto, cabe indicar se ha logrado cumplir a satisfacción de los interesados, los objetivos planteados.

63

El Sistema de Control de Versiones implementado en el departamento de software del CITIC

de la PUCE SD superó las expectativas, cumpliendo no sólo con los

requerimientos de los miembros del equipo de desarrollo, sino que cubre otras características no tomadas en consideración, como lo son el seguimiento de las incidencias en los sistemas puestos en producción, y la posibilidad de trabajar fuera del área de trabajo, es decir a través de Internet.

Todo esto con la mayor seguridad, por medio de claves de acceso encriptados y permisos específicos a los archivos de código fuente, por usuario o grupos de usuarios.

En este trabajo se ha encontrado que esta herramienta es muy útil para el trabajo en equipo y todos los desarrolladores deberían utilizarla. Y como se analizó, existen varios sistemas de control de versiones de los cuales se debe elegir aquel que se adapte mejor de acuerdo a las necesidades del proyecto a realizar.

64

4

CONCLUSIONES Y RECOMENDACIONES

En conclusión existen muchas herramientas que pueden ayudar a los desarrolladores a realizar mejor su trabajo, y muchas de ellas son open source como las mencionadas en este proyecto, y todo desarrollador debería estar al tanto de las capacidades que estas ofrecen.

En cuanto a la implementación del sistema de control de versiones en el departamento de software del CITIC de la PUCESD, se establecieron procesos y cultura de desarrollo, con la simple finalidad de ayudar a los programadores a escribir software de gran calidad, con lo que su tiempo de respuesta ante cambios en los sistemas se ha visto minimizado de manera significativa.

En conclusión, las ventajas que se obtuvieron al implementar el sistema de control de versiones son claras, se ha logrado optimizar el proceso de desarrollo de los sistemas académico y contable de la PUCE SD, garantizando que ningún código se pierda a través del tiempo, reduciendo el tiempo de respuesta ante incidencias, y estableciendo una cultura de trabajo en equipo.

Los miembros del equipo de desarrollo ahora pueden realizar un trabajo profesional con el uso de esta herramienta, podrán trabajar sin dificultades en redes LAN o WAN, cero inconvenientes a la hora de realizarles una auditoría, y ya no se preocuparán por que puedan perder sus códigos si se les daña el computador.

Si un nuevo miembro se añadiera al equipo de desarrollo, no encontrará ningún problema en ponerse al día con el sistema de control de versiones, gracias a la extensa documentación que se adjunta en este proyecto para el uso diario de las herramientas aquí presentadas.

Con esto queda claro que se han cumplidos con los objetivos planteados para este proyecto.

Sin duda los desarrolladores van a seguir utilizando el sistema de control de versiones en futuros proyectos de desarrollo de software.

65

Se recomienda que antes de aplicar un sistema de control de versiones a un nuevo proyecto, se analice si el presentado en este trabajo es el indicado, o si uno con un sistema distribuido satisface las necesidades.

Todo depende de los aspectos generales del proyecto, por ejemplo: ¿cuenta con un servidor para un sistema centralizado?, ¿manejarán sistemas de archivos de texto plano o binarios?, ¿trabajará en una red LAN o WAN?, estas son algunas preguntas que los miembros del equipo de desarrollo deberán plantearse antes de decidirse por cual sistema de control de versiones aplicar.

En caso de usar un sistema distribuido como Git en un proyecto, asegurarse de que los miembros del equipo de desarrollo hayan tenido experiencia en el uso de cualquier otro sistema de control de versiones, porque la curva de aprendizaje sería mayor si se planteara este sistema desde el principio.

Se recomienda establecer una política de respaldos del sistema de control de versiones centralizado, para asegurar que nada se pierda en caso de algún incidente con el servidor, tal como pudiera suceder con cualquier sistema de base de datos.

Es recomendable que todos los miembros del equipo conozcan muy bien cómo funciona el sistema, de esta forma se sacará un mayor provecho de las herramientas y se minimizarán los conflictos de código que pudieran suceder en el caso contrario.

Se recomienda también que el uso de estos sistemas de control de versiones para el desarrollo de software sea impartido en los estudiantes de los últimos niveles de la Universidad, pues son herramientas que sin duda van a necesitar en su actividad laboral.

66

BIBLIOGRAFÍA

Libros: Collins-Sussman, Ben; Fitzpatrick, Brian W. y Pilato, C. Michael (2008). Version Control with Subversion. Illinois, O'Reilly Media, 2ª Edición, 2004

Revistas: Smashing Megazine, Glen Stansberry, 7 Version Control System Reviewed, Septiembre 18 de 2008

Soporte electrónico: Trac Integrated SCM && Proyect Management, Trac Installation Guide for 0.12dev, http://trac.edgewall.org/wiki/TracInstall, 2009-08-10 Trac Integrated SCM && Proyect Management, http://trac.edgewall.org/wiki/0.11/TracOnUbuntu, 2009-08-11 Trac Integrated SCM && Proyect Management, http://trac.edgewall.org/wiki/TracIni, 2009-08-12

Trac

on

Ubuntu,

The Trac Configuration File,

Trac Integrated SCM && Proyect Management, Welcome to Trac Hacks, http://trachacks.org, 2009-08-13 CalinSoft V2 Tecnología, Wordpress y otras yerbas, Instalar Lamp + SVN + Trac en Ubuntu II, http://www.calinsoft.com/2009/04/instalar-lamp-svn-trac-en-ubuntu-ii.html, 2009-08-14 Trac Integrated SCM && Proyect Management, http://trac.edgewall.org/wiki/TracOnWindows, 2009-08-20

Trac

on

Windows,

Eliabd, Usando Subversion, Hudson y Trac en Ubuntu 9.04, http://eliabd.blogspot.com/2009/06/usando-subversion-hudson-y-trac-en.html, 2009-08-16 Community Ubuntu Documentation, https://help.ubuntu.com/community/UbuntuTracHowto, 2009-08-16

UbuntuTracHowto,

67

SolitaryGeek , NautilusSVN – The TortoiseSVN for Linux http://www.solitarygeek.com/linux/linux-version-control-svn-subversion-nautilusnautilussvn-ubuntu/, 2009-08-25

users,

TortoiseSVN, TortoiseSVN, http://tortoisesvn.net/docs/release/TortoiseSVN_es/index.html, 2009-08-29 How to solutions, How To Install Trac on Windows, http://how-to-solutions.com/how-toinstall-trac-on-windows.html, 2009-09-15 Recurser, Gantt Calendar plugin for Trac, http://recurser.com/articles/2008/11/26/ganttcalendar-plugin-for-trac/, 2009-08-30 UserLinux, Trac: Gantt Calendar, http://www.userlinux.net/trac-gantt-calendar.html, 200908-30

68

GLOSARIO

A Apache.- Es un servidor web HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual.

B Bugzilla.- Es una herramienta basada en Web de seguimiento de errores (bugs), (Bug Tracking System o BTS por sus siglas en inglés), originalmente desarrollada y usada por el proyecto Mozilla.

C Checkout.- Acción que permite copiar los archivos del repositorio a la máquina local.

Código fuente.- El simbólico acuerdo de datos o instrucciones en un programa de ordenador o el conjunto de dichas instrucciones.

Command prompt.- Es un programa informático que actúa como interfaz de usuario para comunicar al usuario con el sistema operativo mediante una ventana que espera órdenes escritas por el usuario en el teclado (por ejemplo, PRINT CARTA.TXT), los interpreta y los entrega al sistema operativo para su ejecución.

Conflictos semánticos.- Ocurre cuando las líneas código fuente no tienen una correspondencia de orden lógica.

Consola de gestión.- Programa para mantener y configurar el sistema.

Control de versiones.- Una versión, revisión o edición de un producto, es el estado en el que se encuentra en un momento dado en su desarrollo o modificación.

CVS.- Es una aplicación informática que implementa un sistema de control de versiones.

D Desarrollador.- Persona que escribe códigos para crear un sistema informático.

69

Diagrama de Gantt.- Es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado.

H Herramienta.- Programa software que usa el desarrollador para realizar su trabajo.

F Fusión Mezcla de los códigos de un programador con los códigos de otro programador.

G GENSHI Genshi es una biblioteca de Python que proporciona un conjunto integrado de componentes para el análisis, generación y procesamiento de HTML, XML o cualquier otro contenido textual para su generación en la web.

GPL Es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software.

I IDE Es un programa compuesto por un conjunto de herramientas para un programador.

Interface Programa que presenta por pantalla elementos que permiten al usuario interactuar con el sistema.

J Jira

70

Es una aplicación diseñada para mejorar el proceso de dar seguimiento a los defectos y errores, es decir mantener la trazabilidad de la información.

O Oracle Developer.- Entorno de desarrollo para realizar programas informáticos con tecnología Oracle P Plugins Es una aplicación que se relaciona con otra para aportarle una función nueva y generalmente muy especifica.

Programa cliente Aplicación que es utilizado por el usuario para utilizar las funciones de un programa servidor.

Python Es un lenguaje de programación interpretado creado por Guido van Rossum.

R Reflejos locales Copias exactas de los archivos ubicados en un servidor, en la máquina local.

Repositorio Sitio centralizado donde se almacena y mantiene información digital, habitualmente bases de datos o archivos informáticos.

S SCM Gestión de configuración de software es una especialización de la Gestión de configuración a todas las actividades en el sector del desarrollo de software.

SHA-1

71

Algoritmo de Hash Seguro, es un sistema de funciones hash criptográficas relacionadas de la Agencia de Seguridad Nacional de los Estados Unidos.

Shell Interfaz usada para interactuar con el núcleo de un sistema operativo.

SVN Significa Subversion y es un software de sistema de control de versiones diseñado específicamente para reemplazar al popular CVS, el cual posee varias deficiencias.

T Trunk Es el nombre del directorio en el repositorio en donde se desarrollará el código continuamente.

U URL Es una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos, como documentos e imágenes en Internet, por su localización.

V Versión En software, una versión es un número que indica el nivel de desarrollo de un programa.

Visual Source Safe Es una herramienta de Control de versiones que forma parte de Microsoft Visual Studio aunque está siendo sustituida por el Visual Studio Team Foundation Server.

W Wiki Es un sitio web cuyas páginas web pueden ser editadas por múltiples voluntarios a través del navegador web.

72

ANEXOS

73

ANEXO 1: GUÍA DE INSTALACIÓN EN WINDOWS

74

GUÍA DE INSTALACIÓN EN WINDOWS Instalación de VisualSVN Server VisualSVN Server pesa menos de 6 MB y puede ser descargado e instalado en un par de clics y además es completamente gratis. Se descargó de la siguiente dirección Web: http://www.visualsvn.com/server/

VisualSVN Server

Una vez descargado VisualSVN Server de la página Web, se procede con la instalación, primero aparecerá la pantalla de bienvenida:

Pantalla de Bienvenida

Presionamos Next y aceptamos los términos en el acuerdo de la licencia:

75

TĂŠrminos del Acuerdo de la licencia

Presionamos siguiente y dejamos intactas las opciones por defecto:

Opciones por defecto

Y listo, procedemos a instalar presionando Install, y finalmente iniciamos el servicio.

76

En seguida se aparecerá la consola, en donde podremos crear fácilmente los repositorios que necesitemos, simplemente dando clic derecho en la palabra “Repositories” y seleccionando “Create New Repository…”. Ingresamos el nombre del repositorio pucesd, no seleccionamos la opción para crear la estructura por defecto (Trunk, Branches, Tags) y presionamos aceptar.

Dentro de este repositorio se almacenará el sistema contable y el sistema académico.

Repositorios para el sistema académico y contable

Podemos acceder al repositorio vía navegador, mediante la URL que muestra la consola en el estado del servidor.

También podemos copiar la URL de un repositorio específico dando clic derecho en el repositorio y seleccionando “Copy URL to Clipboard”, esto es esencialmente útil para importar el proyecto al repositorio mediante TortoiseSVN. Debemos establecer una contraseña para nuestro usuario, el cual es el mismo del de inicio de sesión para Windows. También debemos crear a los demás usuarios que harán uso del repositorio, se los puede administrar por grupos, esto es especialmente útil si se trabaja en grandes equipos, pero para este caso bastará en crear a los usuarios necesarios y establecer las contraseñas.

También es posible establecer permisos de accesos a las carpetas del repositorio, por usuario o grupos de trabajo, damos clic derecho a la carpeta dentro del repositorio, seleccionamos Properties y establecemos los permisos de acceso por cada usuario o grupo.

77

Instalación de TortoiseSVN Primero procedemos a descargarnos el instalador de la página de TortoiseSVN: http://tortoisesvn.net/downloads Y luego procedemos a instalarlo, nos aparecerá la pantalla de bienvenida a TortoiseSVN.

Pantalla de bienvenida a TortoiseSVN

Aceptamos los términos del acuerdo de licencia, y seguimos.

Paquetes de instalación

Podemos elegir los paquetes de instalación o el directorio específico para la instalación, o simplemente le damos a siguiente.

78

Instalación de TortoiseSVN

Luego presionamos instalar, y finalizar, después tendremos que reiniciar el sistema.

Hecho esto podemos proceder a importar los espacios de trabajo de los dos proyectos en los repositorios correspondientes. Para ello nos ubicamos en los directorios de los proyectos en el explorador de Windows, damos clic derecho en la carpeta principal, nos ubicamos en la opción TortoiseSVN, y le damos clic en Import…, tal como en la figura.

Importación de los proyectos al repositorio

79

Aparecerá una ventana en donde pondremos la URL del repositorio más el nombre del proyecto y la palabra trunk, que es lugar en donde se llevara la versión de desarrollo, además se debe ingresar una breve descripción de lo que hacemos, lo cual será muy útil en el futuro.

Importando a la URL del repositorio del sistema académico

Nos pedirá que nos autentiquemos:

Autenticación

Luego se comenzarán a copiar los archivos, carpetas y subcarpetas al repositorio, al terminar presionaremos OK, Se repite la tarea para ambos sistemas, para el mismo repositorio.

80

Los archivos ya están en el repositorio pero para trabajar con ellos necesitamos crear una copia de trabajo, para lo cual procedemos a borrar las carpetas de los proyectos del directorio y crearemos el checkout ahí mismo. El checkout nos permitirá copiar los archivos del repositorio al directorio en donde estemos ubicados, y trabajar sobre él, luego cualquier cambio que hagamos en los códigos se verá reflejado en el repositorio, simplemente dando clic derecho sobre un archivo o carpeta y seleccionando update para actualizar la copia de trabajo o commit para actualizar el repositorio.

Instalación de Trac Para instalar trac en Windows vamos a necesitar de algunos programas que se tendrán que descargar de Internet, de las siguientes direcciones web (No instalar todavía): Python 2.5 http://python.org/ftp/python/2.5.2/python-2.5.2.msi Trac http://ftp.edgewall.com/pub/trac/Trac-0.11.2.1.win32.exe SVN Python http://www.tigris.org/files/documents/15/45607/svn-python-1.6.1.win32-py2.5.exe Setuptools http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c7.win32py2.5.exe#md5=395a81d709766f3a0d6084964cb98b5a Genshi http://ftp.edgewall.com/pub/genshi/Genshi-0.5.1.win32-py2.5.exe Se deben instalar en el siguiente orden establecido, en todos se debe presionar siguiente, y siguiente hasta finalizar.

1. Instalar Python 2. Instalar SVN Python 3. Instalar Setuptools 4. Instalar Genshi, y por último 5. Instalar Trac

81

Luego registramos las variables de entorno, vamos a las propiedades de MiPC, en la pestaña Opciones Avanzadas, presionamos Variables de entorno, seleccionamos Path y clic en modificar, al final de la línea ingresamos lo siguiente, y aceptamos: c:\Python25;C:\Python25\Scripts Esto evitará que ingresemos la dirección absoluta a los scripts de trac, luego de esto reiniciamos el sistema operativo.

Corriendo Trac Creamos una carpeta “proyectos”, en la unidad C: Y luego la carpeta trac, quedando de esta forma: c:\proyectos\trac Damos clic en Inicio, Ejecutar, y escribimos cmd, damos enter y en el command prompt, nos dirigimos al directorio anterior, ahí simplemente escribimos: trac-admin pucesd initenv Esto instalará trac en el directorio C:\proyectos\trac\pucesd, nos pedirá cierta información para el proyecto. Primero el nombre del Proyecto, hemos puesto “Sistemas Académico y Contable”. Luego nos pedirá un string de conexión para conectarnos a una base de datos como mysql u oracle, sin embargo lo dejaremos por default con sqlite, y damos enter.

Nos preguntará qué tipo de sistema de control de versiones utilizamos, escribimos svn y damos enter. Finalmente nos pedirá que introduzcamos la dirección absoluta al directorio del repositorio. Ingresamos C:/Repositories/pucesd, y damos enter. Y enseguida comienza a instalarse. Se debe ingresar esta última dirección con el slash de división.

Ejemplo: Project Name [My Project]> Sistemas Académico y Contable + [Enter] Database connecting string [sqlite:db/trac.db]> [Enter] Repository type [svn]>svn [Enter] Path to repository [/path/to/repos]> C:/Repositories/pucesd + [Enter]

Configuración de Trac Primero crearemos un archivo en python en el siguiente directorio: c:\Python25\Scripts\trac-digest.py. Esto servirá para crear usuarios de trac, con sus respectivas contraseñas, para lo cual en el block de notas escribiremos las siguientes líneas:

82

--from optparse import OptionParser import md5 # build the options usage = "usage: %prog [options]" parser = OptionParser(usage=usage) parser.add_option("-u", "--username",action="store", dest="username", type = "string", help="the username for whom to generate a password") parser.add_option("-p", "--password",action="store", dest="password", type = "string", help="the password to use") (options, args) = parser.parse_args() # check options if (options.username is None) or (options.password is None): parser.error("You must supply both the username and password") # Generate the string to enter into the htdigest file realm = 'trac' kd = lambda x: md5.md5(':'.join(x)).hexdigest() print ':'.join((options.username, realm, kd([options.username, realm, options.password]))) --Nota: Este script y todos los programas antes mencionados se encuentran en el CD de anexos, en la carpeta Programas Guardamos y cerramos el archivo.

Ahora crearemos a los usuarios con sus contraseñas, en el mismo command prompt, escribimos: trac-digest.py -u "admin" -p adminpassword >> C:\proyectos\users.txt Repetimos este proceso para registrar a todos los usuarios del sistema.

Establecemos al usuario admin como administrador de trac: trac-admin c:\proyectos\trac\pucesd permission add "admin" TRAC_ADMIN Esto no retornará ninguna línea, luego removeremos el acceso de administrador, una vez que creemos una cuenta, y con eso podemos empezar Trac.

En el command prompt escribimos lo siguiente y damos enter:

83

tracd-script.py -p 80 --auth="*",C:\proyectos\users.txt,trac c:\proyectos\trac\pucesd

Nota: Si no está disponible el puerto 80, lo puede cambiar por cualquier otro, por ejemplo el puerto: 8080. Dejamos la ventana del prompt abierta, si la cerramos se cierra Trac. Si le aparece la ventana del firewall de Windows, presionamos el botón Desbloquear.

Abrimos el navegador Web e ingresamos en la siguiente URL: http://localhost/ (o http://localhost:8080, si está usando ese puerto) Ahí encontraremos un enlace con el nombre del proyecto que se le ha dado en la configuración, en este caso “Sistema Académico y Contable”.

Presionamos ese enlace y entraremos a la interfaz de trac:

Pantalla de bienvenida a Trac

Aquí nos muestra la Wiki, donde una vez que hayamos iniciado sesión podremos modificar la página, añadir enlaces y detalles de actualizaciones para la comunicación sobre los cambios entre los integrantes del equipo.

En la carpeta conf, en el directorio del C:\proyectos\trac\pucesd, encontraremos un archivo llamado trac.ini: C:\proyectos\trac\pucesd\conf\trac.ini

84

Lo abrimos y nos ubicamos en la sección [header_logo], e ingresamos en la parte donde dice src, la dirección del logotipo de la PUCESD, para que la interfaz sea más familiar para los desarrolladores.

Luego nos ubicamos en la sección [trac], e ingresamos lo siguiente: authz_file = C:\Repositories\authz (archivo de accesos de usuarios al repositorio) authz_module_name = pucesd (nombre del repositorio a acceder)

Estas 2 líneas aseguran los permisos de acceso a los archivos de acuerdo a los usuarios o grupos de trabajo. Guardamos y reiniciamos el servicio.

En la pestaña Browse Source, encontraremos el repositorio con los respectivos proyectos, como se muestra en la figura:

Vista del repositorio en Trac

Aquí vemos el sistema de archivos, Size (tamaño de los archivos), Rev (número de revisión), Age (Edad de los archivos), Last Change (autor: y acción del último cambio).

Al presionar el botón View changes, veremos los cambios en relación con versiones anteriores, relacionándolos por su número de revisión.

85

También podemos ir a una revisión anterior ingresando su numeración en View revisión.

Todos los módulos de Trac cuentan con información para su manejo, en la parte inferior encontramos un enlace a las páginas de ayuda.

La bitácora de cambios se encuentra en la pestaña Timeline, en donde se mostrará la fecha y hora, además de quién modificó que cosa:

Bitácora de cambios en los códigos

Instalación del plugin Gantt Calendar para Trac Primero paramos trac, en el command prompt, presionando Ctrl+C, y actualizamos la página de trac, luego nos ubicamos en la unidad c: y escribimos lo siguiente: svn co http://recurser.com/svn/ganttcalendar/trunk/ ganttcalendar Esto hará una copia del repositorio especificado, con la carpeta ganttcalendar Antes de instalar, necesitamos ejecutar el archivo que debemos descargar de la siguiente dirección: http://peak.telecommunity.com/dist/ez_setup.py

86

Este archivo lo guardamos en el directorio de los scripts de python C:\Python25\Scripts\ Luego en el command prompt, escribimos ez_setup.py, esto instalará varias dependencias que necesita Gantt Calendar para instalarse. Ahora sí ingresamos a la carpeta C:\ganttcalendar y presionamos: python setup.py install Hecho esto ingresamos a la carpeta dist, C:\ganttcalendar\dist, e ingresamos lo siguiente: easy_install TracGanttCalendarPlugin-0.1-py2.6.egg Ahora en el explorador de Windows abrimos el archivo trac.ini ubicado en la carpeta C:\proyectos\trac\pucesd\conf, e ingresamos el siguiente texto, justo antes de la sección: [header_logo] [components] ganttcalendar.ticketcalendar.ticketcalendarplugin = enabled ganttcalendar.ticketgantt.ticketganttchartplugin = enabled Y debajo de la sección [ticket] lo siguiente: [ticket-custom] complete = select complete.label = % Complete complete.options = 0|5|10|15|20|25|30|35|40|45|50|55|60|65|70|75|80|85|90|95|100 complete.order = 3 due_assign = text due_assign.label = Start (YYYY/MM/DD) due_assign.order = 1 due_close = text due_close.label = End (YYYY/MM/DD) due_close.order = 2 Guardamos y cerramos.

Finalmente ejecutamos de nuevo el servidor para trac: tracd-script.py -p 80 --auth="*",C:\proyectos\users.txt,trac c:\proyectos\trac\pucesd Si usan otro puerto, cambian 80 por el que quieran usar. Regresamos al navegador Web y actualizamos la página en donde estábamos, veremos que se han añadido dos pestañas más, Calendar y Gantt Ticket, como vemos en la figura:

87

Gantt Calendar

En Calendar se irán mostrando los tickets asignados a todos los miembros del equipo, o sólo los nuestros. Podemos entre hitos de trabajos y fechas de asignación.

Llevar tickets es importante para la gestión de las incidencias, si se van a hacer mejoras al código, o arreglos.

En la siguiente figura, se muestra el diagrama de Gantt respecto de la fecha de asignación y de terminación de cada ticket.

Diagrama de Gantt

88

Con el paso del tiempo, y de acuerdo a los procesos de desarrollo, se obtendría un cuadro como el siguiente:

Diagrama de Gantt con varios Tickets

Los tickets son el método por el cual se reportan las incidencias en el software, cada ticket debe tener un inicio y un fin, un responsable y una prioridad, se asigna de acuerdo a los hitos o de acuerdo a los componentes. Un ticket puede ser asignado por defecto en el software, por una actualización o por una tarea. También posee un porcentaje de completado que se puede ir modificando para informar a los demás de que tanto estamos trabajando por arreglar la incidencia, incluso se pueden adjuntar archivos a los tickets que nos ayuden a reconstruir la escena del porqué ocurrió dicha incidencia.

89

ANEXO 2: GUÍA DE INSTALACIÓN EN UBUNTU - LINUX

90

GUÍA DE INSTALACIÓN EN UBUNTU - LINUX Instalación del servidor Web Como se requiere tener instalado en el servidor apache para correr trac y subversion, primero se procederá a instalar apache. Ingresamos a la terminal de Ubuntu, y escribirá lo siguiente: $sudo apt-get install apache2 $sudo apt-get install php5 libapache2-mod-php5 php5-gd php5-cli $sudo /etc/init.d/apache2 restart Explicación: 

apache2: Con esto instalamos apache en nuestro Linux. para ver si esta activo vamos al navegador y digitamos http://localhost.



php5: Con esto instalamos el modulo Php5 para Apache.



libapache2-mod-php5: Instala el modulo de apache para traducir el php.



php5-gd: Modulo de php para la manipulación de las imágenes.



php5-cli(Command Line Interpreter): Para ejecutar php por linea de comando.



/etc/init.d/apache2 restart: Reiniciamos el servidor web, esto es necesario para poder ver los cambios realizados.

Instalamos el servidor de base de datos: $sudo apt-get install mysql-server $sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin $sudo /etc/init.d/apache2 restart Explicación: 

mysql-server: Instalamos MySQL, el servidor de base de datos.



libapache2-mod-auth-mysql: Modulo de apache para el manejo de autentificaciones con mysql.



php5-mysql: Modulo de php para manejo de conexiones con MySQL.



phpmyadmin: Administrador de MySQL atravez del navegador (http://localhost/phpmyadmin)

91

Nota: Nos pedirá un nombre de usuario y contraseña, esos datos son los que definimos al momento de instalar MySQL. Nota 2: Si nos muestra “The requested URL /phpmyadmin/ was not found on this server” se debe ejecutar: $sudo ln -s /usr/share/phpmyadmin/ /var/www/phpmyadmin Esto

creara

un

acceso

directo

el

cual

permitira

ya

ingresar

a

http://localhost/phpmyadmin Activamos el Mod Rewrite $sudo a2enmod rewrite $sudo /etc/init.d/apache2 restart En /var/www se publicaran las páginas para el servidor web donde se podrá probar el funcionamiento de php.

Instalación de Subversion Ahora procederemos a instalar el sistema de control de versiones, en la terminal escribimos lo siguiente: $sudo apt-get install subversion $sudo a2enmod dav $sudo /etc/init.d/apache2 restart $sudo apt-get install libapache2-svn $sudo /etc/init.d/apache2 restart Explicación: subversion: Con esto instalamos subversion. a2enmod dav: Activamos el modulo de Apache usado para hacer que los repositorios estén disponible a otros a través de una red. /etc/init.d/apache2 restart: Reiniciamos el servidor web, esto es necesario para poder ver los cambios realizados. libapache2-svn: Contiene los módulos que capacitan a Apache funcionar como un servidor de Subversion además del módulo de identificación.

92

Creación del repositorio Terminada la instalación de subversion procedemos a crear el primer repositorio, en la terminal escribimos lo siguiente: $sudo mkdir /var/svn $sudo svnadmin create /var/svn/repos Configurando subversion para que funcione con el servidor Web A continuación, abrir el archivo /etc/apache2/httpd.conf y añada las siguientes líneas: --<Location /repos> DAV svn SVNPath /var/svn/repos AuthType Basic AuthName "Repositorio Subversion" AuthUserFile /etc/subversion/passwd Require valid-user </Location> --Asignamos permisos para que el servidor web pueda modificar el repositorio: $sudo chown -R www-data /var/svn Añadimos un usuario le asignamos la contraseña y reiniciamos el servidor web. $sudo htpasswd -c /etc/subversion/passwd admin $sudo /etc/init.d/apache2 restart Añadimos el proyecto al repositorio: $svn

import

-m

"PUCESD"

/home/pucesd/academico

file:///var/svn/repos/academico/trunk Ahora nos dirigimos con el navegador web a http://localhost/repos y nos pedirá el usuario y la contraseña que hayamos asignado.

93

Instalación de RabbitVCS RabbitVCS es un conjunto de herramientas gráficas escrito para proporcionar un acceso simple y directo a los sistemas de control de versiones. Actualmente Rabbit se integra sólo con Nautilus y soporta Subversion, pero el proyecto apunta a un objetivo mucho más grande: incorporar otros sistemas de control de versiones, como así también, otros sistemas administradores de archivos. RabbitVCS es para ubuntu lo que TortoiseSVN es para Windows. Se integra de maravilla con Gnome y su gestor de archivos Nautilus.

Para instalar RabbitVCS es tan sencillo como introducir los siguientes comandos en la terminal: sudo add-apt-repository ppa:rabbitvcs/ppa sudo apt-get update sudo apt-get install rabbitvcs-core sudo apt-get install rabbitvcs-nautilus rabbitvcs-thunar rabbitvcs-gedit rabbitvcs-cli

Instalación de Trac La instalación de Trac en Ubuntu 9.04 es muy sencilla, este ya se encuentra en los repositorios de archivos y programas de Ubuntu solamente es de dar ingresar en una Terminal los siguientes parámetros:

94

$sudo apt-get update Esto es para actualizar los repositorios de archivos de Ubuntu en nuestra maquina, y luego: $sudo apt-get install trac Con esto se instalaran todas las dependencias que tenga trac. Y por último instalamos los módulos de phyton, para que funcione Trac: $sudo apt-get install libapache2-mod-python Configurando el entorno de Trac Ya teniendo instalado Trac, podemos configurar el entorno en el cual nos basaremos para trabajar, para ello crearemos una carpeta, la dirección de esta carpeta puede ser cualquiera, solo es de tener el cuidado de que no se fácil de eliminarla o moverla de donde la creemos, ingresamos los siguientes comandos: $ sudo su # mkdir -p /var/trac/projects/pucesd # trac-admin /var/trac/projects/pucesd initenv Luego nos aparaceran varias preguntas las cuales hay que responder de la siguiente manera: 

Nombre del proyecto: PUCESD (presionamos Enter)



Database

Connection

String(por

default

sqlite):

la

dejamos

en

blanco

(presionamos Enter). 

El tipo de control de Versiones (por default svn): svn (presionamos Enter).



Dirección del repositorio: /var/svn/repos (presionamos Enter).

Y le damos permisos al usuario de Subversion para que pueda leer y escribir en esta carpeta. $ sudo chown -R www-data:www-data /var/trac/projects/pucesd Ahora para acceder desde el navegador web, utilizando apache, al manejador de trac ingresamos a un terminal y editamos el archivo default de apache. $sudo gedit /etc/apache2/sites-available/default

95

Luego ingresamos las siguientes líneas al final del archivo, antes de la última etiqueta de cierre (</VirtualHost>). <Location /projects> SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot /projects PythonOption PYTHON_EGG_CACHE /tmp </Location> <LocationMatch "/projects/[[:alnum:]]+/login"> AuthType Basic AuthName "TRAC Access" AuthUserFile /etc/subversion/passwd Require valid-user </LocationMatch> Nota: Como se puede ver en la línea: “AuthUserFile /etc/subversion/passwd” debemos apuntar al mismo fichero que se apunta para la autenticación en Subversion.

Finalmente reiniciamos el servidor web: $sudo /etc/init.d/apache2 restart Para acceder a trac, desde el navegador Web ingresamos a la siguiente dirección: http://localhost/projects

Instalación del plugin Gantt Calendar para Trac Gantt Calendar es un plugin para Trac que permite visualizar tickets según milestone o component en forma de calendario.

La instalación es sencilla, desde cualquier directorio del servidor hacemos lo siguiente: $ svn co http://recurser.com/svn/ganttcalendar/trunk/ ganttcalendar $ cd ganttcalendar

96

$ python setup.py bdist_egg $ sudo easy_install dist/TracGanttCalendarPlugin-0.1-py2.4.egg Y el egg se agregará automáticamente a todos los Trac que tengas en el servidor.

Hecho esto solo queda habilitar el componente y agregar los nuevos campos de fecha a la hora de crear un ticket, ingresamos al archivo de configuración de trac: $sudo gedit /var/trac/projects/pucesd/conf/trac.ini Y añadimos las siguientes líneas en las secciones correspondientes: [components] ganttcalendar.ticketcalendar.ticketcalendarplugin = enabled ganttcalendar.ticketgantt.ticketganttchartplugin = enabled ... [ticket-custom] complete = select complete.label = % Complete complete.options = 0|5|10|15|20|25|30|35|40|45|50|55|60|65|70|75|80|85|90|95|100 complete.order = 3 due_assign = text due_assign.label = Start (YYYY/MM/DD) due_assign.order = 1 due_close = text due_close.label = End (YYYY/MM/DD) due_close.order = 2 Reiniciamos apache y listo, si no ha habido ningún problema ya podríamos usar las pestañas Calendar y Gantt Ticket

97

ANEXO 3: MANUAL DE USUARIO DE TORTOISE SVN

98

MANUAL DE USUARIO DE TORTOISE SVN

Tabla de contenidos Empezando Iconos sobreimpresionados Menús contextuales Arrastrar y soltar Atajos comunes Autentificación Maximizando ventanas Importando datos en un repositorio Importar Importar en el sitio Ficheros especiales Obteniendo una copia de trabajo Profundidad de obtención Confirmando sus cambios en el repositorio El diálogo de Confirmación Listas de cambios Excluyendo ítems de la lista de confirmación Mensajes de registro de confirmación Progreso de confirmación Actualice su copia de trabajo con los cambios de otros Resolviendo conflictos Conflictos de ficheros Conflictos de árbol Obteniendo información del estado Iconos sobreimpresionados

99

Columnas de TortoiseSVN en el Explorador de Windows Estado local y remoto Viendo diferencias Listas de cambios Diálogo de Registro de revisiones Invocando el diálogo de Registro de revisiones Acciones del registro de revisiones Obteniendo información adicional Obteniendo más mensajes de registro Revisión actual de la copia de trabajo Características de registro de fusión Cambiando el mensaje de registro y el autor Filtrando los mensajes de registro Información estadística Modo sin conexión Refrescando la vista Viendo diferencias Diferencias de ficheros Opciones de fin de línea y espacios en blanco Comparando carpetas Diferenciando imágenes utilizando TortoiseIDiff Herramientas externas de diferencias/fusión Añadiendo nuevos ficheros y directorios Copiando/Moviendo/Renombrando ficheros y carpetas Ignorando ficheros y directorios Concordancia de patrones en las listas de ignorados Eliminando, moviendo y renombrando Eliminando ficheros y carpetas Moviendo ficheros y carpetas Cambiando las mayúsculas/minúsculas en un nombre de fichero

100

Lidiando con conflictos en las mayúsculas/minúsculas de un nombre de fichero Reparando renombrados de ficheros Eliminando ficheros no versionados Deshacer cambios Limpieza Configuración del proyecto Propiedades de Subversion Propiedades de projecto TortoiseSVN Ítems externos Carpetas externas Ficheros externos Haciendo ramas / etiquetas Crando una rama o etiqueta Obtener o cambiar...

Fusionando Fusionando un rango de revisiones Reintegrando una rama.

Fusionando dos árboles diferentes Opciones de fusión Revisando los resultados de la fusión Registro de fusión Manejando conflictos durante la fusión Fusionar una rama completada Mantenimiento de ramas de características Bloqueando Cómo trabaja el bloqueo en Subversion Obteniendo un bloqueo Quitando un Bloqueo

101

Comprobando el estado de los bloqueos Haciendo ficheros no-bloqueados como sólo-lectura Los scripts ganchos de bloqueo Creando y aplicando parches Creando un fichero parche Aplicando un fichero parche ¿Quién cambió qué línea?

Autoría de ficheros Autoría de las diferencias El navegador de repositorios Gráficos de revisión Nodos del gráfico de revisión Cambiando la vista Usando el gráfico Refrescando la vista Podando árboles Exportando una copia de trabajo de Subversion Eliminando una copia de trabajo del control de versiones Este documento describe el uso diario del cliente TortoiseSVN. Para aprovechar al máximo el manual de usuario: 

Debe tener ya instalado TortoiseSVN.



Debe estar familiarizado con los sistemas de control de versiones.



Debe conocer las bases de Subversion.



Debe haber preparado un servidor y/o tener acceso a un repositorio de Subversion.

Empezando Iconos sobre impresionados

102

Figura 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.

Menús contextuales

Figura 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.

Sugerencia

103

Algunos comandos que se utilizan muy raramente sólo están disponibles en el menú contextual extendido. Para mostrar el menú contextual extendido, mantenga pulsada la tecla Mayús mientras hace click con el boton derecho.

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

Figura 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.

104

Arrastrar y soltar

Figura 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.

Atajos comunes 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í.

F1 La ayuda, por supuesto.

F5 Refresca la vista actual. Este es quizás el comando de una tecla más útil. Por ejemplo... en el Explorador esto refresca los iconos sobreimpresionados en su copia de trabajo. En el diálogo de confirmación volverá a reescanear la copia de trabajo para ver qué puede necesitar ser confirmado. En el diálogo de Mostrar Registro contactará con el repositorio de nuevo buscando los cambios más recientes.

Ctrl-A Selecciona todo. Esto puede ser útil si obtiene un mensaje de error y quiere copiar y pegarlo en un email. Utilice Ctrl-A para seleccionar el mensaje de error y luego...

Ctrl-C

105

... copia el texto seleccionado.

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

Figura 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: svn_simple

contiene

las

credenciales

para

la

autentificación

básica

(usuario/contraseña). svn_ssl_server contiene los certificados SSL de servidor. svn_username contiene las credenciales para autentificación sólo por usuario (sin necesidad de contraseña).

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. 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

106

rmdir /s /q "%APPDATA%\Subversion\auth"

Maximizando ventanas 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.

Importando datos en un repositorio Importar 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.

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: No hay forma de seleccionar los ficheros y carpetas a incluir, salvo si utiliza la configuración del patrón global de ignorar.

La carpeta importada no se convierte en una copia de trabajo. Tiene que hacer una obtención para copiar los ficheros de nuevo desde el servidor.

Es fácil importar en un nivel de carpetas erróneo en el repositorio. Antes de importar su proyecto en un repositorio debería: 1.

Quitar todos los ficheros que no se necesitan para construir el proyecto

(ficheros temporales, ficheros que se generan por un compilador como los *.obj, binarios compilados) 2.

Organizar los ficheros en carpetas y subcarpetas. Aunque es posible

renombrar/mover los ficheros más tarde, ¡es muy recomendable que tenga la estructura del proyecto antes de importarlo!

107

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 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.

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

108

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.

Importar 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: 1.

Utilice el navegador de repositorios para crear nuevas carpetas de

proyecto directamente en el repositorio.

2. Ejecute la operación obtener de la nueva carpeta sobre la carpeta de más alto nivel que desea importar. Obtendrá una advertencia porque la carpeta local no está vacía. Ahora tiene una carpeta de más alto nivel versionada con contenido no versionado.

3. Utilice TortoiseSVN → Añadir... en esta carpeta versionada para añadir parte o todo su contenido. Puede añadir y eliminar ficheros, establecer las propiedades svn:ignore en las carpetas y hacer cualquier otro cambio que necesite.

4.

Confirme la carpeta de más alto nivel, y ya tiene un nuevo árbol

versionado, y una copia de trabajo local, creada desde su carpeta existente.

Ficheros especiales 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á

109

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á cómo no versionado en cada confirmación.

Obteniendo una copia de trabajo

Para tener una copia de trabajo necesita obtener una de un repositorio.

Seleccione un directorio en el explorador de Windows donde quiera poner su copia de trabajo. Haga click con el botón derecho para mostrar el menú contextual y seleccione el comando TortoiseSVN → Obtener..., que mostrará el siguiente cuadro de diálogo:

Figura 7: El diálogo Obtener

110

Si introduce un nombre de carpeta que no aún no exista, se creará un directorio con ese nombre.

Profundidad de obtenció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.

Totalmente recursivo Obtener el árbol entero, incluyendo todas las carpetas hijas y subcarpetas.

Hijos inmediatos, incluyendo carpetas Obtener el directorio especificado, incluyendo todos los fichero sy carpetas hijas, pero no rellenar las carpetas hijas.

Sólo los ficheros hijos Obtener la carpeta especificada, incluyendo todos los ficheros pero no obtener ninguna carpeta hija.

Sólo este ítem Obtener sólo el directorio. No rellenarlo con ficheros ni carpetas hijas.

Copia de trabajo Retiene la profundidad especificada en la copia de trabajo. Esta opción no se utiliza en el diálogo obtener, pero es el valor por defecto para todos los demás diálogos que tengan opción de profundidad.

Excluír Utilizado para reducir la profundidad de una copia de trabajo después de que una carpeta haya sido rellenada. Esta opción sólo está disponible en el diálogo Acctualizar a la revisión.

111

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 o el diálogo Comprobar modificaciones.

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: 1. Obtenga la carpeta padre con profundidad “Sólo este ítem”. Ahora tiene una carpeta de nivel superior vacía.

2.

Seleccione la nueva carpeta y utilice TortoiseSVN → Navegador de

repositorios para ver el contenido del repositorio.

3.

Haga click con el botón derecho sobre Proyecto03 y Menú contextual →

Actualizar ítem a la revisión.... Mantenga las configuraciones por defecto y haga click en Aceptar. Ahora tendrá una carpeta totalmente poblada.

Repita el mismo proceso para Proyecto25.

4.

Navegue a Proyecto76/SubProy y haga lo mismo. Esta vez notará que la

carpeta Proyecto76 no tiene otro contenido que SubProy, que a su vez está totalmente poblado. Subversion ha creado las carpetas intermedias pero sin rellenarlas.

Cambiando la profundidad de la copia de trabajo

112

Una vez que haya obtenido una copia de trabajo a una profundidad en concreto, puede cambiar dicha profundidad más tarde para obtener más o menos contenido utilizando Menú contextual → Actualizar ítem a la revisión....

Utilizando un servidor antiguo Los servidores anteriores a la versión 1.5 no entienden la petición de profundidad de copia de trabajo, por lo que no siempre pueden manejar las peticiones de forma eficiente.

El comando funcionará, pero un servidor antiguo puede que envíe todos los datos, dejando que sea el cliente quien filtre lo que no necesite, lo que puede significar un montón de tráfico de red. Si es posible, debería actualizar su servidor a la versión 1.5.

Si el proyecto contiene referencias a proyectos externos que no desea que se obtengan al mismo tiempo, utilice la casilla Omitir externos.

Importante Si está marcado Omitir externos, o si desea incrementar el valor de la profundidad, deberá realizar actualizaciones a su copia de trabajo utilizando TortoiseSVN → Actualizar a la Revisión... en vez de TortoiseSVN → Actualizar. La actualización estándar incluirá todos los externos y mantendrá la profundidad actual.

Le recomendamos que obtenga únicamente la parte trunk del árbol de directorios, o desde más abajo. Si especifica la ruta padre del árbol de directorios en la URL, al final puede acabar con un disco duro lleno ¡porque obtendrá una copia del árbol completo del repositorio, incluyendo cada rama y etiqueta de su proyecto!

Confirmando sus cambios en el repositorio Enviar los cambios que ha hecho al repositorio se conoce como confirmar los cambios.

Pero antes de confirmar tiene que estar seguro de que su copia de trabajo está actualizada. Puede o bien ejecutar TortoiseSVN → Actualizar directamente, o bien ejecutar TortoiseSVN → Comprobar Modificaciones primero, para ver qué se ha cambiado localmente o en el servidor.

El diálogo de Confirmación

113

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 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, simplemente 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! ¿Confirmar ficheros o carpetas?

Cuando confirma ficheros, el diálogo de confirmación sólo le enseña los ficheros que ha seleccionado. Cuando confirma una carpeta el diálogo de confirmación seleccionará los ficheros que han cambiado de forma automática. Si se olvidó un fichero nuevo que haya creado, al confirmar la carpeta lo encontrará. Confirmar una carpeta no significa que todos los ficheros se marquen como cambiados; sólo le hace la vida más fácil haciendo más trabajo por usted.

114

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.

Muchos ficheros sin versionar en el diálogo de confirmar Si cree que el diálogo de confirmación de TSVN le muestra demasiados ficheros no versionados (por ejemplo, ficheros generados por el compilador o copias de seguridad hechas por su editor), hay varias formas de manejar esta situación. Puede: Añadir el fichero (o una extensión con máscara) a la lista de ficheros a ignorar en la página de configuración. Esto afectará a todas las copias de trabajo que tenga.

Añadir el fichero a la lista de svn:ignore utilizando TortoiseSVN → Añadir a la lista de ignorados. Esto únicamente afectará al directorio en el que establezca la propiedad svn:ignore. Puede cambiar la propiedad svn:ignore de un directorio utilizando el Diálogo de Propiedades SVN. 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

115

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.

Arrastrar y soltar Puede arrastrar ficheros hasta el diálogo de confirmación desde cualquier otro lugar, siempre y cuando las copias de trabajo sean del mismo repositorio. Por ejemplo, puede tener una copia de trabajo enorme con diferentes ventanas del explorador abiertas en carpetas distantes de la jerarquía. Si quiere evitar confirmar desde la carpeta más alta (lo que implica una lenta operación de búsqueda de cambios) puede abrir el diálogo de confirmar para una carpeta y arrastrar desde las otras ventanas para incluir ficheros dentro de la misma confirmación atómica.

Puede arrastrar ficheros no versionados que residan dentro de una copia de trabajo al diálogo de confirmación, y automáticamente serán SVN añadidos.

Reparando renombrados externos A veces los ficheros se renombran fuera de Subversion, y se muestran en la lista de ficheros como un fichero faltante y un fichero no versionado. Para evitar perder la historia necesita notificar a Subversion su conexión. Simplemente seleccione tanto el nombre antiguo (faltante) como el nombre nuevo (sin versionar) y utilice Menú contextual → Reparar movimiento para emparejar los dos ficheros como un renombrado.

Listas de cambios El diálogo de confirmación da soporte a las listas de cambios de Subversion para ayudar a agrupar ficheros relacionados.

Excluyendo ítems de la lista de confirmación 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

116

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.

Mensajes de registro 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 9: El corrector ortográfico del diálogo de confirmación

117

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.

Puede reutilizar mensajes de registro que haya sólo debe pulsar en mensajes que ha

Mensajes recientes para

introducido para

esta

introducido anteriormente. Tan ver

una

copia de

lista de

los últimos

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.

Propiedades especiales de carpetas Hay diversas propiedades especiales de carpeta que pueden usarse para darle mayor control sobre el formato de los mensajes de registro de las confirmaciones y el idioma que utiliza el módulo del corrector ortográfico.

118

Integración con herramientas de control de errores Si ha activado el sistema de control de errores, puede poner una o más incidencias en el cuatro de texto Bug-ID / Nº-Incid.:. Si quiere introducir múltiples incidencias, sepárelas por comas. Alternativamente, si está utilizando el soporte de control de errores basado en expresiones regulares, simplemente añada las referencias a sus incidencias como parte del mensaje de registro.

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

Figura 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: Azul Confirmando una modificación. Púrpura Confirmando un ítem añadido. Rojo oscuro Confirmando un borrado o un reemplazo.

Negro Todos los demás ítems.

Este es el esquema de colores por defecto, pero puede personalizar dichos colores utilizando el diálogo de configuración.

119

Actualice su copia de trabajo con los cambios de otros

Figura 11: Diálogo de progreso mostrando una actualización terminada Periódicamente, debería asegurarse de que los cambios que hacen los demás se incorporen en su copia de trabajo local. El proceso de incorporar los cambios desde el servidor a su copia de trabajo local se conoce como actualización. La actualización puede hacerse en ficheros sueltos, en un conjunto de ficheros, o recursivamente en jerarquías completas de directorios. Para actualizar, seleccione los ficheros y/o directorios que desee, haga click con el botón derecho y seleccione TortoiseSVN → Actualizar en el menú contextual del explorador. Aparecerá una ventana con el progreso de la actualización según se ejecuta. Los cambios que los demás hayan hecho se fusionarán con sus ficheros, manteniendo cualquier cambio que haya hecho en los mismos ficheros.

El repositorio no se ve afectado por una actualización.

El diálogo de progreso utiliza un código de colores para resaltar diferentes acciones de actualización: Púrpura Nuevo ítem añadido a su copia de trabajo Rojo oscuro Ítem redundante borrado de su copia de trabajo, o ítem faltante reemplazado en su copia de trabajo.

Verde Cambios del repositorio que se han fusionado satisfactoriamente con sus cambios locales.

Rojo brillante Cambios del repositorio fusionados con sus cambios locales, pero que han dado lugar a conflictos que debe resolver.

120

Negro Items sin cambios en su copia de trabajo actualizados con una versión más nueva desde el repositorio.

Este es el esquema de colores por defecto, pero puede personalizar dichos colores utilizando el diálogo de configuración. La profundidad por defecto es Copia de trabajo, lo que respeta la configuración de profundidad ya existente. También puede decidir si desea ignorar cualquier proyecto externo en la actualización (esto es, los proyectos referenciados utilizando svn:externals).

Atención: Si actualiza un fichero o una carpeta a una revisión en concreto, no debería hacer cambios en esos ficheros. ¡Obtendrá mensajes out

of date (desactualizado)

cuando intente confirmarlos! Si desea deshacer los cambios de un fichero y empezar de nuevo desde una revisión anterior, puede revertir a una revisión previa desde el diálogo de registro de revisiones.

Actualizar a la revisión puede ser útil a veces para ver cómo estaba su proyecto en un momento anterior en su historia. Pero en general, actualizar ficheros individuales a una revisión anterior no es una buena idea, ya que deja su copia de trabajo en un estado inconsistente. Si el fichero que está actualizando ha cambiado de nombre, incluso puede encontrar que ese fichero ha desaparecido de su copia de trabajo porque en esa revisión no había ningún fichero con ese nombre. También debe tener en cuenta que el ítem mostrará una sobreimpresión normal verde, por lo que no se puede distinguir del resto de ficheros que están actualizados.

Si desea simplemente una copia local de una versión antigua de un fichero, es mejor utilizar el comando Menú contextual → Guardar revisión en... desde el diálogo de registro para dicho fichero.

Múltiples ficheros/carpetas Si selecciona múltiples ficheros y carpetas en el explorador y luego selecciona Actualizar, todos esos ficheros/carpetas se actualizan uno a uno. ¡TortoiseSVN se asegura de que todos los ficheros/carpetas del mismo repositorio se actualicen exactamente a la misma revisión! Incluso si entre esas actualizaciones ocurrió alguna confirmación.

El fichero local ya existe

121

A veces cuando intente actualizar, la actualización falla con un mensaje para decir que ya existe un fichero local con el mismo nombre. Esto típicamente ocurre cuando Subversion intenta obtener un fichero recién versionado, y se encuentra un fichero no versionado del mismo nombre en su copia de trabajo. Subversion nunca sobreescribirá un fichero no versionado - puede contener algo en lo que está trabajando, y que casualmente tiene el mismo nombre de fichero que otro desarrollador ha utilizado para su recién confirmado fichero.

Si obtiene este mensaje de error, la solución es simplemente renombrar el fichero local sin versionar. Tras completar la actualización, puede comprobar si el fichero renombrado sigue siendo necesario.

Si sigue obteniendo mensajes de error, utilize mejor el comando TortoiseSVN → Comprobar modificacioness para mostrar todos los ficheros con problemas. De esa forma puede lidiar con ellos de un golpe.

Resolviendo conflictos De vez en cuando, obtendrá un conflicto cuando actualice/fusione sus ficheros desde el repositorio o cuando cambie su copia de trabajo a una URL diferente. Hay dos tipos de conflictos: conflictos de fichero Un conflicto de fichero ocurre si dos (o más) desarrolladores han cambiado las mismas líneas de un fichero. conflictos de árboles 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.

Conflictos de ficheros 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

122

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: nombre-del-fichero.ext.mine Este es su fichero tal y como estaba en su copia de trabajo antes de que actualizara su copia de trabajo - esto es, sin marcadores de conflicto. Este fichero tiene sus últimos cambios en él y nada más. nombre-del-fichero.ext.rREV-ANTIGUA Este es el fichero que era la revisión BASE antes de que actualizara su copia de trabajo. Esto es, el fichero que obtuvo antes de empezar a hacer sus últimos cambios. nombre-del-fichero.ext.rREV-NUEVA Este es el fichero que su cliente de Subversion acaba de recibir desde el servidor del que actualizó su copia de trabajo. Este fichero corresponde a la revisión HEAD del repositorio.

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.

123

Si tiene conflictos con ficheros binarios, Subversion no intentará mezclar dichos ficheros por sí 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.

Conflictos de árbol 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.

Borrado local, llega un cambio en la actualización 1. El desarrollador A modifica Foo.c y lo confirma en el repositorio 2. El desarrollador B al mismo tiempo ha movido Foo.c a Bar.c en su propia copia de trabajo, o simplemente ha borrado Foo.c o su carpeta padre.

124

Una actualización de la copia de trabajo del desarrollador B acaba con un conflicto de árbol: Foo.c ha sido borrado de la copia de trabajo, pero está marcado como un conflicto de árbol.

Si el conflicto aparece después de un renombrado en vez de un borrado, entonces Bar.c está marcado como añadido, pero no contiene las modificaciones del desarrollador A. El desarrollador B ahora tiene que elegir si mantiene los cambios realizados por el desarrollador A. En el caso de un renombrado, puede fusionar los cambios de Foo.c dentro del fichero renombrado Bar.c. Para simples borrados de ficheros o directorios puede elegir quedarse con los cambios del ítem del desarrollador A y descartar el borrado. O, si marca el conflicto como resuelto sin hacer nada más, estará descartando los cambios del desarrollador A. El diálogo de editar conflictos ofrece la posibilidad de fusionar cambios si puede encontrar el fichero original del renombrado Bar.c. Dependiendo de dónde se haya realizado la actualización, puede que no sea posible encontrar el fichero de origen.

Edición local, entra un borrado en la actualización 1. El desarrollador A mueve Foo.c a Bar.c y lo confirma en el repositorio.

2. El desarrollador B modifica Foo.c en su copia de trabajo.

O en el caso de mover una carpeta...

1. El desarrollador A mueve la carpeta padre FooFolder a BarFolder y lo confirma en el repositorio.

2. El desarrollador B modifica Foo.c en su copia de trabajo.

Una actualización de la copia de trabajo de B acaba con un conflicto de árbol. Para un conflicto simple de fichero: 

Bar.c se añade a la copia de trabajo como un fichero normal.



Foo.c se marca como añadido (con historia) y tiene un conflicto de árbol.

Para un conflicto de carpeta: 

BarFolder se añade a la copia de trabajo como una carpeta normal.

125



FooFolder se marca como añadida (con historia) y tiene un conflicto de árbol.



Foo.c se marca como modificado.

El desarrollador B tiene ahora que decidir si desea continuar con la reorganización del desarrollador A y fusionar sus cambios en los ficheros correspondientes de la nueva estructura, o simplemente revertir los cambios de A y mantener el fichero local.

Para fusionar sus cambios locales con la reorganización, el desarrollador B tiene que encontrar primero qué nombre de fichero tiene ahora el fichero en conflicto Foo.c que fue renombrado/movido en el repositorio. Esto puede hacerse utilizando el diálogo de registro. Luego debe fusionar los cambios a mano ya que no hay actualmente forma de automatizar o simplificar este proceso. Una vez que se hayan portado los cambios, la ruta en conflicto es redundante y puede borrarse. En este caso utilice el botón Eliminar en el diálogo de editar conflictos para limpiar y marcar el conflicto como resuelto.

Si el desarrollador B decide que los cambios de A eran erróneos deberá elegir el botón Mantener en el diálogo de editar conflictos. Esto marca el fichero o carpeta en conflicto como resuelto, pero los cambios del desarrollador A tendrán que eliminarse a mano. De nuevo el diálogo de registro ayuda a controlar lo que se ha movido.

Eliminación local, entra una eliminación en la actualización 1. El desarrollador A mueve Foo.c a Bar.c y lo confirma en el repositorio 2. El desarrollador B mueve Foo.c a Bix.c Una actualización de la copia de trabajo del desarrollador B acaba con un conflicto de árbol: 

Bix.c se marca como añadido con historia.



Bar.c se añade a la copia de trabajo con el estado 'normal'.



Foo.c se marca como borrado y tiene un conflicto de árbol.

Para resolver este conflicto, el desarrollador B tiene que averiguar qué nombre de fichero tiene ahora el fichero en conflicto Foo.c que fue renombrado/movido en el repositorio.

Esto puede hacerse utilizando el diálogo de registro.

Luego el desarrollador B tiene que decidir qué nuevo nombre de fichero de Foo.c mantiene - el del desarrollador A o el renombrado que hizo él mismo.

126

Después de que el desarrollador B haya resuelto manualmente el conflicto, el conflicto de árbol debe marcarse como resuelto mediante el botón del diálogo de editar conflictos.

Falta en local, entra un cambio en la fusión 1.

El desarrollador A, que está trabajando en el tronco, modifica Foo.c y lo

confirma en el repositorio 2. El desarrollador B, que está trabajando en una rama, mueve Foo.c a Bar.c y lo confirma en el repositorio Una fusión de los cambios en el tronco del desarrollador A con los cambios de la copia de trabajo de la rama del desarrollador B acaba con un conflicto de árbol: 

Bar.c ya está en la copia de trabajo con estado 'normal'.



Foo.c se marca como faltante con un conflicto de árbol.

Para resolver este conflicto, el desarrollador B tiene que marcar el fichero como resuelto en el diálogo de edición de conflictos, lo que lo eliminará de la lista de conflictos. Luego tendrá que decidir si copia el fichero faltante Foo.c desde el repositorio a la copia de trabajo, si fusiona los cambios del desarrollador A hechos a Foo.c en el fichero renombrado Bar.c, o si desea ignorar los cambios marcando el conflicto como resuelto y no haciendo nada más.

Tenga en cuenta que si copia el fichero faltante desde el repositorio y luego marca como resuelto, su copia de eliminará de nuevo. Tiene que resolver el conflicto antes.

Edición local, entra un borrado en la fusión 1. El desarrollador A, que está trabajando en el tronco, mueve Foo.c a Bar.c y lo confirma en el repositorio 2. El desarrollador B, que está trabajando en una rama, modifica el fichero Foo.c y lo confirma en el repositorio.

Hay un caso equivalente cuando se mueven carpetas, pero todavía no se detecta en Subversion 1.6...

1. El desarrollador A, que está trabajando en el tronco, mueve la carpeta padre FooFolder a BarFolder y lo confirma en el repositorio.

2. El desarrollador B, que está trabajando en un rama, modifica Foo.c en su copia de trabajo.

127

Una fusión de los cambios en el tronco del desarrollador A con los cambios de la copia de trabajo de la rama del desarrollador B acaba con un conflicto de árbol: 

Bar.c se marca como añadido.



Foo.c se marca como modificado con un conflicto de árbol.

El desarrollador B tiene ahora que decidir si desea continuar con la reorganización del desarrollador A y fusionar sus cambios en los ficheros correspondientes de la nueva estructura, o simplemente revertir los cambios de A y mantener el fichero local.

Para fusionar sus cambios locales con la reorganización, el desarrollador B debe primero averiguar qué nombre de fichero tiene ahora el fichero en conflicto Foo.c que fue renombrado/movido en el repositorio. Esto se puede hacer utilizando el diálogo mostrar registro sobre el origen de la fusión. El editor de conflictos sólo muestra el registro para la copia de trabajo ya que no sabe qué ruta fue utilizada en la fusión, así que lo tendrá que averiguar por su cuenta. Luego se deben fusionar los cambios a mano ya que no hay actualmente forma de automatizar o simplificar este proceso. Una vez que los cambios se hayan portado, la ruta en conflicto es redundante y puede eliminarse. En este caso utilice el botón Eliminar en el diálogo de edición de conflictos para limpiar y marcar el conflicto como resuelto.

Si el desarrollador B decide que los cambios de A eran erróneos, deberá elegir el botón Mantener en el diálogo de editar conflictos. Esto marca el fichero o carpeta en conflicto como resuelto, pero los cambios del desarrollador A deberán eliminarse a mano. De nuevo el diálogo de registro sobre el origen de la fusión ayuda a averiguar qué se movió.

Eliminación local, entra un borrado en la fusión 1. El desarrollador A, que está trabajando en el tronco, mueve Foo.c a Bar.c y lo confirma en el repositorio 2. El desarrollador B, que está trabajando en una rama, mueve Foo.c a Bix.c y lo confirma en el repositorio Una fusión de los cambios en el tronco del desarrollador A con los cambios de la copia de trabajo de la rama del desarrollador B acaba con un conflicto de árbol: 

Bix.c se marca con el estado normal (no modificado).



Bar.c se marca como añadido con historia.



Foo.c se marca como faltante con un conflicto de árbol.

128

Para resolver este conflicto, el desarrollador B tiene que averiguar qué nombre de fichero tiene ahora el fichero en conflicto Foo.c que fue renombrado/movido en el repositorio.

Esto puede hacerse utilizando el diálogo de registro sobre el origen de la fusión. El editor de conflictos sólo muestra el registro de la copia de trabajo, dado que no conoce qué ruta se utilizó para la fusión, por lo que tendrá que averiguarlo por si mismo.

Luego el desarrollador B tiene que decidir qué nuevo nombre de fichero de Foo.c mantiene - el del desarrollador A o el renombrado que hizo él mismo.

Después de que el desarrollador B haya resuelto manualmente el conflicto, el conflicto de árbol debe marcarse como resuelto mediante el botón del diálogo de editar conflictos.

Obteniendo información del estado Mientras está trabajando en su copia de trabajo a menudo necesitará saber qué ficheros ha cambiado/añadido/borrado o renombrado, o incluso qué ficheros han sido cambiados y confirmados por los demás.

Iconos sobreimpresionados

Figura 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

sobreimpresionado es diferente.

estado

en

Subversion

del

fichero,

el

icono

129

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

130

ser un “Buen Ciudadano (TM)” y limita su uso de sobreimpresiones para darles una oportunidad al resto de aplicaciones.

Columnas de TortoiseSVN en el Explorador de Windows 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.

Importante Las columnas adicionales en el Explorador de Windows no están disponibles en Vista, dado que Microsoft decidió no habilitar tales columnas para todos los ficheros, sino únicamente para tipos de ficheros específicos.

Sugerencia Si desea que la organización actual se muestre en todas sus copias de trabajo, puede que desee convertirla en su vista por defecto.

Estado local y remoto

Figura 13: Comprobar modificaciones

131

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.

Azul Ítems modificados localmente.

Púrpura Ítems añadidos. Los ítems que han sido añadidos con historia tienen un signo + en la columna Estado del texto, y un texto de ayuda que le muestra de dónde ha sido copiado.

Rojo oscuro Ítems faltantes o borrados.

Verde Ítems modificados localmente y en el repositorio. Los cambios se fusionarán al actualizar. Ésto puede producir conflictos al actualizar.

Rojo brillante Items modificados localmente y borrados en el repositorio, o modificados en el repositorio y borrados localmente. Esto producirá conflictos al actualizar.

Negro Ítems sin cambios y sin versionar.

132

Este es el esquema de colores por defecto, pero puede personalizar dichos colores utilizando el diálogo de configuració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!

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 pueden 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 relación entre ellas, también puede agrupar los ficheros juntos en 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

133

copia de trabajo completa. Si quiere ver esa información para la copia de trabajo completa debe seleccionar la casilla Mostrar ficheros no modificados.

Sugerencia Si quiere una vista llana de su copia de trabajo, por ejemplo mostrando todos los ficheros y carpetas en todos los niveles de su jerarquía de carpetas, entonces el diálogo Comprobar modificaciones es la forma más sencilla de conseguirlo.

Símplemente seleccione la casilla Mostrar archivos no modificados para ver todos los ficheros de su copia de trabajo.

Reparando renombrados externos A veces los ficheros se renombran fuera de Subversion, y se muestran en la lista de ficheros como un fichero faltante y un fichero no versionado. Para evitar perder la historia necesita notificar a Subversion su conexión. Simplemente seleccione tanto el nombre antiguo (faltante) como el nombre nuevo (sin versionar) y utilice Menú contextual → Reparar movimiento para emparejar los dos ficheros como un renombrado.

Viendo diferencias 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.

Sugerencia Puede mostrar diferencias incluso cuando no está dentro de una copia de trabajo, o cuando tiene múltiples versiones del fichero alrededor: Seleecione los dos ficheros que desea comparar en el explorador (por ejemplo, utilizando la tecla Ctrl y el ratón) y seleccione Diferenciar del menú contextual de TortoiseSVN. El fichero que haya pulsado en último lugar (el que tiene el foco, es decir, el rectángulo con puntos) será tomado como más nuevo.

134

Listas de cambios En un mundo ideal, sólo trabajará en una cosa cada vez, y su copia de trabajo sólo contendrá un conjunto de cambios lógicos. Bueno, de vuelta al mundo real. A menudo ocurre que tiene que trabajar en varias tareas sin relación entre sí a la vez, y cuando mira en el diálogo de confirmar, todos los cambios están juntos y mezclados. La característica lista de cambios le ayuda a hacer agrupaciones de ficheros, facilitando ver qué se está haciendo. Por supuesto ésto sólo funciona si los cambios no se superponen. Si dos tareas diferentes afectan al mismo archivo, no hay forma de separar los cambios.

Importante La característica de lista de cambios en TortoiseSVN sólo está disponible en Windows XP y posterior, puesto que depende de una capacidad del shell que no está presente en Windows 2000.

Puede ver las listas de cambios en varios lugares, pero los más importantes son el diálogo de confirmación y el de comprobar modificaciones. Empecemos en el diálogo comprobar modificaciones después de que haya estado trabajando en varias características y varios ficheros. La primera vez que abra el diálogo, todos los ficheros modificados se muestran juntos. Supongamos que ahora quiere organizar las cosas y agrupar esos ficheros según la característica.

Seleccione uno o más ficheros y utilice Menú contextual → Mover a la lista de cambios para añadir un ítem a una lista de cambios. Inicialmente no habrá listas de cambios, por lo que la primera vez que ejecute esto tendrá que crear una nueva lista de cambios. Dele un nombre que describa para qué la está utilizando, y pulse Aceptar. El diálogo de confirmación cambiará para mostrar agrupaciones de ítems.

Una vez que haya creado una lista de cambios puede arrastrar y soltar ítems en ella, tanto desde otra lista de cambios como desde el Explorador de Windows. Arrastrar desde el Explorador puede ser útil ya que le permite añadir ítems a una lista de cambios antes de que el fichero sea modificado. Puede hacer eso desde el diálogo comprobar modificaciones, pero sólo si muestra todos los ficheros no modificados.

135

Figura 14: Diálogo de confirmación con listas de cambios En el diálogo de confirmación puede ver esos mismos ficheros, agrupados por listas de cambios. Además de dar una indicación visual inmediata de las agrupaciones, también puede utilizar los encabezados de grupo para seleccionar qué ficheros confirmar.

En XP hay un menú contextual que aparece cuando hace click con el botón derecho en una cabecera de grupo, y que le ofrece la posibilidad de marcar o desmarcar todas las entradas de grupo. En Vista sin embargo el menú contextual no es necesario. Haga click en la cabecera de grupo para seleccionar todas las entradas, y luego marque la casilla de una de las entradas seleccionadas para marcarlas todas.

TortoiseSVN reserva un nombre de lista de cambios para su propio uso, llamada ignoreon- commit. Se utiliza para marcar los ficheros versionados que casi nunca querrá confirmar, incluso aunque tengan cambios locales.

Cuando confirme ficheros que pertenezcan a una lista de cambios, normalmente no es necesario que dichos ficheros sigan perteneciendo a la lista de cambios. Por este motivo, y por defecto, los ficheros se eliminan de las listas de cambios automáticamente al ser confirmados. Si desea mantener el fichero en su lista de cambios, utilice la casilla Mantener listas de cambios en la parte inferior del diálogo de confirmación.

Sugerencia Las listas de cambios son una característica únicamente del cliente local. La creación y eliminación de listas de cambios no afectan ni al repositorio ni a la copia de trabajo de ningún otro cliente. Simplemente son una forma conveniente para organizar sus ficheros.

136

Diálogo de Registro de revisiones Para cada cambio que haga y confirme, debería proporcionar un mensaje de registro de ese cambio. Así podrá averiguar después qué cambios hizo y por qué, y tendrá un registro detallado para su proceso de desarrollo.

El diálogo de Registro de revisiones recopila todos esos mensajes de registro y se los enseña. La pantalla se divide en tres paneles.

El panel superior le muestra una lista de revisiones donde se confirmaron cambios a los ficheros/carpetas. Este sumario incluye la fecha y la hora, la persona que confirmó la revisión y el inicio del mensaje de registro.

Las líneas azules indican que algo se ha copiado a esta línea de desarrollo (quizás desde una rama). 

El panel medio le muestra el mensaje de registro completo para la revisión seleccionada.



El panel inferior le muestra una lista de todos los ficheros y carpetas que se cambiaron como parte de la revisión seleccionada.

Pero hace mucho más que eso - le proporciona comandos del menú contextual que puede utilizar para obtener aún más información de la historia del proyecto.

Invocando el diálogo de Registro de revisiones

Figura 15: El diálogo de Registro de revisiones

137

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

Desde el submenú contextual de TortoiseSVN



Desde la página de propiedades



Desde el diálogo de Progreso después de que termine una actualización. En ese caso el diálogo de Registro sólo le mostrará aquellas revisiones que cambiaron desde su última actualización

Acciones del registro de revisiones 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.

Obteniendo información adicional

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

138

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.

Comparar con la copia de trabajo Comparar las revisiones seleccionadas con su copia de trabajo. La Herramienta de Diferencias por defecto es TortoiseMerge que se proporciona con TortoiseSVN. Si el diálogo de registro es de una carpeta, esto mostrará una lista de sus ficheros cambiados, y le permitirá revisar los cambios hechos a cada fichero individualmente.

Comparar y mostrar autoría con la BASE de trabajo Obtener la información de autoría de la revisión seleccionada, y del fichero en su BASE de trabajo, y comparar los resultados utilizando una herramienta visual de diferencias.

Mostrar cambios como diff unificado Ver los cambios hechos en la revisión seleccionada como fichero de diff unificado (formato de parche GNU). Esto le muestra sólo las diferencias con unas pocas líneas de contexto. Es más dificil de leer que una comparación visual de ficheros, pero le mostrará todos los cambios juntos en un formato compacto.

Comparar con la revisión anterior Compara la revisión seleccionada con la revisión anterior. Esto funciona de forma similar a comparar con su copia de trabajo. Para carpetas esta opción mostrará primero el diálogo de ficheros cambiados permitiéndole seleccionar los ficheros a comparar.

Comparar y mostrar autoría con la revisión anterior Muestra el diálogo de ficheros cambios permitiéndole seleccionar ficheros. Obtiene la información de autoría de la revisión seleccionada, y de la revisión anterior, y compara los resultados utilizando una herramienta visual de diferencias (sólo para carpetas).

Guardar revisión en...

139

Almacenar la revisión seleccionada en un fichero, para que pueda tener una versión antigua de ese fichero. (Sólo para ficheros).

Abrir / Abrir con...

Abrir el fichero seleccionado, bien con el visor por defecto para ese tipo de fichero, o bien con el programa que elija. (Sólo para ficheros).

Autoría...

Muestra la autoría del fichero hasta la revisión seleccionada (sólo para ficheros).

Explorar el repositorio Abrir el navegador de repositorios para examinar el fichero o la carpeta seleccionados en el repositorio tal y como estaban en la revisión seleccionada.

Crear rama/etiqueta desde la revisión Crea una rama o una etiqueta desde la revisión seleccionada. Esto es útil por ejemlpo si se le olvidó crear una etiqueta y ya ha confirmado algunos cambios que se supone que no deben ir en esa versión.

Actualizar ítem a la revisión Actualizar su copia de trabajo a la revisión seleccionada. Útil si quiere hacer que su copia de trabajo refleje un momento en el pasado, o si ha realizado confirmaciones posteriores en el repositorio y quiere actualizar su copia de trabajo un paso cada vez. Es mejor actualizar un directorio completo en su copia de trabajo, no sólo un fichero, ya que si no su copia de trabajo podría ser inconsistente. Si desea deshacer un cambio anterior de forma permanente, utilice Revertir a esta revisión Revertir a esta revisión Revierte a una revisión anterior. Si ha hecho varios cambios, y luego decide que realmente desea volver a dejar las cosas como estaban en la revisión N, este es el comando que necesita. Los cambios se revierten en su copia de trabajo, por lo que esta operación no afecta al repositorio hasta que confirme los cambios. Tenga en cuenta que

140

esto deshará todos los cambios que se hayan realizado tras la revisión seleccionada, reemplazando el fichero o la carpeta con la versión anterior.

Si su copia de trabajo está en un estado no modificado, después de realizar esta acción su copia de trabajo se mostrará como modificada. Si ya tiene cambios locales, este comando fusionará los cambios de deshacer en su copia de trabajo.

Lo que ocurre internamente es que Subversion realiza una fusión inversa de todos los cambios realizados después de la revisión seleccionada, deshaciendo el efecto de esas confirmaciones sobre las previas.

Si después de realizar esta acción decide que desea deshacer lo deshecho y volver a obtener su copia de trabajo a su estado previo sin modificaciones, deberá utilizar TortoiseSVN → Revertir desde el Explorador de Windows, lo que descartará los cambios locales hechos por esta acción de fusión inversa.

Si desea simplemente ver cómo estaba un fichero o una carpeta en una revisión anterior, utilice Actualizar a la revisión o Guardar revisión como....

Revertir los cambios hechos en esta revisión Deshace los cambios que se hicieron en la revisión seleccionada. Estos cambios se deshacen en su copia de trabajo, ¡por lo que esta operación no afecta al repositorio en absoluto! Tenga en cuenta que esto deshará únicamente los cambios hechos en esa revisión; no reemplaza su copia de trabajo con el fichero completo tal y como estaba en la revisión anterior. Esto es muy útil para deshacer un cambio anterior cuando ya se han hecho otros cambios que no tienen que ver con él.

Si su copia de trabajo está en un estado no modificado, después de realizar esta acción su copia de trabajo se mostrará como modificada. Si ya tiene cambios locales, este comando fusionará los cambios de deshacer en su copia de trabajo.

Lo que ocurre internamente es que Subversion realiza una fusión inversa de esa única revisión, deshaciendo sus efectos sobre la confirmación anterior.

Puede deshacer lo deshecho tal y como se describe arriba en Revertir a esta revisión.

Fusionar revisión en...

141

Fusiona la(s) revision(es) seleccionada(s) en una copia de trabajo diferente. 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 en otra.

Obtener...

Hace una obtención nueva de la carpeta seleccionada en la revisión seleccionada. Esto muestra un diálogo para que confirme la URL y la revisión, y seleccione un lugar para la obtención.

Exportar...

Exporta la carpeta o el fichero seleccionado en la revisión seleccionada. Esto muestra un diálogo para que confirme la URL y la revisión, y para que seleccione un lugar para la exportación.

Editar autor / mensaje de registro Editar el mensaje de registro o el autor adjunto a una confirmación anterior.

Mostrar propiedades de la revisión Ver y editar cualquier propiedad de revisión, no sólo el mensaje de registro y el autor.

Copiar al portapapeles Copia los detalles de registro de las revisiones seleccionadas al portapapeles.

Esto copia el número de revisión, el autor, la fecha, el mensaje de registro y la lista de ítems cambiados para cada revisión.

Buscar mensaje de registro...

Buscar en los mensajes de registro el texto que desee. Esto busca en los mensajes de registro que ha introducido, y también en los sumarios de acción creados por Subversion (mostrados en el panel inferior). La búsqueda no distingue mayúsculas y minúsculas.

142

Figura 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: Comparar revisiones Compara las dos revisiones seleccionadas utilizando una herramienta de diferencias visual. La herramienta de diferencias por defecto es TortoiseMerge que se proporciona con TortoiseSVN. Si selecciona esta opción para una carpeta, aparecerá un diálogo posterior mostrando los ficheros cambiados y ofreciéndole más opciones de diferenciación.

Autoría de las revisiones Obtener la información de autoría de las dos revisiones y comparar los resultados utilizando una herramienta visual de diferencias.

Mostrar diferencias como diff unificado Ver las diferencias entre las dos revisiones seleccionadas como un fichero diff unificado. Esto funciona para ficheros y carpetas.

Copiar al portapapeles Copie los mensajes de registro al portapapeles tal y como se describió anteriormente.

Buscar mensaje de registro...

Buscar mensajes de registro como se describe más arriba.

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

143

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 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 Mostrar cambios Mostrar los cambios hechos en la revisión seleccionada sobre el fichero seleccionado. Este menú contextual sólo está disponible para los ficheros que se muestran como modificados.

Autoría de los cambios Obtener la información de autoría de la revisión seleccionada y de la revisión anterior del fichero seleccionado, y comparar los resultados utilizando una herramienta visual de diferencias.

Mostrar como diff unificado Mostrar los cambios del fichero en formato diff unificado. Este menú contextual sólo está disponible para los ficheros que se muestran como modificados.

Abrir / Abrir con...

144

Abrir el fichero seleccionado, bien con el visor por defecto para ese tipo de fichero, o bien con el programa que elija.

Autoría...

Abre el diálogo Autoría, permitiéndole ver la información de autoría hasta la revisión seleccionada.

Revertir los cambios hechos en esta revisión Revertir los cambios hechos al fichero seleccionado en esa revisión.

Mostrar propiedades Ver las propiedades de Subversion del ítem seleccionado.

Mostrar registro Mostrar el registro de revisiones para ese fichero seleccionado.

Obtener registros de fusiones Muestra el registro de revisiones para el único fichero seleccionado, incluyendo los cambios fusionados.

Guardar revisión en...

Grabar la revisión seleccionada a un fichero, para que pueda tener una versión antigua de ese fichero.

Sugerencia Puede haberse dado cuenta de que a veces nos referimos a cambios y otras veces a diferencias. ¿Cuál es la diferencia?

Subversion utiliza números de revisión para dos cosas diferentes. Una revisión generalmente representa el estado de un repositorio en un momento en el tiempo, pero también puede utilizarse para representar el conjunto de cambios que generaron esa revisión; por ejemplo, “Hecho en la r1234” significa que los cambios confirmados en la revisión 1234 implementan la característica X. Para dejar claro en qué sentido se utilizan, empleamos dos términos distintos.

145

Si selecciona dos revisiones N y M, el menú contextual le ofrecerá mostrar las diferencias entre estas dos revisiones. En términos de Subversion esto es diff -r M:N. Si selecciona una única revisión N, el menú contextual le ofrecerá mostrar los cambios realizados en esa revisión. En términos de Subversion esto es diff -r N1:N o diff -c N. El panel inferior le muestra los ficheros cambiados en todas las revisiones seleccionadas, por lo que el menú contextual siempre ofrece mostrar cambios.

Obteniendo más mensajes de registro El diálogo Registro no siempre le muestra todos los cambios que se hayan hecho alguna vez por unos cuantos motivos: 

En un repositorio grande, puede haber cientos o incluso miles de cambios, y obtenerlos todos puede llevar mucho tiempo. Normalmente estará interesado sólo en los cambios más recientes. Por defecto, el número de mensajes de registro obtenidos se limita a 100, pero puede cambiar este valor en TortoiseSVN → Configuración

Cuando se marca la casilla Parar en copia/renombrado, Mostrar Registro se parará en el punto en el que el fichero o carpeta seleccionado se copió de algún otro lugar en el repositorio. Esto puede ser útil para buscar ramas (o etiquetas) porque se para en la raíz de esa rama, y le da una indicación rápida de los cambios hechos únicamente en esa rama.

Normalmente querrá dejar esta opción sin marcar. TortoiseSVN recuerda el estado de la casilla, por lo que respetará su preferencia.

Cuando se invoca el diálogo Mostrar Registro desde el diálogo Fusionar, la casilla siempre se marca por defecto. Esto es porque al fusionar lo más probable es buscar cambios en las ramas, y retroceder a la raíz de la rama no tiene sentido en ese caso.

Tenga en cuenta que Subversion actualmente implementa el renombrado como un par de copia/borrado, por lo que renombrar un fichero o carpeta también provocará que el diálogo de registro se pare si se marca esta opción.

146

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.

Revisión actual de la copia de trabajo 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.

Por defecto esto sólo funciona para ficheros. Esto es así porque la revisión actualizada de una carpeta puede no corresponderse con la revisión actualizada de su contenido, y la única forma de obtener la revisión actualizada efectiva de una carpeta es recorrer la copia de trabajo. Esta puede ser una operación lenta para copias de trabajo grandes, por lo que puede si desea habilitar esta característica deberá crear una clave de registro DWORD con valor 1 en HKCU\Software\TortoiseSVN\RecursiveLogRev.

Características de registro de fusión 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.

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

147

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.

Figura 19: El diálogo de registro mostrando revisiones con registro de fusión ¡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.

Cambiando el mensaje de registro y el autor 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).

148

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.

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.

Aviso Dado que las propiedades de revisión de Subversion no se versionan, al hacer modificaciones a estas propiedades (por ejemplo, la propiedad del mensaje svn:log) se sobreescribirá el valor anterior de esa propiedad para siempre.

Filtrando los mensajes de registro 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.

Pulse en el icono de búsqueda para seleccionar sobre qué información desea buscar, y para seleccionar el modo regex. Normalmente sólo necesitará una búsqueda de texto simple, pero si necesita utilizar términos de búsqueda más flexibles, puede utilizar expresiones regulares. Si mueve el ratón encima de la caja, aparecerá un texto de ayuda que le proporcionará pistas sobre cómo utilizar las funciones regex.El filtro funciona comprobando si su cadena de filtro concuerda con las entradas de registro, y de ellas sólo se muestran aquellas entradas que concuerdan con la cadena de filtro.

149

Para hacer que el filtro muestre todas las entradas de registro que no concuerdan con la cadena del filtro, comience la cadena con un signo de exclamación ('!'). Por ejemplo, una cadena de filtro !nombredeusuario mostrará sólo aquellas entradas que no fueron confirmadas por nombredeusuario.

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

También puede filtrar los nombres de las rutas en el panel inferior utilizando la casilla Ocultar rutas cambiadas no relacionadas. Las rutas relacionadas son aquellas que contienen la ruta utilizada para mostrar el registro. Si está obteniendo el registro de una carpeta, eso significa todo lo que esté en esa carpeta o debajo de ella. Para un fichero, significa sólo ese fichero. La casilla tiene tres estados: puede mostrar todas las rutas, poner en gris las rutas no relacionadas, u ocultar esas rutas completamente.

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.

Ningún formato de registro desde el navegador de repositorios Dado que el formateo depende del acceso a propiedades de Subversion, sólo verá los resultados cuando utilice una copia de trabajo obtenida. Acceder a las propiedades de forma remota es una operación lenta, por lo que no verá esta característica desde el navegador de repositorios.

Información estadística 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 estadísticas

150

Esta página le proporciona todas las cifras que pueda necesitar, en particular el período y el número de revisiones cubiertas, y algunos valores mínimos/máximos/medios.

Página de confirmaciones por autor

Figura 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 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

151

el total de confirmaciones) bajo el cual cualquier actividad se agrupa en una categoría Otros.

Página de confirmaciones por fecha

Figura 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.

152

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.

Refrescando la vista 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.

Viendo diferencias Uno de los requisitos más comunes en el desarrollo de proyectos es ver qué ha cambiado. Puede querer ver las diferencias entre dos revisiones del mismo fichero, o las diferencias entre dos ficheros separados. TortoiseSVN provee una herramienta integrada llamada TortoiseMerge para ver las diferencias entre ficheros de texto. Para ver las diferencias entre ficheros de imagen, TortoiseSVN también tiene una herramienta llamada TortoiseIDiff. Por supuesto, puede utilizar su herramienta de diferencias favorita si lo desea.

Diferencias de ficheros Cambios locales Si desea ver qué cambios ha hecho usted en su copia de trabajo, simplemente utilice el menú contextual del explorador y seleccione TortoiseSVN → Diferenciar.

Diferenciar con otra rama/etiqueta Si desea ver qué ha cambiado en el tronco (si está trabajando en una rama) o en una rama específica (si está trabajando en el tronco), puede utilizar el menú

153

contextual del explorador. Simplemente sostegna la tecla Mayúsculas mientras hace click con el botón derecho en el fichero. Luego, seleccione TortoiseSVN → Diferenciar con URL. En el siguiente diálogo, especifique la URL del repositorio con la que quiere comparar su fichero local.

También puede utilizar el navegador de repositorios y seleccionar dos árboles para diferenciar, quizás dos ramas, o una rama/etiqueta y el tronco. Ahí, el menú contextual le permite compararlos utilizando Comparar revisiones.

Diferenciar desde una revisión anterior Si desea ver las diferencias entre una revisión en concreto y su copia de trabajo, utilice el diálogo Registro de Revisiones, seleccione la revision de intereés, y luego seleccione Compar con la copia de trabajo desde el menú contextual.

Si desea ver la diferencia entre la última revision confirmada y su copia de trabajo, asumiendo que la copia de trabajo no se haya modificado, simplemente haga click con el botón derecho sobre el fichero. Luego, seleccione TortoiseSVN → Comparar con la revisión anterior. Esto realizará una diferenciación entre la revisión anterior a la fecha-dela-última-confirmación (tal y como se registró en su copia de trabajo) y la BASE de la copia de trabajo. Esto le muestra el último cambio hecho al fichero que lo llevó al estado que ahora está viendo en su copia de trabajo. No mostrará cambios más nuevos que su copia de trabajo.

Diferenciar entre dos revisiones antiguas Si desea ver las diferencias entre dos revisiones que ya se confirmaron, utilice el diálogo Registro de Revisiones y seleccione las dos revisiones que desea comparar (utilizando el modificador habitual Ctrl). Luego seleccione Comparar revisiones desde el menú contextual.

Si hizo esto desde el historial de revisiones de una carpeta, aparece un diálogo Comparar Revisiones, mostrando una lista de ficheros cambiados en esa carpeta.

Todos los cambios hechos en una confirmación Si desea ver los cambios hechos a todos los ficheros en una revisión en particular de una vez, puede utilizar la salida diff unificado (formato de parche GNU). Esto le muestra sólo las diferencias con unas pocas líneas de contexto. Es más dificil de leer que una

154

comparación visual de ficheros, pero le mostrará todos los cambios juntos. Desde el diálogo Registro de Revisiones, seleccione la revisión de interes, y luego seleccione Mostrar Diferencias como Diff Unificado desde el menú contextual.

Diferencias entre ficheros Si desea ver las diferencias entre dos ficheros diferentes, puede hacerlo directamente en el explorador seleccionando ambos ficheros (utilizando el modificador habitual Ctrl).

Luego desde el menú contextual del explorador seleccione TortoiseSVN → Diferenciar.

Diferencias entre un fichero/carpeta en la copia de trabajo y una URL Si desea ver las diferencias entre un fichero en su copia de trabajo, y un fichero en cualquier repositorio de Subversion, puede hacerlo directamente en el explorador seleccionando el fichero y pulsando la tecla Mayúsculas mientras hace click con el botón derecho para obtener el menú contextual. Seleccione TortoiseSVN → Diferenciar con URL. Puede hacer lo mismo para una carpeta de copia de trabajo. TortoiseMerge muestra esas diferencias de la misma forma que muestra un fichero de parche - una lista de ficheros cambiados que puede ver de uno en uno.

Diferencias con información de autoría Si desea ver no sólo las diferencias sino también el autor, revisión y la fecha en la que se hicieron los cambios, puede combinar los informes de diferencias y de autoría desde dentro del diálogo del historial de revisiones.

Si ha configurado una herramienta de diferenciado de terceros, puede utilizar Mayúsculas cuando seleccione el comando Diferenciar para utilizar la herramienta alternativa.

Opciones de fín de línea y espacios en blanco 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.

155

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.

Comparando carpetas

Figura 23: El diálogo Comparar Revisiones

156

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.

Añadiendo nuevos ficheros y directorios

Figura 24: Menú contextual del explorador para ficheros no versionados

157

Si ha creado nuevos ficheros y/o directorios durante su proceso de desarrollo, necesitará añadirlos también al control de código. Seleccione los ficheros y/o directorios y utilice TortoiseSVN → Añadir.

Después de que añada los ficheros o directorios al control de código, el fichero aparece con una sobreimpresión de icono añadido que significa que primero debe confirmar su copia de trabajo para que esos ficheros y directorios estén disponibles para otros desarrolladores. ¡Añadir un fichero/ directorio no afecta al repositorio!

Añadir muchos También puede usar el comando Añadir en carpetas que ya estén versionadas.

En ese caso, el diálogo de añadir le mostrará todos los ficheros sin versionar dentro de esa carpeta versionada. Esto ayuda si tiene muchos ficheros nuevos y necesita añadirlos todos de golpe.

Para añadir ficheros desde fuera de su copia de trabajo puede usar el manejador de arrastrar- y-soltar: 1. seleccione los ficheros que desea añadir 2.

arrástrelos con el botón derecho a su nuevo destino dentro de la copia de

trabajo 3. suelte el botón derecho del ratón 4. seleccione Menú contextual → SVN Añadir ficheros a esta Copia de Trabajo.

En ese momento los ficheros se copiarán a la copia de trabajo y se añadirán al control de versiones.

También puede añadir ficheros dentro de una copia de trabajo simplemente arrastrándolos con el botón izquierdo y soltándolos en el diálogo de confirmación.

Si añade un fichero o carpeta por error, puede deshacer la adición antes de confirmar utilizando TortoiseSVN → Deshacer añadir....

Copiando/Moviendo/Renombrando ficheros y carpetas A menudo ocurre que ya tiene los ficheros que necesita en otro proyecto en su repositorio, y que simplemente quiere copiarlos. Podría simplemente copiar los ficheros y añadirlos como se describe más arriba, pero eso no le dará ninguna historia. Y si

158

posteriormente arregla un error en los ficheros originales, sólo podrá fusionar el arreglo automáticamente si la nueva copia está relacionada con la original en Subversion.

La manera más fácil de copiar ficheros y carpetas desde dentro de una copia de trabajo es utilizar el menú contextual que aparece al arrastrar con el botón derecho. Cuando arrastra con el botón derecho un fichero o una carpeta de una copia de trabajo a otra, o incluso dentro de la misma carpeta, aparece un menú contextual cuando suelta el botón del ratón.

Figura 25: Menú de arrastre con el botón derecho para un directorio bajo el control de versiones Ahora puede copiar contenido existente versionado a un nuevo lugar, posiblemente renombrándolo al mismo tiempo.

También puede copiar o mover ficheros versionados dentro de una copia de trabajo, o entre dos copias de trabajo, utilizando el método familiar corta-y-pega. Utilice el método estándar de Windows Copiar o Cortar para copiar uno o más ítems versionados al portapapeles. Si el portapapeles contiene ítems versionados, puede utilizar TortoiseSVN → Pegar (tenga en cuenta: no es el método estándar de Windows Pegar) para copiar o mover estos ítems al nuevo lugar de la copia de trabajo.

Puede copiar ficheros y carpetas desde su copia de trabajo a otro lugar del repositorio utilizando TortoiseSVN → Rama/Etiqueta.

Puede localizar una versión anterior de un fichero o carpeta en el diálogo de registro y copiarlo a un nuevo lugar del repositorio directamente desde el diálogo de registro utilizando Menú contextual → Crear rama/etiqueta desde la revisión.

También puede utilizar el navegador de repositorio para localizar el contenido que quiere, y copiarlo en su copia de trabajo directamente desde el repositorio, o copiar entre dos lugares dentro del repositorio.

159

No se puede copiar entre repositorios Mientras que puede copiar y mover ficheros y carpetas dentro de un repositorio, no puede copiar o mover desde un repositorio a otro y preservar la historia utilizando TortoiseSVN. Ni siquiera si los repositorios residen en el mismo servidor. Todo lo que puede hacer el copiar el contenido en su estado actual y añadirlo como contenido nuevo en el segundo repositorio.

Si no está seguro de si dos URLs en el mismo servidor se refieren al mismo repositorio o a repositorios distintos, utilice el navegador de repositorios para abrir una de las URLs y averiguar dónde está la raíz del repositorio. Si puede ver ambos lugares en una única ventana del navegador de repositorios, entonces las dos rutas están en el mismo repositorio.

Ignorando ficheros y directorios

Figura 26: Menú contextual del explorador para ficheros no versionados En la mayoría de los proyectos tendrá ficheros y carpetas que no deberán estar sujetos al control de versiones. Esto puede incluir ficheros creados por el compilador, *.obj, *.lst, o quizás una carpeta de salida donde se almacenan los ejecutables. Cuando confirma los cambios, TortoiseSVN le muestra los ficheros no versionados, que rellenan la lista de ficheros del diálogo de confirmar. Por supuesto que puede desactivarlos para que no se muestren, pero entonces quizás se olvide de añadir un nuevo fichero de código fuente.

La mejor forma de evitar estos problemas es añadir los ficheros derivados a la lista de ignorados del proyecto. De esta forma nunca se mostrarán en el diálogo de confirmar, pero se seguirán señalando los genuinos ficheros de código no versionados.

160

Si hace click con el botón derecho en un único fichero no versionado, y selecciona el comando TortoiseSVN → Ignorar del menú contextual, aparecerá un submenú que le permitirá seleccionar sólo ese fichero, o todos los ficheros con la misma extensión. Si selecciona múltiples ficheros, no hay submenú y sólo puede añadir esos ficheros o carpetas específicos.

Si desea eliminar uno o más ítems de la lista de ignorados, haga click con el botón derecho en dichos ítems y seleccione TortoiseSVN → Eliminar de la Lista de Ignorados También puede acceder a la propiedad svn:ignore de la carpeta directamente. Esto le permitirá especificar patrones más generales utilizando expansión de comodines en los nombres de los ficheros, descrito más adelante.

La lista global de ignorados Otra forma de ignorar ficheros es añadirlos a la lista global de ignorados. La mayor diferencia aquí es que la lista global de ignorados es una propiedad del cliente. Se aplica a todos los proyectos de Subversion, pero sólo en el PC cliente. En general es mejor utilizar la propiedad svn:ignore donde sea posible, porque puede aplicarse a áreas del proyecto específicas, y funciona para todos los que obtengan el proyecto.

Ignorando ítems versionados Los ficheros y las carpetas verisonadas nunca pueden ser ignoradas - esta es una característica de Subversion.

Concordancia de patrones en las listas de ignorados 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: * Concuerda con cualquier cadena de caracteres, incluyendo la cadena vacía (sin caracteres). ?

Concuerda con un único cáracter cualquiera. [...]

161

Concuerda con cualquiera de los caracteres incluídos entre los corchetes.

Dentro de los corchetes, un par de caracteres separados por “-” concuerda con cualquier caracter existente entre los dos en el orden lexicográfico. Por ejemplo, [AGm-p] concuerda con cualquiera de estos: A, G, m, n, o o p.

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].

Sin rutas en la lista global de ignorados No debería incluir información de ruta en su patrón. La concordancia de patrones está pensando para usarse contra nombres de fichero planos y nombres de carpeta. Si desea ignorar todas las carpetas CVS, simplemente añada CVS a la lista de ignorados. No hay necesidad de especificar CVS */CVS como se hacía en versiones anteriores. Si desea ignorar todas las carpetas tmp que existen dentro de una carpeta prog y no dentro de una carpeta doc debería utilizar la propiedad svn:ignore. No hay una forma fiable de conseguir esto utilizando patrones globales de ignorados.

Eliminando, moviendo y renombrando Al contrario que CVS, Subversion le permite renombrar y mover ficheros y carpetas. Por tanto hay entradas de menú para borrar y renombrar en el submenú TortoiseSVN.

Figura 27: Menú contextual del explorador para ficheros versionados

162

Eliminando ficheros y carpetas 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.

Recuperando un fichero o una carpeta borrados

163

Si ha borrado un fichero o una carpeta y ya ha confirmado esa operación de borrado en el repositorio, entonces un comando TortoiseSVN → Revertir normal no los podrá recuperar. Pero el fichero o la carpeta borrados no están perdidos para siempre. Si sabe la revisión en la que se borraron el fichero o la carpeta (si no lo sabe, utilice el diálogo de registro para averiguarlo), abra el navegador de repositorios y cambie a esa revisión. Luego seleccione el fichero o la carpeta que ha borrado, haga click con el botón derecho y seleccione Menú Contextual → Copiar a..., y como destino de esa operación de copia seleccione la ruta de su copia de trabajo.

Moviendo ficheros y carpetas 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: 1. seleccione los ficheros o directorios que desea mover 2.

arrástrelos con el botón derecho a su nuevo destino dentro de la copia de

trabajo 3. suelte el botón derecho del ratón 4.

en el menú contextual seleccione Menú contextual → SVN Mover ficheros

versionados aquí Moviendo ficheros y carpetas 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: 1. seleccione los ficheros o directorios que desea mover 2.

arrástrelos con el botón derecho a su nuevo destino dentro de la copia de

trabajo 3. suelte el botón derecho del ratón 4.

en el menú contextual seleccione Menú contextual → SVN Mover ficheros

versionados aquí

164

No SVN Mueva externos NO debería utilizar los comandos TortoiseSVN Mover o Renombrar en una carpeta que ha sido creada utilizando svn:externals. Esta acción puede provocar que el ítem externo se elimine de su repositorio padre, probablemente molestando a muchas otras personas. Si necesita mover una carpeta externa, debería moverla como lo hace con el resto de ficheros sin versionar, y luego ajustar las propiedades svn:externals de las carpetas padres origen y destino.

Cambiando las mayúsculas/minúsculas en un nombre de fichero 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) 1. Confirme los cambios en su copia de trabajo.

2.

Renombrar el fichero de MAYusculas a mayUSCULAS directamente en el

repositorio utilizando el Navegador de Repositorios.

3. Actualice su copia de trabajo.

Solución B) 1.

Renombre de MAYusculas a MAYusculas_ con el comando Renombrar del

submenú de TortoiseSVN. 2. Confirme los cambios.

3. Renombre de MAYusculas_ a mayUSCULAS. 4. Confirme los cambios.

Lidiando con conflictos en las mayúsculas/minúsculas de un nombre de fichero

165

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.

Evitando dos ficheros con el mismo nombre Hay un script gancho de servidor disponible en: http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/ Este script evitará confirmaciones cuyo resultado sea dos ficheros con conflicto en las mayúsculas.

Reparando renombrados de ficheros 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.

166

Eliminando ficheros no versionados 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.

Deshacer cambios Si desea deshacer todos los cambios que ha hecho en un fichero desde la última actualización, necesita seleccionar el fichero, hacer click con el botón derecho para sacar el menú contextual, y luego seleccionar el comando TortoiseSVN → Revertir Aparecerá un diálogo que le muestra los ficheros que ha cambiado y que puede revertir. Seleccione los que desee revertir y pulse Aceptar.

Figura 28: Diálogo de Revertir

167

Si desea deshacer un borrado o un renombrado, necesitará utilizar Revertir en la carpeta padre dado que el ítem borrado ya no existe y no podrá hacer click con el botón derecho sobre él.

Si quiere deshacer la adición de un ítem, esto aparece en el menú contextual como TortoiseSVN → Deshacer añadir.... Esto también es revertir, en realidad, pero su nombre se ha cambiado para hacerlo más obvio.

Las columnas en este diálogo pueden ser personalizadas de la misma forma que las columnas en el diálogo Comprobar modificaciones.

Deshaciendo cambios que han sido confirmados Revertir sólo deshará sus cambios locales. No deshace ningún cambio que ya haya sido confirmado.

Revertir es lento Cuando revierte los cambios puede que note que la operación lleva bastante más tiempo del que sería de esperar. Esto es así porque la versión modificada del fichero se manda a la papelera de reciclaje, para que pueda recuperar sus cambios si ha revertido por error. Sin embargo, si su papelera de reciclaje está llena, Windows necesita bastante tiempo para encontrar dónde poner el fichero.

La solución es simple: o bien vacía la papelera de reciclaje, o bien desactiva la casilla Utilizar la papelera de reciclaje al revertir en la configuración de TortoiseSVN. Limpieza Si un comando de Subversion no puede completarse de forma correcta, quizás por problemas en el servidor, su copia de trabajo puede quedarse en un estado inconsistente. En ese caso deberá utilizar TortoiseSVN → Limpiar en la carpeta. Es una buena idea hacerlo en la rama superior de la copia de trabajo.

El comando Limpiar tiene otro efecto secundario muy útil. Si ha cambiado la fecha de un fichero pero no su contenido, Subversion no puede determinar si el fichero ha cambiado realmente excepto haciendo una comparación byte-a-byte con la copia prístina. Si tiene muchos ficheros en este estado, comprobar su estado será muy lento, lo que hará que muchos diálogos ralenticen su respuesta. Ejecutando el comando Limpiar en su copia de

168

trabajo reparará esas fechas “rotas” y restaurará las comprobaciones de estado a la máxima velocidad.

Utilizar fechas de confirmación Algunas versiones anteriores de Subversion estaban afectadas con un error que causaba errores en la fecha cuando obtenía con la opción Utilizar fechas de confirmación activada. Utilice el comando Limpieza para acelerar esas copias de trabajo.

Configuración del proyecto A veces desea obtener información más detallada sobre un fichero o directorio que la que proporcionan los iconos sobreimpresionados. Puede obtener toda la información que Subversion proporciona en el diálogo de propiedades del explorador. Simplemente seleccione el fichero o directorio y seleccione Menú de Windows → Propiedades en el menú contextual (atención: ésta es la entrada normal del menú de propiedades que el explorador proporciona, ¡no la que está en el submenú de TortoiseSVN!). En el cuadro de diálogo de propiedades, TortoiseSVN ha añadido una nueva página de propiedades para los ficheros y carpetas bajo control de Subversion, donde puede ver toda la información relevante sobre el fichero/directorio seleccionado.

Figura 29: Página de propiedades del Explorador, pestaña Subversion

169

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”. svn:keywords Subversion soporta expansión de palabras clave similar a CVS, lo que puede utilizarse para introducir el nombre del fichero y la información de la revisión dentro del propio fichero. Las palabras clave actualmente soportadas son: $Date$ Fecha de la última confirmación conocida. Esto se basa en la información obtenida cuando actualiza su copia de trabajo. No se contacta con el repositorio para buscar cambios más recientes. $Revision$ Revisión de la última confirmación conocida. $Author$ Autor que hizo la última confirmación conocida. $HeadURL$ La URL completa de este fichero en el repositorio. $Id$ Una combinación comprimida de las cuatro palabras clave anteriores.

Para averiguar cómo utilizar estas palabras clave, lea la sección svn:keywords del Libro de Subversion, que porporciona información completa sobre estas palabras clave y cómo habilitarlas y utilizarlas.

Añadiendo y editando propiedades

170

Figura 30: 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.

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.

171

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”.

Exportando e importando propiedades A menudo se encontrará aplicando el mismo conjunto de propiedades muchas veces, por ejemplo bugtraq:logregex. Para simplificar el proceso de copiar propiedades de un proyecto a otro, puede utilizar la característica Exportar/Importar.

Desde el fichero o carpeta en el que las propiedades ya están establecidas, utilice TortoiseSVN → Propiedades, seleccione las propiedades que desea exportar y haga click en Exportar.... Se le preguntará por un nombre de fichero donde se grabarán los nombres de las propiedades y sus valores.

Desde la(s) carpeta(s) donde desea aplicar estas propiedades, utilice TortoiseSVN → Propiedades y haga click en Importar.... Se le preguntará por un nombre de fichero desde el que importar, por lo que deberá navegar al lugar donde almacenó el fichero exportado anteriormente y seleccionarlo. Las propiedades se añadirán a las carpetas de forma no recursiva.

Si desea añadir las carpetas a un árbol recursivamente, siga los pasos anteriores, y luego en el diálogo de propiedades seleccione cada propiedad por turnos, haga click en Editar..., seleccione la casilla Aplicar propiedad recursivamentey haga click en Aceptar.

El formato del fichero de importación es binario y propietario de TortoiseSVN. Su único propósito es transferir las propiedades utilizando Importar y Exportar, por lo que no hay necesidad de editar estos ficheros.

Propiedades binarias TortoiseSVN puede manejar valores de propiedades binarios utilizando ficheros. Para leer un valor de propiedad binario, utilice Grabar... para almacenarlo en un fichero. Para establecer un valor binario, utilice un editor hexadecimal u otra herramienta adecuada para crear un fichero con el contenido que necesite, y luego utilice Cargar... para leer ese fichero.

Aunque las propiedades binarias no se utilizan a menudo, pueden ser útiles en algunas aplicaciones. Por ejemplo, si está almacenando ficheros gráficos muy grandes, o si la aplicación que se utiliza para cargar el fichero es pesada, puede querer guardar una

172

pequeña imagen guía como una propiedad para poder obtener una previsualización rápidamente.

Establecer propiedades automáticamente Puede configurar Subversion y TortoiseSVN para que establezca propiedades automáticamente en ficheros y carpetas cuando se añaden al repositorio. Hay dos formas de hacerlo.

Puede editar el fichero de configuración de Subversion para habilitar esta característica en su cliente. La página General del diálogo de configuración de TortoiseSVN tiene un botón de edición para llevarle allí directamente. El fichero de configuración es un fichero de texto simple que controla algunas de las funciones de Subversion. Necesita cambiar dos cosas: primero, en la sección encabezada por miscellany, descomente la línea enable-auto-props = yes.

En segundo lugar, necesita editar la sección a continuación para definir qué propiedades quiere que se añadan a qué tipos de ficheros. Este método es una función estándar de Subversion y funciona con cualquier cliente de Subversion. Sin embargo, debe definirse en cada cliente de forma individual - no hay forma de propagar estas configuraciones desde el repositorio.

Un método alternativo es establecer la propiedad tsvn:autoprops en las carpetas, como se describe en la siguiente sección. Este método funciona sólo con los clientes TortoiseSVN, pero se propaga a todas las copias de trabajo al actualizarlas.

Sea cual sea el método que elija, debe tener en cuenta que las auto-props se aplican sólo a los ficheros en el momento en que se añaden al repositorio. Las auto-props nunca cambiarán las propiedades de ficheros que ya estén versionados.

Si desea estar totalmente seguro de que a los nuevos ficheros se les aplica las propiedades correctas, debería establecer un script gancho pre-confirmación para rechazar las confirmaciones cuando estas propiedades necesarias no estén establecidas.

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

173



tsvn:logminsize establece la longitud mínima de un mensaje de registro para una confirmación. Si introduce un mensaje más corto de lo especificado aquí, la confirmación se deshabilita. Esta característica es muy útil para que se acuerde de proporcionar un mensaje descriptivo apropiado para cada confirmación. Si esta propiedad no se establece, o el valores cero, se permiten mensajes de registro vacíos.



tsvn:lockmsgminsize establece la longitud mínima para un mensaje de bloqueo.

Si introduce un mensaje más corto de lo especificado aquí, el bloqueo se deshabilita. Esta característica es muy útil para que se acuerde de proporcionar un mensaje descriptivo apropiado para cada blqoueo que obtenga. Si esta propiedad no se establece, o el valor es cero, se permiten mensajes de bloqueo vacíos.



tsvn:logwidthmarker se utiliza con proyectos que necesitan que los mensajes de registro se formateen con algún ancho máximo (típicamente, 80 caracteres) antes de un salto de línea. Al establecer esta propiedad a un valor distinto de cero ocurren dos cosas en el diálogo de entrada de mensajes de registro: pone un marcador para indicar el ancho máximo, y deshabilita el ajuste de línea en la pantalla, para que pueda ver si el texto que ha introducido es muy largo. Tenga en cuenta que esta característica sólo funcionará correctamente si ha seleccionado una fuente de ancho fijo para los mensajes de registro.



tsvn:logtemplate se utiliza en proyectos que tienen reglas sobre el formateo de mensajes. Esta propiedad alberga una cadena de texto de múltiples líneas que se insertará en el cuadro del mensaje de confirmación cuando inice una confirmación. Puede editarlo para incluir la información necesaria. Tenga en cuenta que si estaba utilizando también tsvn:logminsize, debe asegurarse de establecer una longitud mayor que la de la plantilla o perderá el mecanismo de protección.



Subversion le permite establecer “autoprops” (autopropiedades), que serán aplicadas a los ficheros recién añadidos o importados, basándose en la extensión del fichero. Esto necesita que todos los clientes hayan establecido las autoprops adecuadas en el fichero de configuración de Subversion. tsvn:autoprops puede establecerse en carpetas y éstas se fusionarán con las autoprops locales del usuario cuando se importen o añadan ficheros. El formato es el mismo que para las

autopropiedades

de

Subversion,

por

ejemplo

*.sh

=

svn:eol-

style=native;svn:executable establece dos propiedades en los ficheros con extensión .sh.

174

Si hay un conflicto entre las autoprops locales y tsvn:autoprops, la configuración del proyecto tiene preferencia ya que son específicas para ese proyecto. 

En el diálogo de Confirmar tiene la opción de pegar la lista de ficheros cambiados, incluyendo

el

estado

de

cada

fichero

(añadido,

modificado,

etc).

tsvn:logfilelistenglish define si el estado del fichero se inserta en inglés o en el idioma traducido. Si la propiedad no se establece, el valor por defecto es true. 

TortoiseSVN puede utilizar los módulos de corrector ortográfico que se utilizan también por OpenOffice y Mozilla. Si tiene éstos instalados, esta propiedad determinará qué corrector ortográfico utilizar, es decir, en qué lenguaje deberían estar escritos los mensajes de registro para su proyecto. tsvn:projectlanguage establece el módulo de idioma que el motor del corrector ortográfico debería utilizar cuando introduzca un mensaje de registro. Puede encontrar los valores para su idioma en esta página: MSDN:LanguageIdentifiers.



Puede introducir este valor en decimal, o en hexadecimal si se precede por 0x.

Por ejemplo, Español (España, ordenación tradicional) puede introducirse como 0x040a or 1034.



La propiedad tsvn:logsummary se utiliza para extraer una porción del mensaje de registro que luego se muestra en el diálogo de registro como el sumario del mensaje de registro.

El valor de la propiedad tsvn:logsummary debe establecerse a una cadena de texto regex de una línea que contenga un grupo regex. Lo que satisfaga ese grupo se utilizará como sumario.

Por ejemplo: \[SUMARIO\]:\s+(.*) capturará todo lo que haya tras “[SUMARIO]” en el mensaje de registro y lo utillizará como sumario.



Cuando quiera añadir una nueva propiedad, puede o bien elegir una desde la lista en el cuadro desplegable, o puede introducir el nombre de propiedad que desee.

Si su proyecto utiliza algunas propiedades personalizadas, y quiere que esas propiedades aparezcan en la lista del cuadro desplegable (para evitar errores ortográficos cuando introduzca un nombre de propiedad), puede crear una llista de sus propias propiedades personalizadas utilizando tsvn:userfileproperties y tsvn:userdirproperties. Aplique estas propiedades a una carpeta. Cuando vaya a editar las propiedades de cualquier ítem hijo, sus propiedades personalizadas aparecerán en la lista de nombres de propiedades predefinidas.

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.

175

Establecer las propiedades de proyecto en carpetas Estas propiedades especiales del proyecto deben estar establecidas en carpetas para que el sistema funcione. Cuando confirma un fichero o una carpeta, se leen las propiedades de esa carpeta. Si no se encuentran allí las propiedades, TortoiseSVN las buscará hacia arriba en el árbol de carpetas para encontrarlas, hasta que llega a una carpeta sin versionar, o se encuentra la raíz del árbol (por ejemplo, C:\). Si puede estar seguro de que cada usuario obtiene sólo desde por ejemplo trunk/ y no desde alguna subcarpeta, entonces es suficiente establecer las propiedades en trunk/. Si no puede estar seguro, debería establecer las propiedades recursivamente en cada subcarpeta. Una propiedad establecida en una carpeta más profunda dentro de la jerarquía del proyecto tiene preferencia sobre las propiedades establecidas en niveles más altos (más cerca de trunk/).

Para las propiedades de proyecto sólo puede utilizar la casilla Recursivo para establecer la propiedad en todas las subcarpetas de la jerarquía, sin establecerla en todos los ficheros.

Cuando añada nuevas subcarpetas utilizando TortoiseSVN, cualquier propiedad de proyecto presente en la carpeta padre se añadirá también automáticamente a la nueva carpeta hija.

Atención Aunque las propiedades de proyecto de TortoiseSVN son extremadamente útiles, sólo funcionan con TortoiseSVN, y algunas sólo funcionarán en las versiones más recientes de TortoiseSVN. Si la gente que trabaja en su proyecto utiliza un número de clientes de Subversion diferentes, o es posible que tengan versiones antiguas de TortoiseSVN, puede que quiera utilizar ganchos de repositorio para forzar políticas de proyectos. Las propiedades de proyecto sólo ayudan a implementar una política, no pueden forzarlas.

Haciendo ramas / etiquetas Una de las características de los sistemas de control de versiones es la posibilidad de aislar cambios en una línea separada de desarrollo. Esto se conoce como una rama. Las

176

ramas se utilizan a menudo para probar nuevas características sin molestar la línea principal del desarrollo con errores de compilación y errores. Tan pronto como la nueva característica es lo suficiente estable, la rama de desarrollo se fusiona de nuevo en la rama principal (trunk, troncal/tronco).

Otra característica de los sistemas de control de versiones es la posibilidad de marcar revisiones particulares (por ejemplo, una versión lanzada a producción), para que pueda en cualquier momento recrear un cierto entorno o compilación. Este proceso se conoce como etiquetar.

Subversion no tiene comandos especiales para hacer ramas o etiquetas, pero en cambio utiliza lo que se denomina “copias baratas”. Las copias baratas son similares a los vínculos duros de Unix, que significa que en vez de hacer una copia completa en el repositorio, se crea un vínculo interno, apuntando a una revisión y árbol específicos.

Como resultado, las ramas y las etiquetas son muy rápidas de crear, y casi no conllevan espacio extra en el repositorio.

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

Figura 31: El diálogo Rama/Etiqueta

177

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: Revisión HEAD en el repositorio La nueva rama se copia directamente en el repositorio desde la revisión HEAD. No se necesita transferir datos desde su copia de trabajo, y la rama se crea muy rápidamente.

Revisión específica en el repositorio La nueva rama se copia directamente en el repositorio, pero puede elegir una versión anterior. Esto es útil si se olvidó de crear una etiqueta cuando lanzó una versión de su proyecto la semana pasada. Si no puede acordarse del número de revisión, pulse el botón a la derecha para mostrar el registro de revisiones, y seleccione el número de revisión desde allí. De nuevo no se transfiere datos desde su copia de trabajo, y la rama se crea muy rápidamente.

Copia de trabajo La nueva rama es una copia idéntica de su copia de trabajo local. Si ha cambiado algunos ficheros a una revisión anterior en su copia de trabajo, o si ha hecho cambios locales, esto es exactamente lo que irá a la copia. Naturalmente, esta

178

clase de etiquetado complejo conlleva transferir datos desde su copia de trabajo al repositorio si no existe ya allí.

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.

Obtener o cambiar 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: 

TortoiseSVN → Obtener para obtener una copia nueva en una carpeta vacía.

Puede obtener la copia de trabajo en cualquier parte de su disco duro, y puede crear tantas copias de trabajo de su repositorio como desee.



Cambiar su copia de trabajo actual a la copia recién creada en el repositorio. De nuevo seleccione la carpeta superior de su proyecto y utilice TortoiseSVN → Cambiar... del menú contextual.

En el siguiente diálogo, introduzca la URL de la rama que acaba de crear. Deje la opción Revisión HEAD activada y pulse Aceptar. Su copia de trabajo se cambia a la nueva rama/etiqueta.

Cambiar trabaja igual que Actualizar, en el sentido de que nunca pierde sus cambios locales. Cualquier cambio que haya hecho a su copia de trabajo que

179

todavía no se hayan confirmado se fusionarán cuando haga el Cambio. Si no desea que esto ocurra, entonces debe o bien confirmar los cambios antes de cambiar, o revertir su copia de trabajo a una revisión ya- confirmada (típicamente HEAD). 

Si desea trabajar en el tronco (trunk) y en la rama, pero no desea el coste de una obtención nueva, puede utilizar el Explorador de Windows para hacer una copia de la copia de trabajo obtenida, y luego TortoiseSVN → Cambiar... esa copia a su nueva rama.

Figura 32: 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. 

Las etiquetas se usan típicamente para crear una copia estática de un proyecto en una etapa concreta. Como tales normalmente no se utilizan para el desarrollo eso es para lo que se utilizan las ramas, y por esa razón recomendamos la estructura del repositorio /trunk/branches /tags en primer lugar. Trabajando en una revisión etiquetada no es una buena idea, pero dado que sus ficheros locales no están protegidos, no hay nada que le impida hacer esto por error. Sin embargo, si intenta confirmar a una ruta en el repositorio que contenga /tags/ (en inglés), TortoiseSVN le avisará.



Puede ser que necesite hacer más cambios a una versión que ya había etiquetado. La forma correcta de manejar esta situación es crear primero una nueva rama desde la etiqueta. Haga sus cambios en esta rama, y luego cree una nueva etiqueta para esta rama, por ejemplo Version_1.0.1.



Si modifica una copia de trabajo creada desde una rama y confirma, entonces los cambios irán a la nueva rama y no en el tronco. Sólo se guardan las modificaciones. El resto continúa siendo una copia barata.

180

Fusionando Mientras que las ramas se utilizan para mantener líneas de desarrollo separadas, en alguna etapa tendrá que fusionar los cambios hechos en una rama de vuelta en el tronco, o viceversa.

Es importante entender cómo funcionan las ramas y la fusión en Subversion antes de empezar a utilizarlos, porque puede convertirse en algo bastante complejo. Le recomendamos encarecidamente que lea el capítulo Creando ramas y fusionando en el Libro de Subversion, que le proporcionará una descripción completa, y muchos ejemplos de cómo se utiliza.

El siguiente punto a tener en cuenta es que la fusión siempre tiene lugar en una copia de trabajo. Si quiere fusionar cambios en una rama, deberá tener una copia de trabajo obtenida de dicha rama, e invocar el asistente de fusionado desde esa copia de trabajo utilizando TortoiseSVN → Fusionar....

En general es una buena idea realizar fusiones en una copia de trabajo sin modificar. Si ha hecho otros cambios en su copia de trabajo, confírmelos primero. Si la fusión no funciona como espera, puede querer revertir los cambios, y el comando Revertir descartará todos los cambios, incluidos cualquiera que haya hecho antes de la fusión.

Hay tres casos de uso comunes para fusionar que se manejan de formas ligeramente diferentes, como se describen a continuación. La primera página del asistente de fusión le pide seleccionar el método que necesita.

Fusionando un rango de revisiones.

Este método cubre el caso en el que ha hecho una o más revisiones a una rama (o al tronco) y desea portar estos cambios a una rama diferente.

Lo que le está pidiendo a Subversion que haga es: “Calcula los cambios necesarios para ir [DESDE] la revisión 1 de la rama A [HASTA] la revisión 7 de la rama A, y aplica esos cambios en mi copia de trabajo (del tronco o de la rama B).”

Reintegrando una rama. 

Este método cubre el caso cuando ha realizado una rama de funcionalidad como se discute en el libro de Subversion. Todos los cambios del tronco han sido portados a la rama de la funcionalidad, semana a semana, y ahora que la

181

funcionalidad está completa desea fusionarla de nuevo en el tronco. Dado que ha mantenido la rama de la funcionalidad sincronizada con el tronco, las últimas versiones de la rama y del tronco serán absolutamente iguales excepto por sus cambios en la rama. 

Este es un caso especial de la fusión de árboles describa más abajo, y necesita sólo la URL desde la que fusionar (normalmente) su rama de desarrollo. Utiliza las características de registro de fusiones de Subversion para calcular el rango de revisiones correcto que se debe utilizar, y realiza comprobaciones adicionales para asegurarse de que la rama ha sido completamente actualizada con los cambios del tronco. Esto le asegura que no va a deshacer accidentalmente el trabajo que otros han confirmado en el tronco desde sus últimos cambios sincronizados.



Tras la fusión, todo el desarrollo en las ramas ha sido completamente fusionado de vuelta a la línea principal. La rama ahora es redundante y puede eliminarse.



Una vez que haya realizado una fusión de reintegración no debería continuar usándola para desarrollo. La razón para esto es que si intenta resincronizar su rama existente desde el tronco más adelante, el registro de fusión verá su reintegración como un cambio del tronco que aún no ha sido fusionado en la rama, ¡e intentará fusionar la fusión rama-a-tronco de nuevo en la rama! La solución a esto es simplenete crear una nueva rama desde el tronco para continuar con la siguiente fase de su desarrollo.

Fusionando dos árboles diferentes.

Este es un caso más general del método de reintegración. Lo que le está pidiendo a Subversion que haga es: “Calcula los cambios necesarios para ir [DESDE] la revisión HEAD del tronco [HASTA] la revisión HEAD de la rama, y aplica esos cambios a mi copia de trabajo (del tronco).” El resultado neto es que el tronco ahora es exactamente igual a la rama.

Si su servidor/repositorio no soporta el registro de fusiones, entonces esta es la única forma de fusionar una rama de nuevo al tronco (trunk). Otro caso de uso ocurre cuando utiliza ramas de vendedor y necesita fusionar los cambios después de incorporar una nueva versión de ese código en el tronco.

Fusionando un rango de revisiones

182

Figura 33: 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.

Importante Hay una diferencia importante en la forma que se especifican los rangos de revisiones en TortoiseSVN comparado con el cliente de línea de comandos. La forma más fácil de visualizar esto es pensar en una valla con postes y paneles.

Con el cliente de línea de comandos se especifican los cambios a fusionar utilizando dos revisiones “postes” que especifican los puntos anterior y posterior.

183

Con TortoiseSVN se especifican los conjuntos de cambios a fusionar utilizando “paneles de vallas”. La razón para esto queda más clara cuando utiliza el diálogo de registro para seleccionar las revisiones a fusionar, donde cada revisión aparece como un conjunto de cambios.

Si está fusionando revisiones en bloques, el método mostrado en el Libro de Subversion le hará fusionar 100-200 esta vez y 200-300 la próxima. Con TortoiseSVN fusionará 100-200 esta vez y 201-300 la próxima.

Esta diferencia ha generado un montón de reacciones en las listas de trabajo. Nos damos cuenta de que es una diferencia respecto al cliente de línea de comandos, pero creemos que para la mayoría de usuarios GUI el método que hemos implementado es más fácil de entender.

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.

184

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” Reintegrando una rama.

Figura 34: 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

185

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.

Fusionando dos árboles diferentes

Figura 35: 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.

186

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

Opciones de fusió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 fin 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.

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

187

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.

Ahora que todo está preparado, todo lo que debe hacer es pulsar en el botón Fusionar. Si quiere previsualizar los resultados, el botón Probar fusión realiza la operación de la fusión, pero no modifica la copia de trabajo en absoluto. Le muestra una lista de ficheros que serán cambiados por la fusión real, y le notifica las áreas donde ocurrirán conflictos.

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.

Revisando los resultados de la fusió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.

188

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.

Sugerencia Si acaba de fusionar una rama de característica en el tronco, el tronco contiene ahora todo el código de la nueva característica, y la rama es obsoleta. Si lo necesita, puede borrar la rama del repositorio.

Importante Subversion no puede fusionar un fichero con una carpeta, y viceversa - sólo carpetas con carpetas y ficheros con ficheros. Si pulsa en un fichero y abre el diálogo de fusionar, entonces deberá darle una ruta a un fichero en ese diálogo. Si selecciona una carpeta y llama al diálogo, debe especificar una URL de una carpeta para la fusión.

Registro de fusión 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. 

Puede evitar el peligro de fusionar la misma revisión dos veces (problema de fusiones repetidas). Una vez que una revisión se ha marcado como que ha sido fusionada, las fusiones futuras que incluyan esa revisión en el rango la saltarán.



Cuando fusiona una rama de nuevo al tronco, el diálogo de registro le puede mostrar las confirmaciones de la rama como parte del registro del tronco, proporcionando una mejor trazabilidad de los cambios.



Cuando se meustra el diálogo de registro desde el diálogo de fusión, las revisiones ya fusionadas aparecen en gris.



Cuando muestre información de autoría para un fichero, puede elegir mostrar el autor original de la revisión fusionada, en vez de la persona que hizo la fusión.

189



Puede marcar revisiones como no fusionar si las incluye en la lista de revisiones fusionadas sin ejecutar realmente la fusión.

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.

Manejando conflictos durante la fusión 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 36: El diálogo Información de conflicto de fusión Cuando ocurre un conflicto durante la fusión, tiene tres formas de manejarlo.

1. Puede decidir que sus cambios locales son mucho más importantes, por lo que querrá descartar la versión del repositorio y mantener su versión local. O puede querer descartar sus cambios locales en favor de la versión del repositorio.

De cualquier forma, no se intenta fusionar los cambios - simplemente elige una u otra.

2. Normalmente querrá ver los conflictos y resolverlos. En ese caso, seleccione Editar conflicto, lo que iniciará su herramienta de fusionado. Cuando esté satisfecho con el resultado, pulse en Resuelto.

190

3. La última opción es posponer la resolución y continuar con el fusionado. Puede elegir hacerlo para el fichero en conflicto actual, o para todos los ficheros durante el resto de la fusión. Sin embargo, si hay más cambios en ese fichero, no será posible completar la fusión.

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 resultarí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 ;) Fusionar una rama completada 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 37: 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.

191

Mantenimiento de ramas de características 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.

Bloqueando Subversion generalmente trabaja mejor sin bloqueos, utilizando los métodos “CopiarModificar- Fusionar” que se describieron anteriormente en el “La solución copiarmodificar-fusionar”. Sin embargo, hay algunas pocas situaciones en las que puede querer implementar alguna forma de política de bloqueo.

Está utilizando ficheros “no fusionables”, por ejemplo, ficheros de imagen. Si dos personas cambian el mismo fichero, la fusión no es posible, así que alguno de ellos perderá sus cambios.

Su compañía ha utilizado en el pasado un sistema de control de versiones bloqueante, y la dirección ha decidido que “bloquear es lo mejor”.

Primero necesita asegurarse de que su servidor de Subversion está actualizado al menos a la versión 1.2. Las versiones anteriores no tienen ningún soporte de bloqueos. Si está usando el acceso file://, sólo necesitará actualizar sus clientes, por supuesto.

192

Cómo trabaja el bloqueo en Subversion 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ólolectura 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.

193

Obteniendo un bloqueo 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 38: 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...

Quitando un Bloqueo 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

194

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.

Comprobando el estado de los bloqueos

Figura 39: 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.

Evite romper y robar bloqueos Si ha roto o robado el bloqueo de otro sin decírselo, puede causar una pérdida potencial de trabajo. Si está trabajando con tipos de ficheros no fusionables y roba el bloqueo de otro, una vez que usted quite el bloqueo ellos son libres de confirmar sus cambios y sobreescribir los suyos. Subversion no pierde datos, pero ha perdido la protección para trabajo en equipo que el bloqueo le proporcionaba.

Haciendo ficheros no-bloqueados como sólo-lectura

195

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”.

Los scripts ganchos de bloqueo 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”.

Creando y aplicando parches En proyectos de código abierto (como éste), todos tienen acceso de lectura al repositorio, y cualquiera puede hacer una contribución al proyecto. ¿Así que cómo se controlan esas contribuciones?

Si

cualquiera

pudiera

confirmar

cambios,

el

proyecto

estaría

permanentemente inestable y probablemente roto de forma permanente. En esta situación, el cambio se maneja mediante un fichero de parche enviado al equipo de

196

desarrollo, que tienen acceso de escritura. Ellos pueden revisar el parche antes, y luego o bien confirmarlo en el repositorio o devolvérselo al autor.

Los ficheros de parche son simplemente ficheros de diff unificados que muestran las diferencias entre su copia de trabajo y la revisión base.

Creando un fichero parche Primero necesita hacer y probar sus cambios. Luego en vez de utilizar el comando TortoiseSVN → Confirmar... sobre la carpeta padre, seleccione TortoiseSVN → 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”.

Figura 40: El diálogo Crear parche 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.

197

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. 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.

Aplicando un fichero parche 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.

Desde el menú contextual de esa carpeta, pulse en TortoiseSVN → Aplicar Parche... Esto mostrará un diálogo de abrir fichero que le permitirá seleccionar el fichero de parche a aplicar. Por defecto sólo aparecen los ficheros .patch o .diff, pero puede elegir “Todos los ficheros”. Si había guardado previamente un parche en el portapapeles, puede usar Abrir desde el portapapeles... en el diálogo de abrir fichero.

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.

198

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. ¿Quién cambió qué línea?

A veces necesita saber no sólo qué lineas han cambiado, sino también exactamente quién cambió líneas específicas en un fichero. Entonces es cuando el comando TortoiseSVN → Autoría..., a veces conocido como comando de anotar, tiene su utilidad.

Este comando muestra, por cada línea en un fichero, su autor y la revisión en la que se cambió la línea.

Autoría de ficheros

Figura 41: 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

199

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 42: 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.

200

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 sí 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.

201

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”.

Autoría de las diferencias 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.

Autoría de las revisiones En el panel superior, seleccione dos revisiones, y luego seleccione Menú Contextual → Ver autoría de las revisiones. Esto obtendrá los datos de autoría de las dos revisiones, y luego utilizará el visor de diferencias para comparar los dos ficheros de autoría.

Ver la autoría de los cambios Seleccione una revisión en el panel superior, luego seleccione un fichero en el panel inferior y seleccione Menú contextual → Autoría de los cambios. Esto obtendrá los datos de autoría de la revisión seleccionada y la anterior, y utilizará el visor de diferencias para comparar los dos ficheros de autoría.

Comparar y ver autoría con la BASE de trabajo Muestre el registro de un único fichero, y en el panel superior, seleccione una única revisión, y luego seleccione Menú contextual → Comparar y ver autoría con la BASE de trabajo. Esto obtendrá los datos de autoría de la revisión seleccionada, y también del fichero en la BASE de trabajo, y utilizará el visor de diferencias para comparar los dos ficheros de autoría.

El navegador de repositorios A veces necesitará trabajar directamente en el repositorio, sin tener una copia de trabajo. Ésa es la razón por la que existe el Navegador de Repositorios. Igual que el Explorador y

202

los iconos sobreimpresionados le permiten ver su copia de trabajo, el navegador de repositorios le permite ver la estructura y el estado del repositorio.

Figura 43: El navegador de repositorios Con el navegador de repositorios puede ejecutar comandos como copiar, mover, renombrar... directamente en el repositorio.

El navegador de repositorios se parecerá al explorador de Windows, excepto que está mostrando el contenido del repositorio en una revisión concreta en vez de los ficheros de su ordenador. En el panel izquierdo puede ver un árbol de directorios, y en el panel derecho están los contenidos del directorio seleccionado. En la parte superior de la ventana del visor de repositorios puede introducir la URL del repositorio y la revisión que desea visualizar.

Al igual que el explorador de Windows, puede pulsar sobre los encabezados de las columnas en el panel derecho si desea establecer la ordenación. Y como en el explorador hay menús contextuales en ambos paneles.

203

El menú contextual para un fichero le permite: 

Abrir el fichero seleccionado, bien con el visor por defecto para ese tipo de fichero, o bien con el programa que elija.



Guardar una copia no versionada del fichero en su disco duro.



Mostrar el registro de las revisiones para ese fichero, o mostrar un gráfico de todas las revisiones para que pueda ver de dónde vino el fichero.



Ver la autoría del fichero, para saber quién cambió qué línea y cuándo.



Eliminar o renombrar el fichero.



Hacer una copia del fichero, bien a una parte diferente del repositorio, o bien a una copia de trabajo incluída dentro del mismo repositorio.



Ver/editar las propiedades del fichero.

El menú contextual para una carpeta le parmite: 

Mostrar el registro de revisiones para la carpeta, o mostrar un gráfico de todas las revisiones para que pueda ver de dónde vino la carpeta.



Exportar la carpeta a una copia local no versionada de su disco duro.



Obtener la carpeta para producir una copia de trabajo local en su disco duro.



Crear una nueva carpeta en el repositorio.



Añadir ficheros o carpetas directamente al repositorio.



Borrar o eliminar la carpeta.



Hacer una copia de la carpeta, bien a una parte diferente del repositorio, o bien a una copia de trabajo dentro del mismo repositorio.



Ver/Editar las propiedades de la carpeta.



Marcar la carpeta para comparación. La carpeta marcada se mostrará en negrita.



Comparar la carpeta con una carpeta marcada previamente, bien como diff unificado, o bien como una lista de ficheros que pueden diferenciarse visualmente utilizando

la

herramienta

de diferencias

por

defecto.

Esto

puede

ser

particularmente útil para comparar dos etiquetas, o el tronco y una rama para ver qué se ha cambiado.

Si selecciona dos carpetas en el panel derecho, puede ver las diferencias bien como diff unificado, o bien como una lista de ficheros que pueden diferenciarse visualmente utilizando la herramienta de diferencias por defecto.

204

Si selecciona múltiples carpetas en el panel derecho, puede obtenerlos todos a la vez en una carpeta padre común.

Si selecciona dos etiquetas que se han copiado desde la misma raíz (tipicamente, /trunk/), puede utilizar Menú Contextual → Mostrar Registro... para ver la lista de revisiones entre los dos puntos etiquetados.

Puede utilizar F5 para refrescar la vista como siempre. Esto refrescará todo lo que se esté viendo actualmente. Si quiere precargar o refrescar la información para los nodos que aún no han sido abiertos, utilice Ctrl-F5. Después de eso, la expansión de cualquier nodo ocurrirá automáticamente sin que haya una pausa por la red mientras se recoge la información.

También puede utilizar el navegador de repositorios para operaciones de arrastrar-ysoltar. Si arrastra una carpeta desde el Explorador al navegador de repositorios, se importará esa carpeta en el repositorio. Tenga en cuenta que si arrastra múltiples items, se importarán en confirmaciones separadas.

Si desea mover un ítem dentro del repositorio, simplemente arrastre con el botón izquierdo el ítem a su nuevo lugar. Si desea crear una copia en vez de mover el ítem, entonces deberá Ctrl-arrastrar con el botón izquierdo. Cuando copia, el cursor tiene un símbolo “más” en él, tal y como lo hace en el Explorador.

Si desea copiar/mover un fichero o una carpeta a otro lugar y darle también otro nombre a la vez, puede arrastrar con el botón derecho o Ctrl-arrastrar con el botón derecho el ítem en vez de arrastrarlo con el botón izquierdo. En ese caso, aparece un diálogo en el que puede introducir un nuevo nombre para el fichero o la carpeta.

Siempre que haga cambios en el repositorio utiizando uno de estos métodos, se le presentará un diálogo para introducir un mensaje de registro. Si ha arrastrado algo por error, esta es su oportunidad para cancelar la acción.

A veces cuando intenta abrir una ruta obtendrá un mensaje de error en vez de los detalles del ítem. Esto puede ocurrir si ha especificado una URL inválida, si no tiene permisos de acceso, o si hay algún otro problema en el servidor. Si necesita copiar este mensaje para incluirlo en un email, simplemente haga click con el botón derecho sobre él y utilice Menú Contextual → Copiar mensaje de error al portapapeles, o simplemente utilice Ctrl+C.

205

Gráficos de revisión

Figura 44: Un gráfico de revisiones A veces necesita saber desde qué revisión del tronco se tomaron las ramas y las etiquetas, y la forma ideal de ver este tipo de información es en un gráfico o una estructura de árbol. Ahí es cuando necesita utilizar TortoiseSVN → Gráfico de Revisiones...

Este comando analiza la historia de las revisiones e intenta crear un árbol mostrando los puntos en los que se tomaron las copias, y cuando se borraron las ramas/etiquetas.

Importante Para generar el gráfico, TortoiseSVN debe obtener todos los mensajes de registro desde la raíz del repositorio. No es necesario decir que esto puede llevar varios minutos incluso con un repositorio con unos pocos miles de revisiones, dependiendo de la velocidad del servidor, el ancho de banda de la red, etc. Si

206

intenta esto con algo como el proyecto Apache, que actualmente tiene más de 500.000 revisiones, puede estar esperando un buen rato.

Nodos del gráfico de revisión 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 Ïtems eliminados Los ítems borrados, por ejemplo una rama que no se necesita más, se muestran utilizando un octágono (rectángulo con las esquinas cortadas). El color por defecto es rojo. Ítems renombrados Los ítems renombrados también se muestran utilizando un octágono, pero el color por defecto es azul. Ítem normal Todos los demás ítems se muestran utilizando un rectángulo normal.

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.

Cambiando la vista 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.

Agrupar ramas Este modo agrupa los cambios por ramas, de forma que no hay una ordenación global por revisiones: las revisiones consecutivas en una rama se mostrarán (a

207

menudo) como líneas consecutivas. Las sub-ramas, sin embargo, se colocarán de forma que las ramas más nuevas se muestren encima de las ramas más antiguas para mantener el gráfico más delgado. Como resultado, una fila cualquier puede contener cambios de diferentes revisiones.

Más antiguo arriba Normalmente el gráfico muestra la revisión más antigua abajo, y el árbol crece hacia arriba. Utilice esta opción para hacer crecer el árbol desde arriba.

Alinear árboles en la parte superior Cuando un gráfico se parte en varios árboles más peuqeños, los árboles pueden aparecer bien en su órden de revisión natural, o alineados en la parte inferior de la ventana, dependiendo de si utiliza la opción Agrupar por ramas. Utilice esta opción para hacer crecer todos los árboles hacia abajo desde arriba.

Mostrar todas las revisiones Esto hace exactamente lo que espera, y muestra cada revisión donde algo (en el árbol del que está mostrando el gráfico) ha cambiado. Para historiales largos esto puede producir un árbol realmente enorme.

Mostrar revisiones HEAD Esto asegura que la última revisión de cada rama se muestra siempre en el gráfico.

Ocultar rutas eliminadas Oculta las rutas que ya no están presentes en la revisión HEAD del repositorio, por ejemplo ramas eliminadas.

Mostrar la revisión de la copia de trabajo Marca la revisión en el gráfico que corresponde a la revisión de actualización del ítem para el que obtuvo el gráfico. Si acaba de actualizar, esto será HEAD, pero si otros han confirmado cambios desde su última actualización, su copia de trabajo puede estar unas revisiones por debajo. Este nodo se marca dándole un borde remarcado.

Mostrar modificaciones en la copia de trabajo

208

Si su copia de trabajo contiene cambios locales, esta opción lo dibuja como un nodo separado elíptico, enlazado al nodo al que su copia de trabajo fue actualizado por última vez. El color de resalte por defecto es rojo. Puede necesitar refrescar el gráfico utilizando F5 para capturar cambios recientes.

Filtro A veces los gráficos de revisión contienen más revisiones de las que desea ver.

Esta opción abre un diálogo que le permitirá restringir el rango de revisiones mostrado, y ocultar rutas concretas por su nombre.

Usando el gráfico 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

209

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.

Refrescando la vista 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.

Podando árboles 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.

210

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.

Exportando una copia de trabajo de Subversion A veces querrá una copia de su árbol de trabajo sin ninguno de esos directorios .svn, por ejemplo para crear un fichero comprimido de sus fuentes, o para exportarlo a un servidor web. En vez de hacer una copia y borrar todos esos directorios .svn manualmente, TortoiseSVN ofrece el comando TortoiseSVN → Exportar.... Las operaciones exportar desde una URL y exportar desde una copia de trabajo se tratan de forma ligeramente distinta.

Figura 45: El diálogo Exportar-desde-URL Si ejecuta este comando sobre una carpeta sin versionar, TortoiseSVN asumirá que la carpeta de destino es el objetivo, y abrirá un diálogo para que introduzca la URL y la revisión desde la que desea realizar la exportación. Este diálogo tiene opciones para exportar sólo la carpeta de más alto nivel, para omitir las referencias externas, y para obligar un estilo de fin de línea concreto en aquellos ficheros que tuvieran establecida la propiedad svn:eol-style.

Por supuesto también puede exportar directamente desde el repositorio. Utilice el Navegador de repositorios para navegar al subárbol relevante en su repositorio, y luego

211

utilice Menú contextual → Exportar. Obtendrá el diálogo Exportar desde URL descrito más arriba.

Si ejecuta este comando en su copia de trabajo, se le preguntará por el lugar donde guardar la copia de trabajo limpia sin las carpetas .svn. Por defecto, sólo se exportan los ficheros versionados, pero puede utilizar la casilla Exportar también los ficheros o versionados para incluir cualquier otro fichero no versionado que exista en su copia de trabajo y no esté en el repositorio. Las referencias externas utilizando svn:externals pueden omitirse si es necesario.

Otra forma de exportar su copia de trabajo es arrastrar con el botón derecho la carpeta con la copia de trabajo a otro lugar y elegir Menú contextual → SVN Exportar aquí o Menú contextual → SVN Exportar todo aquí. La segunda opción incluirá también los ficheros sin versionar.

Cuando exporte desde una copia de trabajo, si en la carpeta de destino ya existe otra con el nombre de la que está exportando, se le dará la opción de sobreescribir el contenido existente, o de crear una nueva carpeta con un nombre generado automáticamente, por ejemplo, Destino (1).

Exportando ficheros sueltos El diálogo de exportar no permite exporar ficheros sueltos, aunque Subversion puede hacerlo. Para exportar ficheros sueltos con TortoiseSVN, tendrá que utilizar el navegador de respositorios (“El navegador de repositorios”). Simplemente arrastre el o los ficheros que desea exportar desde el navegador de repositorios a donde los desee tener en el explorador, o utilice el menú contextual del navegador de repositorios para exportar los ficheros.

Exportando un árbol de cambios Si quiere exportar una copia de su estructura de árbol del proyecto pero conteniendo sólo los ficheros que han cambiado en una revisión en concreto, o entre dos revisiones, utilice la característica de comparar revisiones descrita en “Comparando carpetas”.

Eliminando una copia de trabajo del control de versiones

212

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 noversionada. Si responde sí, los directorios de control se eliminan y tendrá un simple árbol sin directorios de control.

Relocalizando una copia de trabajo

Figura 46: El diálogo Relocalizar Si su repositorio ha cambiado por algún motivo de lugar (IP/URL); o quizás está estancado y no puede confirmar y no quiere obtener de nuevo su copia de trabajo de la nueva localización y mover todos sus datos cambiados a la copia de trabajo nueva: el comando TortoiseSVN → Relocalizar es lo que está buscando. Básicamente hace muy poco: escanea todos los ficheros entries en las carpetas .svn y cambia la URL de las entradas al nuevo valor.

Puede sorprenderse al ver que TortoiseSVN contacta el repositorio como parte de esta operación. Todo lo que hace es realizar algunas comprobaciones sencillas para asegurarse que la nueva URL realmente se refiere al mismo repositorio que la copia de trabajo existente.

Aviso Esta es una operación que se utiliza realmente poco. El comando relocalizar se utiliza sólo si la URL de la raiz del repositorio ha cambiado. Estas son algunas posibles razones: 

La dirección IP del servidor ha cambiado.

213



El protocolo ha cambiado (por ejemplo, de http:// a https://).



La ruta raíz del repositorio ha cambiado en la configuración del servidor.

De otra forma, necesita relocalizar cuando su copia de trabajo se refiere al mismo lugar en el mismo repositorio, pero es el propio repositorio el que se ha movido.

Esto no se aplica si: 

Quiere moverse a un repositorio de Subversion diferente. En ese caso debería realizar una obtención limpia desde la nueva localización del repositorio.



Quiere cambiar a una rama o a un directorio diferente dentro del mismo repositorio. Para hacer eso debería utilizar TortoiseSVN → Cambiar.... Para más información, lea “Obtener o cambiar...”.

Si utiliza relocalizar en alguno de los casos anteriores, corromperá su copia de trabajo y obtendrá muchos mensajes de error inexplicables cuando actualice, confirme, etc. Una vez que ésto ha ocurrido, el único arreglo es hacer una obtención limpia.

214

ANEXO 4: MANUAL DE USUARIO DE TRAC

215

MANUAL DE USUARIO DE TRAC TracWiki

El wiki es el medio por el cual los desarrolladores se comunican, ingresando de forma textual sus cambios o modificaciones en los códigos o en el sistema en general, informan a los demás sobre cambios relevantes, como creaciones de nuevos módulos o componentes, sobre la creación de una nueva versión, sus características o comparación con la versión anterior.

Para poder editar el wiki, primero deberá loguearse, presionando Login, e ingresando su nombre de usuario y contraseña en el cuadro de diálogo.

WikiFormatting se utiliza en las páginas del wiki, en tickets y en los logs check-in de los mensajes. Esto permite formato de texto y los hipervínculos en Trac y entre todos los módulos.

La edición de texto wiki es fácil, usando cualquier navegador web y un sencillo sistema de formato, y no más complejos lenguajes de marcas como el HTML. El razonamiento detrás de su diseño es que el HTML, con su gran colección de etiquetas nestable, es demasiado complicado para permitir la edición de ritmo rápido, y distrae del contenido real de las páginas. Nota, sin embargo, que también apoya Trac HTML, reStructuredText y textil como alternativa de marcas formatos.

El objetivo principal de la wiki es hacer más fácil la edición de texto y de animar a la gente a contribuir y anote contenido textual para un proyecto.

216

El wiki en sí mismo no garantiza el cumplimiento de cualquier estructura, sino más bien se asemeja a una pila de hojas de papel vacías, donde se puede organizar la información y documentación que estimen conveniente, y más tarde si es necesario reorganizar.

WikiFormatting Wiki markup es un elemento central en Trac, estrechamente integrado en todas las otras partes de Trac en un flexible y poderoso todo.

Trac tiene un compilador en un pequeño y potente motor de renderizado Wiki. Este motor wiki implementa un creciente grupo comando de otros populares Wikis, especialmente MoinMoin Sintaxis disponibles en cualquier parte donde WikiFormattin es permitido: Font Styles El Wiki de Trac soporta los siguientes estilos de fuentes: '''bold''',

'''!'''

can

‘'italic'' '''''bold italic''''' __underline__ {{{monospace}}} or `monospace` ~~strikethrough~~ ^superscript^ ,,subscript,,

Despliega:

bold, ''' can be bold too, and ! italic bold italic underline monospace

or monospace

strike-through superscript subscript

be

bold

too''',

and

'''!

'''

217

Nota: {{{…}}} y `…` son comando que no solo seleccionan una fuente monoespacial, sino que también su contenido como texto verbatim, significa que ninguna otra wiki se procesa en este texto. ! Le dice al parser del wiki que no tome los siguientes caracteres como formato wiki, así que preste atención a los espacios después de !, por ejemplo cuando termina en bold.

Headings Tu puedes crear encabezados, empezando una línea con uno hasta cinco caracteres de igual (“=”) seguidos por un espacio simple y el texto del encabezado. La línea deberá terminar con un espacio seguido por el mismo número de caracteres igual. El encabezado podría opcionalmente ser seguido por un id explícito. Sino, uno implícito pero no obstante un identificador de lectura será generado.

Ejemplo: =

Heading

==

=

Subheading

=== About

==

''this''

=== Explicit

id

===

===

#using-explicit-id-in-heading

Esto despliega:

Heading Subheading About this Explicit id Párrafos Un nuevo texto párrafo es creado cuando dos bloques de texto son separados por una o más líneas vacías.

Un forzado corte de línea puede ser insertado, usando: Line

1[[BR]]Line

2

218

Despliega: Line 1 Line 2 Listas El wiki soporta ambas, ordenadas/numeradas y listas sin ordenar.

Por ejemplo: *

Item *

Item

* *

1 1.1

*

Item

1.1.1

*

Item

1.1.2

*

Item

1.1.3

Item Item

1. Item a.

1.2 2

1 Item

1.a

a.

Item 1.b

i. Item

1.b.i

i. Item

1.b.ii

1. Item

2

Despliega: Item 1 o

Item 1.1 

Item 1.1.1 



Item 1.1.2 

Item 1.1.3 o

Item 1.2

Item 2 1. Item 1 1. Item 1.a 2. Item 1.b 1. Item 1.b.i 2. Item 1.b.ii 2. Item 2

219

Y a las listas numeradas también se les puede dar un número explícito.

3.

Item 3

Note que debe haber uno o más espacios precediendo el listado de los ítems marcados, de otra forma será tratado como un párrafo normal.

Definición de listas La Wiki también soporta definición de listas.

Ejemplo: llama:: some kind of mammal, with hair ppython:: some

kind

of

reptile,

without

hair

(can you spot the typo?)

Note que necesita un espacio en frente de los términos definidos Texto Preformateado Los bloques conteniendo texto preformateado son adecuados para fragmentos de código, notas y ejemplos. Use 3 llaves entre el texto para definir una cuota de bloque. Las llaves deben estar en una línea separada.

Ejemplo: {{{

def HelloWorld(): print "Hello World" }}}

Despliega: def

HelloWorld(): print

"Hello

World"

Bloques de citas Para marcar un párrafo como bloque de cita, escriba el párrafo con dos espacios de margen izquierdo.

Ejemplo: This

text

is

a

quote

from

someone

else.

220

Citaciones de discusión Para delinear una citación en el hilo de una discusión, como en el área de comentarios de los tickets, las marcas de citación como en los correos (“>”,”>>”,etc.) deben ser usados.

Ejemplo: >> Someone's original text > Someone else's reply text My reply text Nota: Algunos elementos del WikiFormating, como lo son las listas y textos preformateados, se pierden en el área de citación. Algún reformateo debe ser necesario para crear una cita clara.

Tablas Simples tablas pueden ser creadas como esto: ||Cell 1||Cell 2||Cell 3|| ||Cell 4||Cell 5||Cell 6||

Despliega:

Cell 1

Cell 2

Cell 3

Cell 4

Cell 5

Cell 6

Note que tablas más complejas pueden ser creadas usando reStructuredText.

Enlaces Los enlaces son creados automáticamente por WikiPageNames y URLs. Los WikiPageLinks pueden ser deshabilitados precediéndolos con una marca de exclamación “!”, como !WikiPageLink.

Ejemplo: TitleIndex,

http://www.edgewall.com/,

Despliega: TitleIndex, http://www.edgewall.com/, NotAlink

!NotAlink

221

Los enlaces pueden dar un título más descriptivo, escribiendo el enlace seguido por un espacio y un título y todo esto dentro de corchetes. Si el título descriptivo es omitido, entonces el prefijo explícito se descarta, a menos que el enlace sea una enlace externo.

Esto puede ser útil para las páginas Wiki no añadidas a la convención de WikiPageNames.

Ejemplo: * [http://www.edgewall.com/ Edgewall * [wiki:TitleIndex Title Index] * [wiki:ISO9000]

Software]

Despliega: Edgewall Software Title Index ISO9000?

Enlaces Trac Las páginas Wiki pueden ser enlazadas directamente a otras partes del sistema de Trac.

Las páginas pueden referirse a tickets, reportes, changesets, milestones, archivos fuente y otras páginas Wiki usando la siguiente notación: * Tickets:

#1

* Reports:

{1}

* Changesets:

or

ticket:1

or r1,

report:1 [1]

or

changeset:1

* ...

Despliega: Tickets: #1 or ticket:1 Reports: {1} or report:1

Changesets: r1, [1] or changeset:1 ...

Hay muchas más formas den enlazar enlaces Trac, vea TracLinks para una información detallada.

Escapando de los enlaces y de WikiPageNames

222

Usted puede evitar marcar enlaces fuera de TracLinks precediendo una expresión con un simple “!” (marca de exclamación).

Ejemplo: !NoHyperLink !#42

is

not

a

link

Despliega: NoHyperLink #42 is not a link Imágenes Las Urls que terminan con .png, .gif o .jpg no son interpretadas automáticamente como enlaces de imágenes, y convertidas a <img> tags.

Ahora usted tiene que usar la [[Image]] macro. El forma más simple de incluir una imagen es subiéndola como un adjunto a la presente página, y ponerle un nombre en un macro llamado [[Image(picture.gif)]] En adición a la presente página, es posible referirse a otros recursos: [[Image(wiki:WikiFormatting:picture.gif)]]

(referring to attachment on

another page) [[Image(ticket:1:picture.gif)]] [[Image(htdocs:picture.gif)]]

(file attached to a ticket)

(referring to a file inside project htdocs)

[[Image(source:/trunk/trac/htdocs/trac_logo_mini.png

Ejemplo despliega:

Vea WikiMacros para documentación adicional en la [[Image()]] macro.

Macros Las macros son funciones personalizadas para insertar contenido dinámico en una página.

Ejemplo: [[RecentChanges(Trac,3)]]

223

Despliega: 11/07/2009 TracRoadmap TracRss TracSearch Vea WikiMacros para mรกs informaciรณn, y una lista de las macros instaladas.

Procesadores Trac soporta formatos de marcado alternativo usando WikiProcessors. Por ejemplo, procesos que son usados para escribir pรกginas en reStructuredText o HTML Ejemplo 1: {{{ #!html <h1

style="text-align:

right;

color:

blue">HTML

Test</h1>

}}}

Despliega:

HTML Test Ejemplo: {{{ #!python class Test: def __init__(self): print "Hello World" if __name__ == '__main__': Test() }}} Despliega: class

Test: def __init__(self): print "Hello World" if __name__ == '__main__': Test()

Perl: my ($test) = 0; if ($test > 0) { print }

"hello";

224

Vea WikiProcessors para más información.

Comentarios Los comentarios pueden ser añadidos al texto plano. Esto podría no ser prestados y podría no desplegar en ningún otro formato que en texto plano. {{{ #!comment Your

comment

here

}}} Miscelánea Cuatro o más guiones pueden ser reemplazados por una línea horizontal (<HR>) Ejemplo: --Despliega:

Wiki Page Names Los nombres de las páginas Wiki comúnmente usan las convención CamelCase. Con el texto wiki, cualquier palabra en CamelCase se convierte automáticamente en un enlace hacia una página wiki con ese nombre.

Las páginas con nombre CamelCase deben seguir estas reglas: El nombre debe consistir sólo de caracteres alfabéticos. Los dígitos, espacios, puntuación o guiones bajos no son permitidos.

Un nombre debe tener al menos dos letras capitales.

El primer carácter debe ser capitalizado.

Cada letra capital debe ser seguida por una o más letras minúsculas.

El uso del slash ( / ) es permitido en nombres de páginas (posiblemente para representar un jerarquía.

Si usted quiere crear una página wiki que no siga las reglas CamelCase, usted puede usar la siguiente sintaxis: * [wiki:Wiki_page],

[wiki:ISO9000]

225

* [wiki:"Space characters

Matters"]

that

* or simply: ["WikiPageName"]s free links style)

page

name

(!MoinMoin's

embeds

space

internal

Esto será renderizado como: Wiki_page?, ISO9000?

Space Matters? that page name embeds space characters or simply: WikiPageName?s (MoinMoin's internal free links style) Comenzando con Trac 0.11, esto es también posible para enlaces a una versión específica de una página Wiki, como podrías hacerlo para una versión específica de un archivo, por ejemplo: WikiStart@1 Finalmente, uno también puede añadir un ancla a un nombre de página Wiki, en orden para especificar un enlace a una sección con la página. El ancla puede ser fácilmente visto pasando el cursor sobre la cabecera, luego cliqueando en el signo ¶ que aparecen al final de este. El ancla es usualmente generada automáticamente, pero también se la puede especificar explícitamente.

Pasos para añadir una nueva página Wiki 1. Elegir un nombre para tu nueva página. Vea WikiPageNames para la convención de nombramientos.

2. Editar una página Existente (o cualquier otro recurso que soporte WikiFormating y añada un enlace a su nueva página. Guarde los cambios.

3. Siga el enlace que ha creado para que lo lleve a la nueva página. Trac desplegará un mensaje de “Describa Nombre de página aquí” 4. Clic en el botón “Editar esta página” para editar y añadir el contenido de su nueva página. Guarde los cambios.

5. Todo hecho. Su nueva página será publicada.

Usted puede saltarse del segundo paso ingresando un nombre CamelCase de la página, en el campo de búsqueda en la parte superior de la página. Pero note que la página podría efectivamente ser “huérfana” a menos que la enlace a algún lugar.

Trac Links

226

TracLinks son una propiedad fundamental de Trac, porque permiten fácil enlaces entre varias entidades en el sistema como lo son: tickets, reportes, changsets, páginas Wiki, hitos, y archivos fuentes, donde sea que WikiFormating sea usado.

TracLinks son generalmente de la forma type:id (donde id representa el número, nombre o dirección del elemento) aunque algunos elementos utilizados con frecuencia también tienen cortas anotaciones a mano.

Dónde usar TracLinks Usted puede usar TracLinks en: Código fuente (Subversion) mensajes commit Páginas Wiki Descripciones completas para tickets, reportes e hitos Y cualquier otro campo de texto donde se marque explícitamente soporte de WikiFormating Algunos ejemplos: Tickets: #1 or ticket:1 Ticket comments: comment:1:ticket:2 Reports: {1} or report:1

Changesets: r1, [1], changeset:1 or (restricted) [1/trunk], changeset:1/trunk Revision log: r1:3, [1:3] or log:@1:3, log:trunk@1:3, [2:5/trunk] Diffs (requires 0.10): diff:@1:3, diff:tags/trac-0.9.2/wiki-default//tags/trac0.9.3/wiki-default or diff:trunk/trac@3538//sandbox/vc-refactoring@3539 Wiki pages: CamelCase or wiki:CamelCase attachment:attachment.1073.diff:ticket:944 Parent page: [..]

Milestones: milestone:1.0 Attachment: attachment:example.tgz (for current page attachment), (direcciones absolutas) A specific file revision: source:/trunk/COPYING@200 Files: source:trunk/COPYING A particular line of a specific file revision: source:/trunk/COPYING@200#L25 Despliega:

227

Tickets: #1 or ticket:1 Ticket comments: comment:1:ticket:2 Reports: {1} or report:1 Changesets: r1, [1], changeset:1 or (restricted) [1/trunk], changeset:1/trunk Revision log: r1:3, [1:3] or log:@1:3, log:trunk@1:3, [2:5/trunk] Diffs (requires 0.10): 0.9.3/wiki-default or

diff:@1:3,

diff:tags/trac-0.9.2/wiki-default//tags/trac-

diff:trunk/trac@3538//sandbox/vc-refactoring@3539 Wiki

pages: CamelCase or wiki:CamelCase Parent page: .. Milestones: milestone:1.0 Attachment:

attachment:example.tgz

(for

current

page

attachment),

attachment:attachment.1073.diff:ticket:944(direcciones absolutas) Files: source:trunk/COPYING A specific file revision: source:/trunk/COPYING@200 A particular line of a specific file revision: source:/trunk/COPYING@200#L25 Nota: La forma wiki:CamelCase es raramente usada, pero puede ser conveniente referirse a páginas cuyos nombres no sigan las reglas WikiPageNames, por ejemplo: palabras simples, caracteres no alfabéticos, etc. Vea WikiPageNames para más especificaciones a enlaces de nombres de página Wiki A los enlaces de Trac que usan anotaciones completas se les puede dar un título personal como este: [ticket:1

This

is

a

link

to

ticket

number

one].

Si el título es omitido, sólo el id (la parte después de los dos puntos) es desplegada: [ticket:1] Wiki es por defecto el nombre de espacio parte del enlace completo es omitido: [SandBox

the

sandbox]

TracLinks son una muy simple idea, pero actualmente permiten bastante una compleja rede de información. In la práctica, es muy intuitiva y simple de usar, y se ha encontrado a las pistas de enlces extremadamente útil para un mejor entendimiento de lo que está pasando en un proyecto o del porqué un cambio en particular fue realizado.

228

Uso avanzado de los TracLinks Enlaces Relativos Para crear un enlace a un ancla específico en una página, use „#‟: [#Relativelinks

relative

links]

Sugerencia: Cuando mueves el cursor sobre el título de una sección, un „¶‟ carácter será desplegado. Este es un enlace para una sección específica y puedes usar esto para copiar el #... de la parte de adentro de un enlace relativo a un ancla.

Para crear un enlace a una página SubWiki sólo usa un „/‟: WikiPage/SubWikiPage or ./SubWikiPage Para un enlace desde una página SubWiki a una anterior, simplemente usa un „..‟: [..]

Para enlazar desde una página SubWiki a una página hermana, usa un „../‟: [../Sibling see next sibling] Enlaces InterWiki Otros prefijos se pueden definir libremente y hacerlos apuntar a recursos en otras aplicaciones Web. La definición de los prefijos, así como las URL de las aplicaciones Web correspondientes se define en una página especial del wiki, la página de InterMapTxt. Tenga en cuenta que, si bien esto podría ser usado para crear enlaces a otros entornos de Trac, hay una manera más especializada para registrar otros entornos Trac, que ofrece una mayor flexibilidad.

Enlaces InterTrac Esto puede ser visto como una especie de vínculo InterWiki especializado para la captura de otros proyectos Trac.

Cualquier tipo de vínculos Trac puede ser escrito en un entorno de Trac y en realidad se refieren a los recursos presentes en otro entorno de Trac, siempre que el vínculo Trac sea el prefijo del nombre de ese entorno otro Trac seguido de dos puntos. Ese otro entorno Trac debe estar registrado, con su nombre o un alias. Vea Intertrac para más detalles.

229

Una ventaja distintiva de los vínculos a través de vínculos Intertrac InterWiki es que la forma abreviada de los vínculos Trac suelen tener una forma de entender los prefijos Intertrac. Por ejemplo, los enlaces a las entradas para Trac puede escribir #T234 (si T se estableció como un alias para Trac), los enlaces a cambios de Trac pueden ser escrito como [trac 1508] Enlaces de servidor relativos A menudo es útil para poder enlazar a los objetos de su proyecto que no tienen incorporado en Trac un mecanismo de vinculación, como en los recursos estáticos, newticket, una compartida / registrada página en el servidor, etc.

Para vincular a los recursos dentro del proyecto, utilice una ruta absoluta desde la raíz del proyecto, o un vínculo relativo de la URL de la página actual (cambio de 0,11): [/newticket Create a new ticket] [/ home] Para vincular a otra ubicación en el servidor (fuera del proyecto), use la sintaxis de enlace „//location‟: [//register

Register

Here]

Citando el espacio en TracLinks Inmediatamente después de un prefijo TracLinks, los objetivos que contiene caracteres de espacio deben ser encerrados en un par de citas o comillas dobles. Ejemplos:

wiki:"The whitespace convention" attachment:'the file.txt' or attachment:"the file.txt" attachment:"the file.txt:ticket:123" Escapar de Enlaces Para evitar análisis de un TracLink, puede escapar de ella precediéndolo con un "!"

(Signo de exclamación). !NoLinkHere. ![42]

is

not

a

Vínculos Trac parametrizados

link

either.

230

Los vínculos Trac canalizan los recursos Trac que tienen en general más de una forma de ser prestados, de acuerdo a algunos parámetros extra. Por ejemplo, una página Wiki puede aceptar una versión o un parámetro de formato, un informe puede hacer uso de variables dinámicas, etc.

Cualquier enlace Trac puede soportar un conjunto arbitrario de parámetros, escritos de la misma manera de como lo sería para la URL correspondiente. Algunos ejemplos: wiki:WikiStart?format=txt ticket:1?version=1 [/newticket?component=module1 create a ticket for module1] Referencia de TracLinks Las siguientes secciones describen los tipos de vínculos individuales en detalle, así como varias notas avanzadas del uso de los enlaces.

Archivo adjunto: Enlaces La sintaxis de los vínculos de los archivos adjuntos es el siguiente: attachment:the_file.txt creates a link to the attachment the_file.txt of the current object attachment:the_file.txt:wiki:MyPage creates a link to the attachment the_file.txt of the MyPage wiki page attachment:the_file.txt:ticket:753 creates a link to the attachment the_file.txt of the ticket 753 Tenga en cuenta que la vieja forma, poniendo el nombre de archivo al final, aún se puede utilizar: attachment: ticket: 753: the_file.txt.

Si desea crear un vínculo directo al contenido del archivo adjunto en lugar de un enlace a la página de archivo adjunto, simplemente utilice raw-attachment: en lugar de attachment:.

Esto puede ser útil para señalar directamente a un documento HTML, por ejemplo. Tenga en cuenta que para este caso de uso, usted tendría que permitir que el navegador web para

representar

el

contenido

mediante

el

establecimiento

de

[attachment]

render_unsafe_content = yes (véase en el TracIni#attachment-section). Advertencia: sólo que en los ambientes y para que esté 100% seguro de que puede confiar en las personas

231

que son capaces de adjuntar archivos, de lo contrario se abriría su sitio a ataques de cross-site scripting.

Comentario: Enlaces Cuando estás dentro de determinados tickets, sólo tienes que escribir, por ejemplo comment:3 para vincular a la observación del tercer cambio. También es posible vincular a un comentario de un ticket específico desde cualquier lugar utilizando una de las siguientes sintaxis: comment:3:ticket:123 ticket:123#comment:3 (note that you can't write #123#comment:3!)

Ticket: Enlaces Además de la obvia forma ticket:id, también es posible especificar una lista de tickets o incluso una serie de tickets en lugar de la ID. Esto genera un vínculo a una vista de consulta personalizada que contiene este conjunto fijo de tickets.

Ejemplo: ticket:5000-6000 ticket:1,150 Timeline: Enlaces Los enlaces a la línea de tiempo se pueden crear mediante la especificación de una fecha en el formato de la norma ISO: 8601. La fecha puede ser opcionalmente seguida por una especificación de tiempo. El tiempo se interpreta como hora UTC, pero también, puede especificar la hora local, seguido de su zona horaria, si no quiere calcular el tiempo UTC. Ejemplos: timeline:2008-01-29 timeline:2008-01-29T15:48 timeline:2008-01-29T16:48Z+01 Enlaces relacionados con el control de versiones Fuente: Enlaces

232

El comportamiento por defecto de una ruta de enlace source:/some/path es abrir el navegador de directorios si la ruta apunta a un directorio y de lo contrario abre la vista de registro.

También es posible enlazar directamente a una revisión específica de un fichero como este: source:/some/file@123 - link to the file's revision 123 source:/some/file@head - link explicitly to the latest revision of the file Si no se especifica la revisión, incluso se puede vincular a un número de línea concreto: source:/some/file@123#L10 source:/tag/0.10@head#L10 Por último, también se puede resaltar un conjunto arbitrario de líneas: source:/some/file@123:10-20,100,103#L99 - highlight lines 10 to 20, and lines 100 and 103. export: Enlaces Para forzar la descarga de un archivo en el repositorio, en lugar de mostrarlo en el navegador, utiliza el enlace de export. Existen varias formas: export:/some/file - get the HEAD revision of the specified file export:123:/some/file - get revision 123 of the specified file export:/some/file@123 - get revision 123 of the specified file Esto puede ser muy útil para mostrar la documentación XML o HTML con hojas de estilo correcto y las imágenes, en caso de que se ha comprobado en el repositorio. Tenga en cuenta que para este caso de uso, habría que permitir que el navegador web para representar el contenido mediante el establecimiento de [browser] render_unsafe_content = yes (véase TracIni#browser-section), de lo contrario Trac obligará a los archivos para ser descargados como archivos adjuntos por asuntos de seguridad.

Si la ruta es un directorio en el repositorio en lugar de un archivo específico, el navegador de código se utiliza para mostrar el directorio (idéntico al resultado de source:/some/dir). log: Enlaces

233

Los log: links se utilizan para mostrar rangos de revisión. En su forma más simple, se puede enlazar con las últimas revisiones de la ruta especificada, pero también puede mostrar apoyo a un conjunto arbitrario de las revisiones. log:/ - the latest revisions starting at the root of the repository log:/trunk/tools - the latest revisions in trunk/tools log:/trunk/tools@10000 - the revisions in trunk/tools starting from revision 10000 log:@20788,20791:20795 - list revision 20788 and the 20791 to 20795 revision range log:/trunk/tools@20788,20791:20795 - list revision 20788 and the revisions from the 20791 to 20795 range which affect the given path Hay formas cortas para los rangos de revisión, como estos: [20788,20791:20795] [20788,20791:20795/trunk/tools] r20791:20795 (but not r20788,20791:20795 nor r20791:20795/trunk) Por último, note que en todas las anteriores, un rango de revisiones se pueden escribir indiferentemente x:y o x-y.

Trac Macros Las Macros de Trac son plugins para ampliar el motor de Trac con funciones personalizadas escritos en Python. Una macro inserta HTML dinámico de datos en cualquier contexto de apoyo WikiFormatting.

Otro tipo de macros son WikiProcessors. Por lo general, con los formatos de marcado alternativos y la representación de grandes bloques de información (como el código fuente a colores).

Usando Macros Las llamadas a Macros están encerrados en dos corchetes. Al igual que las funciones de Python, las macros también pueden tener argumentos, una lista separada por comas y entre paréntesis.

Las Macros de Trac también pueden ser escritas como TracPlugins. Esto les da algunas capacidades que las macros no tienen, tales como poder acceder directamente a la petición HTTP. Ejemplo

234

Una lista de los 3 más recientemente cambiaron de páginas wiki que comienzan con 'Trac': [[RecentChanges(Trac,3)]] Macros Disponibles Tenga en cuenta que la siguiente lista sólo incluirá la documentación de la macro si no ha habilitado optimizaciones -OO, o no ha establecido la opción de PythonOptimize para mod_python. [[InterTrac]] Proporcionar una lista de prefijos conocidos Intertrac. [[TitleIndex]] Inserta una lista alfabética de todas las páginas wiki en la salida.

Acepta una cadena de prefijo como parámetro: si la hay, sólo las páginas con nombres que comienzan con el prefijo se incluyen en la lista resultante. Si se omite este parámetro, se enumeran todas las páginas.

Formato diferente y la profundidad puede ser especificado: format=group: La lista de páginas se estructurarán en grupos de acuerdo a un prefijo común. Este formato también admite un argumento min = n, donde n es el número mínimo de páginas para un grupo. depth=n: Limita la profundidad de las páginas a la lista. Si se pone a 0, sólo las páginas de nivel superior se verán, si se establece en 1, sólo los hijos inmediatos de las páginas se mostrarán, etc Si no se establece o se establece en -1, todas las páginas en la jerarquía se muestran. [[RecentChanges]] Lista todas las páginas que han sido recientemente modificadas, agrupándolas por el día de la última modificación.

235

Esta macro acepta dos parámetros. La primera es una cadena de prefijo: si la hay, sólo las páginas con nombres que comienzan con el prefijo se incluyen en la lista resultante.

Si se omite este parámetro, se enumeran todas las páginas.

El segundo parámetro es un número para limitar el número de páginas devueltas. Por ejemplo, si se especifica un límite de 5 dará como resultado sólo las cinco páginas más recientemente modificadas para ser incluidas en la lista. [[PageOutline]] Muestra un esquema estructural de la página wiki actual, cada elemento en el esquema ha de ser un enlace al titular correspondiente.

Esta macro acepta tres parámetros opcionales: El primero es un número o rango que permite configurar el nivel mínimo y máximo de las cabeceras que deben incluirse en el esquema. Por ejemplo, especificando "1" aquí resultan sólo el nivel superior de las cabeceras que están incluidas en el esquema. Especificando "2-3" hará que el esquema incluya todos los títulos de nivel 2 y 3, como una lista anidada. El valor predeterminado es incluir a todos los niveles de partida.

El segundo parámetro se puede utilizar para especificar un título personalizado (el valor predeterminado es sin título).

El tercer parámetro selecciona el estilo del esquema. Esto puede ser en línea o retirada (esta última es la opción predeterminada). El estilo en línea hace el esquema como parte normal del contenido, mientras que la retirada de las causas del contorno para ser mostrado en una caja que está por defecto flotado en el lado derecho del otro contenido. [[Image]] Inserta una imagen en texto con formato wiki.

El primer argumento es la especificación de archivo. La especificación de los archivos adjuntos se referenciará de tres formas: module:id:file, donde los módulos pueden ser wiki o ticket, para referirse al nombre del archivo adjunto de la página wiki especificada o ticket.

236

id:file: lo mismo que lo anterior, pero el id es una abreviatura de ticket o el nombre de una página Wiki. file para referirse a un archivo adjunto local llamado 'archivo'. Esto sólo funciona dentro de la página wiki o ticket.

Además, la especificación de archivo puede hacer referencia a los archivos del repositorio, utilizando la sintáxis source:file (source:file@rev también funciona).

Los archivos también se puede acceder con un URL directo; /archivo de un proyecto relativo, //archivo de un servidor-relativa o absoluta http://server/file para la ubicación del archivo.

El resto de argumentos son opcionales y permiten la configuración de los atributos y el estilo del elemento prestados <img>: Dígitos y unidades se interpretan como el tamaño (por ejemplo, 120, 25%) para la imagen right, left, top o bottom se interpretan como la alineación de la imagen link= algunos TracLinks ... reemplaza el vínculo con el origen de la imagen por el que se indica mediante un TracLinks. Si no se especifica ningún valor, el enlace es simplemente eliminado. nolink significa sin enlace a la fuente de imagen (obsoleto, use link=) key=valor estilos se interpretan como atributos HTML o indicaciones de estilo CSS para la imagen. Las claves válidas son: align, border, width, height, alt, title, longdesc, class, id y usemap border sólo puede ser un número  Ejemplos: [[Image(photo.jpg)]]

# el más simple

[[Image(photo.jpg, 120px)]]

# con ancho de imagen

[[Image(photo.jpg, right)]]

# alineado por keywords

[[Image(photo.jpg, nolink)]]

# sin enlace a la fuente

[[Image(photo.jpg, align=right)]]

# alineado por atributos

Usted puede utilizar la imagen de otra página, otro ticket u otro módulo. [[Image(OtherPage:foo.bmp)]]

# si el módulo actual es una wiki

[[Image(base/sub:bar.bmp)]]

# de la página wiki jerárquica

[[Image(#3:baz.bmp)]]

# si en un ticket, apunta al #3

[[Image(ticket:36:boo.jpg)]]

237

[[Image(source:/images/bee.jpg)]] # directamente desde el repositorio! [[Image(htdocs:foo/bar.png)]] # archivo de imagen en el htdocs [[MacroList]] Muestra una lista de todas las macros instaladas Wiki, incluida la documentaciรณn si es posible.

Opcionalmente, el nombre de una macro especรญfica se puede proporcionar como un argumento. En ese caso, sรณlo se muestra la documentaciรณn de la macro.

Tenga en cuenta que esta macro no serรก capaz de mostrar la documentaciรณn de las macros PythonOptimize si la opciรณn estรก habilitada para mod_python! [[TracIni]] Produce la documentaciรณn para el archivo de configuraciรณn de Trac.

Normalmente, este serรก utilizado en la pรกgina TracIni. Los argumentos opcionales son un filtro de la secciรณn de configuraciรณn, y una opciรณn de configuraciรณn del nombre de filtro: sรณlo las opciones de configuraciรณn, cuya secciรณn y nombres comienzan con el filtro son salidas. [[TracGuideToc]] Esta macro muestra un modo rรกpido y sucio para hacer una tabla de contenidos para un conjunto de pรกginas wiki. [[TicketQuery]] Macro que lista tickets que cumplan ciertos criterios.

Esta macro acepta una lista separada por comas de los parรกmetros introducidos, en la forma "clave = valor".

Si la clave es el nombre de un campo, el valor debe utilizar la sintaxis de una especificaciรณn de filtro como se define en TracQuery#QueryLanguage. Tenga en cuenta que esto no es lo mismo que la simplificada sintaxis de URL utilizado para la consulta: los vรญnculos a partir de un carรกcter ?.

238

Además de los filtros, varios otros nombrados parámetros se pueden utilizar para controlar cómo se presentan los resultados. Todos ellos son opcionales.

El parámetro de formato determina cómo se presenta la lista de tickets: list -- la presentación por defecto es para listar los tickets de identificación al lado del resumen, con cada ticket en una línea distinta. compact -- los tickets se presentan como una lista separada por comas de identificadores de tickets. count -- sólo se muestra la cuenta de tickets coincidentes table -- una vista similar a la vista de consulta personalizada (pero sin los controles) El parámetro max se puede utilizar para limitar el número de tickets a mostrar (por defecto 0, es decir, no como máximo).

El parámetro order establece el campo utilizado para reservar tickets (por defecto es id).

El parámetro desc indica si el orden de los tickets deben ser invertidos (por defecto a false).

El parámetro group establece el campo utilizado para agrupación de tickets (por defecto no está establecido).

El parámetro groupdesc indica si el orden de presentación natural de los grupos deben ser invertido (por defecto es false).

El parámetro verbose puede establecer un valor verdadero a fin de obtener la descripción de los tickets en la lista. Para el formato de tabla solamente, obsoleto en los parámetros de las filas.

El parámetro rows se puede utilizar para especificar qué campo(s) deben ser visto como una fila, por ejemplo, rows=description | summary [[TracAdminHelp]] Muestra ayuda para los comandos trac-admin

239

Ejemplo: [[TracAdminHelp]] # todos los comandos [[TracAdminHelp(wiki)]] # todos los comandos del wiki [[TracAdminHelp(wiki export)]] # los comandos de exportación wiki [[TracAdminHelp(upgrade)]] # los comandos de actualización

Macros de todo el mundo El sitio Trac Hacks (http://trac-hacks.org) proporciona una amplia colección de macros y otros plugins de Trac aportados por la comunidad Trac. Si usted está buscando nuevas macros, o ha escrito una y le gustaría compartir con el mundo, por favor no dude en visitar ese sitio.

El desarrollo de macros personalizados Las macros, como el mismo Trac, están escritas en el lenguaje de programación Python.

Para obtener más información sobre el desarrollo de macros, consulte el desarrollo de los recursos en el sitio principal del proyecto. http://trac.edgewall.org/intertrac/TracDev Aplicación Éstos son 2 ejemplos sencillos que muestran cómo crear una macro con Trac 0,11.

Además, un vistazo a Timestamp.py para un ejemplo que muestra la diferencia entre el estilo antiguo y nuevo estilo de macros y en macros/README se proporciona una visión algo más profunda sobre la transición.

Macro sin argumentos Debe ser guardado como TimeStamp.py porque Trac usará el nombre del módulo como el nombre de macro. from #

datetime

Note:

since

import Trac

datetime 0.11,

datetime

internally from

genshi.builder

import

tag

objects

are

used

240

from trac.util.datefmt import format_datetime, utc from trac.wiki.macros import WikiMacroBase class

TimeStampMacro(WikiMacroBase):

"""Inserts wiki

the

current

time

(in

seconds)

into

the

page."""

revision = "$Rev$" url = "$URL$" def expand_macro(self, formatter, name, args): t = datetime.now(utc) return

tag.b(format_datetime(t,

'%c'))

Macro con argumentos Debe ser guardado como HelloWorld.py (en el directorio plugins /) ya que Trac usar谩 el nombre del m贸dulo como el nombre de macro. from

trac.wiki.macros

class

it

HelloWorld

that

must

what

WikiMacroBase

HelloWorldMacro(WikiMacroBase):

"""Simple Note

import

the

end

comes

name

macro. of

the

with

"Macro"

before

"Macro"

class

ends

is

up

meaningful:

being

the

macro

name The documentation of the class (i.e. what you're reading) will become the documentation of the macro, as shown by the !MacroList macro (usually used in the WikiMacros page). """ revision = "$Rev$" url = "$URL$" def

expand_macro(self,

formatter,

name,

args):

"""Return some output that will be displayed in the Wiki content. `name` is the actual name of the macro (no surprise, here it'll be `'HelloWorld'`), `args` call

is

of

the

text

enclosed

in

parenthesis

at

the

the

macro.

Note that if there are ''no'' parenthesis (like in, e.g. [[HelloWorld]]), then `args` is `None`.

241

""" return Note

'Hello

that

returned as

the

World,

there's

args

no

need

=

'

to

+

unicode(args)

HTML

escape

the

data, template

engine

(Genshi)

will

do

it

for

us.

Detalles expand_macro expand_macro debe retornar una cadena Python simple que será interpretada como HTML, o, preferiblemente, un objeto de marcado (uso de trac.util.html importación de marcado). El marcado (cadena) sólo anota la cadena para que el procesador devuelva la cadena HTML tal cual, sin escapar. Usted también tendrá que importar Formatter utilizando de importación trac.wiki Formatter.

Si la macro crea el formato wiki en lugar de HTML, usted puede convertir a HTML así: text

=

"whatever

containing

other

wiki

markup

you

want,

even

macros"

# Convert Wiki markup to HTML, new style out = StringIO() Formatter(self.env, formatter.context).format(text, out) return Markup(out.getvalue()) WikiProcessors Los procesadores se WikiMacros diseñado para proporcionar formatos de marcas alternativas para el motor de Wiki. Los procesadores pueden ser considerados como funciones de macro para procesar texto editado por el usuario.

El motor de Wiki utiliza procesadores para permitir el uso de Restructured Text, raw HTML y textile en cualquier texto de Wiki en Trac.

El uso de procesadores Para utilizar un procesador en un bloque de texto, utilice un bloque de código Wiki, seleccionando un procesador por nombre usando la notación de Shebang (#!), familiar para la mayoría de los usuarios de UNIX a partir de scripts.

Ejemplo 1 (inserción de HTML puro en un texto wiki): {{{ #!html

242

<h1

style="color:

orange">This

is

raw

HTML</h1>

}}}

Tenga en cuenta que desde la versión 0.11, estos bloques de HTML tienen que ser autónomo, es decir, no se puede iniciar un elemento HTML en un solo bloque y cerrar más tarde en un segundo bloque. Utilice los procesadores div o span para lograr un efecto similar.

Ejemplo 2 (Ingresando Texto reestructurado en un texto wiki) {{{ #!rst A

header

-------This ..

is [*]

some This

**text** is

the

with

a

footnote

[*]_.

footnote.

}}}

Ejemplo 3 (Ingresando un bloque de código C en el texto wiki) {{{ #!c int

main(int

argc,

char

*argv[])

{ printf("Hello World\n"); return 0; } }}}

Procesadores disponibles Los siguientes procesadores están incluidos en la distribución del TRAC: html – Ingresa HTML personalizado en una página wiki. div -- Envuelve un contenido de Wiki arbitraria en un elemento <div> span -Envuelve un contenido de Wiki arbitraria en un elemento <span> rst – Soporte Trac para Texto Reestructurado. textile – Soportado si textile está instalado. comment -- No procesa el texto en esta sección (es decir, el contenido sólo existen en el texto - no en la página renderizada).

Soporte para código destacado

243

Trac incluye los procesadores para proporcionar la sintaxis de línea que destaca para los siguientes lenguajes: c -- C cpp -- C++ python - Python perl -- Perl ruby -- Ruby php -- PHP asp -ASP java -- Java js -- Javascript sql -- SQL xml -XML sh -- Bourne/Bash shell Nota: Trac se basa en los paquetes de software externo para coloreado de sintaxis. Ver TracSyntaxColoring para más información.

Al utilizar el tipo MIME del procesador, es posible resaltar la sintaxis en los mismos idiomas que se admiten cuando se navega código fuente. Por ejemplo, puede escribir: {{{ #!text/ht ml <h1>text< /h1>

}}}

El resultado será sintaxis de código HTML resaltado: <h1>text</h1> Lo mismo es válido para todos los otros tipos MIME soportados.

Para obtener más procesador macros desarrollados y / o aportado por los usuarios, visite: http://trac.edgewall.org/intertrac/ProcessorBazaar (trac:ProcessorBazaar) http://trac.edgewall.org/intertrac/MacroBazaar (trac:MacroBazzar) Temas avanzados: Desarrollo de procesador de macros

244

El desarrollo de procesadores no es diferente de macros Wiki. De hecho, funcionan de la misma manera, sólo que la sintaxis de uso es diferente. Vea WikiMacros para más información.

Wiki Page Templates El contenido por defecto para una nueva página wiki se puede elegir de una lista de plantillas de página.

Esta lista se compone de todas las páginas wiki que comienzan con un nombre que comienza con PageTemplates/. El contenido inicial de una nueva página será simplemente el contenido de la plantilla seleccionada o una página en blanco si se selecciona la especial (página en blanco) de entrada. Cuando no hay en realidad, páginas wiki similares a la del prefijo, el contenido inicial será siempre la página en blanco y el selector de lista no se muestra (es decir, esto coincide con el comportamiento que tenían hasta ahora).

Para crear una nueva plantilla, basta con crear una nueva página con un nombre que comienza con PageTemplates/.

(Sugerencia: se podría incluso crear un PageTemplates/Template para facilitar la creación de nuevas plantillas!)

TracTimeline

La línea de tiempo ofrece una visión histórica del proyecto en un único informe.

245

En ella se enumeran todos los eventos Trac que se han producido en orden cronológico, una breve descripción de cada evento y en su caso, la persona responsable del cambio.

La línea de tiempo lista este tipo de eventos: Wiki page events – Creación y cambios Ticket events – Creación y resolución/cerrados (y opcionalmente otros cambios) Source code changes – Chequeos en el repositorio Milestone – Hitos completados Cada entrada de evento proporciona un enlace al evento en cuestión, así como un breve extracto de la observación real o texto, si está disponible.

Opciones del TracIni para la configuración de la línea de tiempo. [timeline]

abbreviated_messages

Si

wiki-mensajes

ser reducido

o

de no.

sucesos Esto

sólo

formato afecta

debe a

la

prestación por defecto, y puede ser anulado por los proveedores de eventos específicos. changeset_collapse_events

Ya

sea

de

cambios

sucesivos a

partir

del

mismo autor, que tiene exactamente el mismo mensaje debe ser presentado como un evento.

Este evento unirá a la gama de conjuntos de cambios en la vista de registro.

Si los mensajes en formato wiki de cambios changeset_long_messages

deben ser multilínea o no. Si esta opción no se especifica o es falso y se establece en wiki_format_messages verdadera, los mensajes de cambios estará solo, perdiendo parte del formato (viñetas, etc.)

Número de archivos para

changeset_show_files

mostrar (-1 para un

número ilimitado, 0 para deshabilitar). Esto también puede ser la ubicación, para mostrar el prefijo común para los archivos modificados.

246

Número predeterminado de días que aparece en default_daysback

la línea de tiempo, en días.

El

max_daysback

número

máximo

de

días

(-1

para

un

número ilimitado) que se puede mostrar en la línea de tiempo.

newticket_formatter

¿Qué

formateador

desea

(por

ejemplo,

'html'

o 'oneliner') para ser utilizado en la

presentación de la descripción de los tickets nuevos. Si es 'oneliner', la [timeline] opción de abreviación de mensajes se aplica Habilita la visualización de todos los cambios ticket_show_details

en los tickets en la línea de tiempo, no sólo operaciones de abrir/cerrar.

Soporte RSS El módulo Timeline soporta suscripción a través de sindicación RSS 2.0. Para suscribirse a los eventos del proyecto, haga clic en el icono XML de color naranja en la parte inferior de la página.

TracRss Varios de los módulos de Trac soportan la sindicación de contenidos mediante el RSS (Really Simple Syndication) el formato XML. Usando la función de suscripción RSS en Trac, usted puede fácilmente controlar el progreso del proyecto, un conjunto de incidencias o incluso los cambios en un único archivo.

Trac soporta RSS en: 

TracTimeline - Utilice el feed RSS para suscribirse a los eventos del proyecto.

Supervise el progreso general del proyecto en su lector de RSS favorito.



TracTickets, TracReports, y TracQuery - Permite la sindicación de informes y resultados sobre consultas de tickets.



Sea notificado acerca de incidencias importantes y relevantes en los tickets.

TracBrowser y TracRevisionLog - Sindicación de los cambios de archivo.

Manténgase al día con los cambios en un determinado archivo o directorio.

247

¿Cómo acceder a los datos RSS? En cualquier en Trac en donde RSS esté disponible, usted debe encontrar un pequeño icono naranja XML, normalmente se colocan en la parte inferior de la página. Al hacer clic en el icono tendrá acceso a la fuente RSS de ese recurso específico.

Nota: Los distintos módulos proporcionan datos diferentes en sus feeds RSS. Por lo general, la información sindicada, corresponde a la vista actual. Por ejemplo, si hace clic en el enlace RSS en una página de informe, la alimentación se basará en ese informe.

Podría explicarse por el pensamiento de la RSS como una visión alternativa de los datos que se muestran actualmente.

Enlaces



http://blogs.law.harvard.edu/tech/rss - RSS 2.0 Specification



http://www.mozilla.org/products/firefox/ - Mozilla Firefox compatible con los marcadores en vivo mediante RSS



http://sage.mozdev.org - Sage agregador de feeds RSS y Atom para Mozilla Firefox



http://pim.kde.org/users.php - KDE lector de RSS para Linux / BSD / * n * x sistemas



http://www.rssreader.com/ - libre y poderoso lector de RSS para Windows



http://liferea.sourceforge.net/ - Open source GTK2 lector de RSS para Linux



http://akregator.sourceforge.net/ - Open source KDE RSS Reader (parte de KDE-PIM)



http://www.sharpreader.net/ - el RSS Reader gratuito escrito en. NET para Windows



http://ranchero.com/netnewswire/ - Un excelente lector de RSS para Mac OS X (tiene dos versiones gratuitas y de pago)



http://www.utsire.com/shrook/ - Un lector de RSS para Mac OS X que soporta HTTPS (incluso con certificados firmados por cuenta propia) y autenticado.



http://vienna-rss.sourceforge.net/ - Open source Feed Reader para Mac OS X con el soporte de Carpetas Inteligentes



http://www.mesadynamics.com/Tickershock.html - no intrusiva "ticker de noticias de" estilo de lector de RSS para Mac OS X



http://www.wizzrss.com/Welcome.php - WizzRSS lector de feeds para Firefox

248

EL SUBSISTEMA DE CONTROL DE VERSIONES

TracBrowser

El navegador de repositorios Trac El navegador de repositorios Trac se puede utilizar para navegar por los directorios y revisiones específicas de los archivos almacenados en el repositorio de la configuración del sistema de control de versiones.

Las entradas del directorio se muestran en una lista con columnas ordenable. Las entradas de la lista se pueden ordenar por nombre, tamaño o edad, haciendo clic en los encabezados de columna. El orden puede invertirse haciendo clic en un encabezado de columna dado nuevamente.

El navegador puede ser utilizado para navegar por la estructura del directorio haciendo clic en los nombres de directorio. Al hacer clic en un nombre de archivo, mostrará el contenido del archivo. Al hacer clic en el número de revisión de un archivo o directorio, le llevará a la TracRevisionLog para ese archivo. Tenga en cuenta que también hay un vínculo de navegación al Registro de Revisiones (Revision Log) que hace lo mismo para la ruta de acceso que en la actualidad se está examinando.

También es posible navegar por los directorios o archivos que estaban en el historial, en cualquier revisión del repositorio dado. El comportamiento por defecto es mostrar la

249

última revisión, pero otro número de revisión puede seleccionar fácilmente usando la entrada de la revisión de campo View revision en la parte superior de la página.

La barra de colores al lado de la columna Edad da una indicación visual de la edad de la última modificación de un archivo o directorio. En la configuración por defecto, el azul es más antiguo y el rojo es más reciente, pero esto se puede configurar.

En la parte superior de la página del navegador, hay un menú desplegable que se puede utilizar para seleccionar algunos lugares interesantes en el repositorio, por ejemplo, las ramas o etiquetas. Esto se refiere a veces como la facilidad browser quickjump. El significado preciso y el contenido de este menú dependerán de su servidor. Para Subversion, esta lista contiene por defecto unas cuantas ramas (trunk y cualquier subcarpeta más recientes de la carpeta branches de nivel superior) y unas pocas etiquetas (cualquier subcarpeta de la carpeta tags de nivel superior). Esto puede ser configurado para los casos más avanzados.

Si usted está usando un Javascript activado en el navegador, usted será capaz de expandir y contraer las carpetas haciendo clic en la flecha en el lado derecho de una carpeta. Alternativamente, el teclado también se puede utilizar para ello: el uso de „k‟ y 'j' para ir a la entrada siguiente o anterior, y „o‟ (o 'Enter') para alternar entre el estado expandido y colapsado de la carpeta seleccionada o para visitar el archivo seleccionado.

Para el backend de Subversion, algunas características adicionales están disponibles: Soporte para la propiedad svn: needs-lock Soporte para la propiedad svn: externals (que puede ser configurado) El svn:mime-type se utiliza para seleccionar el resaltador de sintaxis para la prestación del archivo. Por ejemplo, cofigurando svn:mime-type a text/html garantizará que el archivo se coloreará como HTML, independientemente de la extensión de archivo.

También permite seleccionar la codificación de caracteres utilizados en el contenido del archivo. Por ejemplo, si el contenido del archivo está codificado en UTF-8, ponga svn:mime-type a text/html; charset=utf-8. La especificación chartset= reemplaza la codificación predeterminada definida en la opción de default_charset de la sección [trac] del trac.ini.

250

TracChangeset

Módulo Trac de cambios Trac tiene una funcionalidad integrada para la visualización de "diffs" - los cambios a los archivos.

Existen diferentes tipos de conjuntos de cambios. Algunos pueden corresponder a las revisiones efectuadas en los repositorios, los demás pueden acumular cambios en varias revisiones, pero al final, cualquier tipo de diferencias puede ser mostrada.

El punto de vista de cambios consta de dos partes, la cabecera y la vista de diferencias.

Changeset Header La cabecera muestra una visión general de todo el conjunto de cambios. Aquí podrás encontrar la información tal como: Timestamp - Cuándo se cometió el conjunto de cambios Autor - ¿Quién cometió el conjunto de cambios Mensaje - Una descripción breve del autor (el mensaje de registro) Archivos - Una lista de los archivos afectados por este conjunto de cambios Si más de una revisión está involucrada en el conjunto de cambios que se muestra, la fecha y hora, autor y campos de mensaje no se muestra.

251

Al frente de cada archivo en la lista, encontrará un rectángulo de color. El color indica el archivo se ve afectado por los cambios.

Verde: Añadido Rojo: Eliminado Amarillo: Modificado Azul: copiado Gris: Desplazado La leyenda de color se encuentra debajo de la cabecera como recordatorio.

Diff Views Debajo de la cabecera es la parte principal del conjunto de cambios, la vista de diferencias. Cada archivo se muestra en una sección separada, cada uno de los cuales contendrá sólo las regiones del archivo que se ven afectados por los cambios. Hay dos estilos diferentes de mostrar las diferencias: inline o side-by-side (se puede cambiar entre los estilos utilizando el formulario de preferencias): El estilo inline muestra las regiones cambiado de un archivo por debajo de unos a otros. Una región de removida de los archivos será de color rojo, una región añadida será de color verde. Si una región fue modificada, la antigua versión se muestra por encima de la nueva versión. Los números de línea en el lado izquierdo indican la posición exacta de los cambios tanto en la antigua y la nueva versión del archivo.

El estilo side-by-side muestra la antigua versión a la izquierda y la nueva versión a la derecha (esto normalmente requiere más ancho de pantalla que el estilo de línea.) Regiones añadidas y removidas serán coloreadas de la misma manera como con el estilo inline (verde y rojo, respectivamente), pero las regiones modificadas, tendrá un fondo amarillo.

Además, varias opciones avanzadas están disponibles en el formulario de preferencias para ajustar la visualización de las diferencias: Usted puede configurar cuántas líneas van a ser mostradas antes y después de cada cambio (si el valor all es usado, entonces todo el archivo será mostrado) Usted puede cambiar si son ignoradas o no las líneas en blanco, casos de cambio y espacios en blanco, lo que le permite encontrar los cambios funcionales más rápidamente.

252

Diferentes formas de obtener un cambio Examinando un Changeset Cuando vemos un chequeo en el repositorio, como cuando seguimos un enlace a un conjunto de cambios o a un evento de cambios en la línea de tiempo, Trac mostrará los cambios exactos realizados por el chequeo.

Habrá también enlaces de navegación para ir a los cambios anteriores y siguientes.

Examinando diferencias entre revisiones A menudo querrá mirar a los cambios realizados en un archivo o en un directorio que abarca múltiples revisiones. La forma más sencilla de llegar es desde el TracRevisionLog, donde puede seleccionar la edad y las nuevas revisiones del archivo o directorio, y luego haga clic en el botón View changes.

Examinando diferencias entre ramas Una de las principales características de los sistemas de control de versiones es la posibilidad de trabajar simultáneamente en diferentes líneas de evolución, llamada comúnmente "ramas". Trac permite examinar las diferencias exactas entre dichas ramas.

Usando el botón View changes... en el TracBrowser le permite ingresar From: y To: rutas/revisión pares. El conjunto resultante de las diferencias consisten en que los cambios deben aplicarse a los contenidos From:, a fin de llegar al contenido To:.

Por conveniencia, es posible invertir los papeles de la vieja y la nueva rutas/revisión pares haciendo clic en el enlace Reverse Diff en la página de cambios.

Chequeando el último cambio La última posibilidad para examinar cambios es utilizar el enlace Last Change proporcionada por el TracBrowser.

Este enlace te llevará a la última modificación que se hizo en esa ruta. Desde allí, usted puede utilizar el enlace Previous Change y Next Change para recorrer el historial de cambios del archivo o directorio.

253

TracRevisionLog Visualización de revisión Registros Al navegar en el repositorio, siempre es posible consultar la vista Revision Log correspondiente a la ruta que estás viendo. Esto mostrará una lista de los conjuntos de cambios más recientes en los que la ruta actual o de cualquier otra ruta por debajo de ella se haya modificado.

El Formulario de Registro de Revisiones Es posible establecer la revisión en la que el registro de la revisión debe comenzar, usando el campo View log starting at. Un valor vacío o un valor de head se toman como los cambios más recientes.

También es posible especificar la revisión en la que el registro debe parar, usando el cambio back to. Por defecto, se queda vacío, lo que significa que el registro de revisiones se detendrá tan pronto como 100 revisiones han sido listadas.

Además, hay tres modos de funcionamiento del registro de revisiones.

De forma predeterminada, el registro de revisiones se detiene en copia, lo que significa que cada vez que un complemento, operación Copiar o Renombrar es detectado, ninguna revisión anterior será mostrada. Eso es muy conveniente cuando se trabaja con las ramas, como uno sólo ve el historial que corresponde a lo que se ha hecho en la rama.

También es posible indicar que uno quiere ver lo que sucedió antes de una copia o un cambio de Renombrado, seleccionando el modo de seguimiento de copias. Esto cruzará todas las copias o cambios de nombre. Cada vez que el nombre de la ruta cambia, habrá un nivel de sangría adicional. De esta manera, los cambios en los diferentes caminos son fáciles de agrupar visualmente.

Es incluso posible ir al pasado en cambios de Add, con el fin de ver si ha habido un cambio Delete en esa ruta, antes que Add. Este modo corresponde al modo llamado Show only adds, moves and deletes. Aunque muy útil, a veces, sea consciente de que esta operación es muy intensiva en recursos.

254

Por último, también hay una casilla de verificación Show full log message, que controla si el contenido completo del mensaje de registro se debe mostrar para cada cambio, o sólo una versión abreviada del mismo.

La información de registro de revisiones Para cada entrada de registro de revisiones, hay 7 columnas que muestran: 1. La primera columna contiene un par de botones de radio y debe utilizarse para seleccionar las viejas y las nuevas revisiones que se utilizarán para ver los cambios reales.

2. Un código de color (similar a la utilizada para los conjuntos de cambios), indicando el tipo de cambio. Al hacer clic en esta columna se actualiza un registro de revisión a fin de que lo reinicie con este cambio.

3. La fecha en que se realizó el cambio.

4. El número de revisión, muestra como @xyz. Este es un enlace al TracBrowser, usando esa revisión como la línea de base.

5. El número de cambios mostrado como [xyz]. Este es un enlace a la vista TracChangeset.

6. El autor del cambio.

7. El mensaje de registro, que contiene un resumen o el mensaje de registro completo, en función del valor total de la casilla de verificación Show full log messages en el formulario de arriba.

La inspección de los cambios entre las revisiones Los botones View changes… (situados por encima y por debajo de la lista de cambios, en la parte izquierda) muestra el conjunto de las diferencias correspondientes a los cambios globales a partir de una antigua revisión (primer radio-botón) a la nueva revisión (segundo radio-botón), en el punto de vista TracChangeset.

Tenga en cuenta que la revisión de edad no tiene por qué ser en realidad más que la nueva revisión, sino que sólo da una base para el diff. Es por lo tanto perfectamente posible generar fácilmente un reverse diff, para revertir lo que se ha hecho en el determinado rango de revisiones.

Por último, si las dos revisiones son idénticas, se mostrará el correspondiente conjunto de cambios (el mismo efecto que al hacer clic en la columna 5).

255

Formatos alternativos El texto de cambios En la parte inferior de la página, hay un vínculo ChangeLog que mostrará el rango de revisiones que actualmente se muestra, pero como un texto sencillo, igualando las convenciones habituales para los ficheros ChangeLog.

Soporte RSS El registro de la revisión también proporciona un canal RSS para supervisar los cambios.

Para suscribirse a un feed RSS para un archivo o directorio, abra su registro de revisiones en el navegador y haga clic en el icono naranja "XML" en la parte inferior de la página. Para obtener más información sobre el soporte de RSS en Trac, véase TracRss.

El Subsistema de tickets TracTickets

El sistema Trac Ticket La base de datos de Trac tickets ofrece un seguimiento simple pero eficaz de los problemas y los errores dentro de un proyecto.

256

Como el elemento central de la gestión de proyectos de Trac, los tickets se utilizan para tareas de proyectos, peticiones de características, informes de errores y problemas de soporte de software.

Al igual que con el TracWiki, este subsistema se ha diseñado con el objetivo de que la contribución de los usuarios y la participación sea lo más simple posible. Debe ser tan fácil como sea posible para informar de los errores, hacer preguntas y proponer mejoras.

Una incidencia que se asigna a una persona que debe resolver o reasignar el ticket a otra persona. Todos los tickets pueden ser editados, anotados, asignados, priorizados y discutidos en cualquier momento.

Ticket Fields Un ticket contiene atributos con la siguiente información: Reporter - El autor de la entrada.

Type - La naturaleza de la entrada (por ejemplo, defecto o mejora de la solicitud) Component - El módulo del proyecto o de un subsistema del que trata el ticket. Version Versión del proyecto que pertenece a este ticket.

Keywords - Palabras clave con los que un ticket es marcado. Útiles para la búsqueda y generación de informes.

Priority- La importancia de esta incidencia, que van desde la trivial a bloqueador.

Milestone - Cuando este problema debe ser resuelto a más tardar.

Assigned to/Owner – Persona principal responsable para el manejo de la incidencia. CC - Una lista separada por comas de otros usuarios o direcciones de correo electrónico de notificación. Tenga en cuenta que esto no implica incumba la responsabilidad o cualquier otra política.

Resolution - Razón por la cual se cerró el ticket. Uno de fixed, invalid, wontfix, duplicate, worksforme.

257

Status - ¿Cuál es la situación actual? Uno de new, assigned, closed, reopened.

Summary - Una breve descripción que resume el problema o incidencia.

Description - El cuerpo del ticket. Una buena descripción debe ser específica, descriptiva y al punto.

Nota: Las versiones de Trac antes de 0,9 no tenía el tipo de campo, sino que proporcionan un campo de gravedad y distintos valores por defecto para el campo de prioridad. Este cambio fue hecho para simplificar el modelo de entradas por la eliminación de la distinción un tanto borrosa entre la prioridad y gravedad. Sin embargo, el viejo modelo que está disponible si lo prefiere: sólo tiene que añadir / modificar los valores predeterminados de la prioridad y gravedad, y, opcionalmente, ocultar el tipo de campo, eliminando todos los posibles valores a través de trac-admin.

Nota: El tipo, componente, versión, prioridad y campos de gravedad se puede manejar con trac-admin o con el plugin de WebAdmin.

Nota: La descripción de los valores de prioridad de orden interna está disponible en TicketTypes

Cambiando y comentando Tickets Una vez que el ticket se ha ingresado en Trac, se puede modificar en cualquier momento la información para anotar el error. Esto significa que los cambios y comentarios al ticket se han identificado como una parte del ticket en sí.

Al ver un ticket, la historia de los cambios aparecerá debajo del área del ticket principal.

En Trac, se usan los comentarios de ticket para discutir temas y tareas. Esto hace entender más fácil la motivación detrás de un diseño o aplicación, al regresar a ella más adelante.

Nota: Una característica importante es la de ser capaz de utilizar TracLinks y WikiFormatting en las descripciones de tickets y en los comentarios. Utilice TracLinks para referirse a otras incidencias, changesets o archivos para hacer a los tickets más específicos y fáciles de entender.

258

Nota: Consulte TracNotification para saber cómo configurar notificaciones por correo electrónico de los cambios de los tickets.

Nota: Consulte TracWorkflow para obtener información sobre las transiciones de estado (ciclo de vida del ticket), y cómo este flujo de trabajo puede ser personalizado.

Valores predeterminados para campos desplegables La opción seleccionada por defecto para el despliegue de varios campos se puede establecer en trac.ini, en la sección [ticket]: default_component: Nombre del componente seleccionado por defecto default_milestone: Nombre del hito por defecto default_priority: valor de prioridad por defecto default_severity: valor de gravedad por defecto default_type: tipo de ticket por defecto default_version: nombre de la versión por defecto Si se omite alguna de estas opciones, el valor predeterminado o bien será la primera en la lista, o un valor vacío, dependiendo de si el ámbito en cuestión es necesario que se establezcan.

Ocultar campos y añadir campos personalizados Muchos de los campos predeterminados de tickets se pueden ocultar desde la interfaz web de tickets simplemente mediante la eliminación de todos los posibles valores a través de trac-admin. Por supuesto, esto sólo se aplica a campos desplegables, como el tipo, prioridad, gravedad, componente, versión e hito.

Trac también te permite añadir tus propios campos de entrada personalizado. Ver TracTicketsCustomFields para más información.

Assign-to como lista desplegable Si la lista de los propietarios de entradas posibles es finita, puede cambiar el campo assign-to de un campo de entrada de texto a una lista desplegable. Esto se hace

259

mediante el establecimiento de la opción restrict_owner a “true” en la sección [ticket] en el trac.ini. En ese caso, Trac utilizará la lista de todos los usuarios que han accedido al proyecto para poblar el campo desplegable.

Para aparecer en la lista desplegable, un usuario debe estar registrado en el proyecto, es decir, una sesión de usuario debe existir en la base de datos. Esta entrada se crea automáticamente en la base de datos la primera vez que el usuario envía un cambio en el proyecto, por ejemplo, al editar la información del usuario en la página de configuración, o simplemente mediante la autenticación si el usuario tiene un inicio de sesión. Además, el usuario debe tener permisos de TICKET_MODIFY.

Valores de preajuste para tickets nuevos Para crear un enlace al formulario del nuevo ticket llenado con los valores preestablecidos, es necesario llamar al /newticket? URL con variable=valor separados por &.

Las variables posibles son: type - El tipo de lista desplegable reporter - Nombre o correo electrónico del que reporta summary – Línea de resumen del ticket description - Descripción larga del ticket component - Lista desplegable del componente version - Lista desplegable de la versión severity - Lista desplegable de la gravedad keywords - Las palabras clave priority - Lista desplegable de la prioridad milestone - Lista desplegable del hito owner - La persona responsable del ticket cc - Lista de correos electrónicos para notificar los cambios del ticket Ejemplo: /trac/?newticket?summary=Compile%20Error&version=1.0&componente=gui

260

TracReports

Informes de Trac El módulo de informes Trac proporciona un sencillo y potente mecanismo de presentación de informes para presentar información sobre entradas en la base de datos Trac.

En lugar de tener su propio formato de definición de informe, TracReports se basa en el estándar SQL SELECT para definición de informes personalizados.

Nota: El módulo de informes se está eliminando progresivamente en su forma actual ya que limita seriamente la capacidad del equipo de Trac para realizar ajustes en el esquema de base de datos subyacente. El módulo de consulta es un buen reemplazo que proporciona más flexibilidad y una mejor usabilidad. Si bien hay algunos informes que aún no pueden ser manejados por el módulo de consulta, existe la intención de mejorarla aún más para que en algún momento el módulo de informes pueda ser eliminado completamente. Esto también significa que no habrá más mejoras importantes en el módulo de informes.

Ya se puede sustituir por completo el módulo de informes por el módulo de consulta, simplemente mediante la desactivación en trac.ini: [components] trac.ticket.report.* = disabled

261

Esto hará que el módulo de consulta sea el controlador predeterminado para la navegación "View Tickets". Le animamos a probar esta configuración e informar qué tipo de características de informes faltan, si hay alguno.

Es casi definitivamente necesario que reinicie el httpd en este punto.

Un informe consta de las siguientes partes básicas: ID - Identificador único (secuencial) Title - Título descriptivo Description - Una breve descripción del informe, en texto de WikiFormatting. Report Body - Lista de los resultados de la consulta de informe, con formato de acuerdo a los métodos descritos a continuación.

Footer - Enlaces a formatos alternativos de descarga para este informe.

Cambiar el orden Informes Simples - informes desagrupados para ser específicos - se puede cambiar para ser ordenada por cualquier columna, simplemente haciendo clic en el encabezado de la columna.

Si un encabezado de la columna es un hipervínculo (rojo), haga clic en la columna que desea ordenar. Al hacer clic en el mismo encabezado de nuevo se invierte el orden.

Cambiando la numeración del Informe Puede haber casos en que es necesario cambiar el ID del informe, tal vez para organizar mejor los informes. En la actualidad esto requiere cambios en la base de datos de Trac.

La tabla de informe tiene el siguiente esquema: 

ID INTEGER PRIMARY KEY



Texto de autor



Texto del título



Texto de la consulta



Texto de descripción

262

Cambiando el ID se cambia el orden mostrado y el número en la lista de resporte disponible y permalink del informe. Esto se hace mediante la ejecución de algo así como: update report set id=5 where id=3; Tenga en cuenta que la integridad se ha de mantener (es decir, ID tiene que ser único, y usted no quiere superar el máximo, ya que es gestionado por SQLite).

Navegando Tickets Al hacer clic en uno de los resultados del informe le llevará a ese ticket. Usted puede navegar a través de los resultados haciendo clic en los enlaces siguiente o anterior ticket justo debajo de la barra de menú principal, o haga clic en el enlace Back to Report para volver a la página del informe.

Puede modificar cualquier ticket y continuar navegando por los resultados con los enlaces Next/Previous/Back to Report después de guardar los resultados, pero cuando regrese con el informe, no habrá ninguna pista sobre lo que ha cambiado, igual sucede si se viaja con

una

lista

de

los

tickets

obtenidos

a

partir

de

una

consulta

(véase

TracQuery#NavigatingTickets).

Descargar Formatos alternativos Aparte de la vista predeterminada HTML, los informes también se pueden exportar en una serie de formatos alternativos. En la parte inferior de la página del informe, usted encontrará una lista de los formatos de datos. Haga clic en el enlace deseado para descargar el formato de informe alternativo.

Delimitado por comas - CSV (Comma Separated Values) Exportar el informe como texto sin formato, cada fila en su propia línea, columnas separadas por una sola coma (',').

Nota: Los retornos de carro, saltos de línea, y las comas son despojados de los datos de la columna para preservar la estructura CSV.

263

Delimitado por tabuladores Al igual que anteriormente, pero utiliza tabuladores (\ t) en lugar de coma.

RSS - XML Content Syndication Todos los informes mediante el apoyo de sindicación XML / RSS 2.0. Para suscribirse a un feed RSS, haga clic en el icono naranja "XML" en la parte inferior de la página. Vea TracRss para información general sobre el soporte de RSS en Trac.

Creación de informes personalizados La creación de un informe personalizado requiere un conocimiento cómodo de SQL. Un informe es básicamente una única consulta SQL, ejecutado y presentado por Trac.

Los informes pueden ser vistos y creados a partir de una expresión SQL personalizada directamente desde la interfaz web.

Normalmente, un informe consta de una expresión SELECT de la tabla ticket, utilizando las columnas disponibles y ordenada de la forma en la que usted quiera.

Columnas del Ticket La tabla ticket tiene las siguientes columnas: id type time changetime component severity priority owner reporter cc version milestone status resolution summary description keywords

264

Véase TracTickets para una descripción detallada de los campos de columna.

Ejemplo: Todas los tickets activos, ordenados por prioridad y tiempo SELECT id AS ticket, status, severity, priority, owner, time as created, summary FROM ticket WHERE status IN ('new', 'assigned', 'reopened') ORDER BY priority, time

Informes avanzados: variables dinámicas Para informes más flexibles, Trac soporta el uso de variables dinámicas en SQL. En resumen, las variables dinámicas son cadenas especiales que se sustituirán por los datos personalizados antes de la ejecución de la consulta.

Uso de variables en una consulta La sintaxis de las variables dinámicas es sencilla, cualquier palabra en mayúsculas comenzando con '$' se considera una variable.

Ejemplo: SELECT id AS ticket,summary priority=$PRIORITY

FROM

ticket

WHERE

Para asignar un valor a $PRIORITY a la hora de ver el informe, se debe definir como un argumento en la dirección URL del informe, dejando de lado la guía $.

Ejemplo: http://trac.edgewall.org/reports/14?PRIORITY=high Para utilizar las variables, sepárelos con un '&'.

Ejemplo: http://trac.edgewall.org/reports/14?PRIORITY=high&SEVERITY=cr itical Variables especiales/constantes Hay una variable dinámica mágica para permite que los informes prácticos, su valor se establece automáticamente sin tener que cambiar la dirección URL.

265

$ USER - usuario del usuario conectado.

(Ejemplo de lista de todos los tickets asignados al usuario): SELECT id AS owner=$USER

ticket,summary

FROM

ticket

WHERE

Informes avanzados: formato personalizado Trac

es capaz también

hacer

informes más

avanzados,

incluyendo

diseños

personalizados, la agrupación de resultados y estilos CSS definidos por el usuario.

Para crear esos informes, usaremos sentencias SQL especializadas para controlar la salida del motor de informes de Trac.

Columnas especiales Para formatear los informes, TracReports busca los nombres de columna 'magic' en el resultado de la consulta. Estos nombres „magic‟ son procesados y afectan al diseño y el estilo del informe final.

Columnas formateadas automáticamente ticket – Número de identificación del Ticket. Se convierte en un hipervínculo a ese ticket. created, modified, date, time - Formatea a la celda como una fecha y/o tiempo. description - campo de descripción de tickets procesados por el motor del wiki.

Ejemplo: SELECT id as ticket, created, status, summary FROM ticket

Columnas de un formato personalizado Columnas cuyos nombres comienzan y terminan con 2 guiones bajos (Ejemplo: __color__) son asumidos para ser sugerencias formateadas, que afectan a la apariencia de la fila.

266

__group__ - Los resultados del Grupo basados en valores de esta columna. Cada grupo tendrá su propio encabezado y tabla. __color__ - Debe ser un valor numérico de 1 a 5 para seleccionar un conjunto predefinido de colores por fila. Suele usarse para colorear filas por incidencias de prioridad.

Predeterminados: Color 1 Color 2 Color 3 Color 4 Color 5 __style__ - Una expresión de estilo CSS personalizado para usar en la fila actual.

Ejemplo: Lista de tickets activos, agrupados por hitos, coloreados por prioridad

SELECT p.value AS __color__, t.milestone AS __group__, (CASE owner WHEN 'daniel' THEN 'font-weight: bold; background: red;' ELSE '' END) AS __style__, t.id AS ticket, summary FROM ticket t,enum p WHERE t.status IN ('new', 'assigned', 'reopened') AND p.name=t.priority AND p.type='priority' ORDER BY t.milestone, p.value, t.severity, t.time

Nota: Una tabla de combinación es usada para que coincida con las prioridades de los tickets, con su representación numérica de la tabla enum.

Cambiando la disposición de filas informe Por defecto, todas las columnas en cada fila se muestran en una sola fila en el informe de HTML, posiblemente con formato de acuerdo a las descripciones anteriores. Sin embargo, también es posible crear tickets de información en multi-línea. column_ - Quiebre de la fila después de esto. Añadiendo un guión ('_') al nombre de columna, las columnas restantes se continuará en una segunda línea. _column_ - Fila completa. Mediante la adición de un guión ('_') tanto en el comienzo y el final de un nombre de columna, los datos se muestran en una fila distinta. _column - Ocultar datos. Anteponiendo un guión ('_') a un nombre de columna Trac encarga de ocultar el contenido de la salida HTML. Esto es útil para la información sea visible sólo si se descarga en otros formatos (como CSV o RSS / XML).

267

Ejemplo: Lista de tickets activos, agrupados por hitos, coloreados por prioridad, con la descripción y de trazado multi-línea

SELECT p.value AS __color__, t.milestone AS __group__, (CASE owner WHEN 'daniel' THEN 'font-weight: bold; background: red;' ELSE '' END) AS __style__, t.id AS ticket, summary AS summary_,-- ## Break line here component,version, severity, milestone, status, owner, time AS created, changetime AS modified,

-- ## Dates

are formatted description AS _description_,

-- ## Uses a full row

changetime AS _changetime, reporter AS _reporter -- ## Hidden from HTML output FROM ticket t,enum p WHERE t.status IN ('new', 'assigned', 'reopened') AND p.name=t.priority AND p.type='priority' ORDER BY t.milestone, p.value, t.severity, t.time

Presentación de informes sobre los campos personalizados Si se han añadido campos personalizados para sus tickets usted puede escribir una consulta SQL para cubrirlos. Tendrá que hacer un join en la tabla ticket_custom, pero esto no es especialmente fácil.

Si tiene tickets en la base de datos antes de declarar los campos adicionales en trac.ini, no habrá datos asociados en la tabla ticket_custom. Para evitar esto, utilice cláusulas SQL “LEFT OUTER JOIN". Vea TracIniReportCustomFieldSample para algunos ejemplos. http://trac.edgewall.org/intertrac/TracIniReportCustomFieldSample Tenga en cuenta que es necesario establecer los permisos para ver los botones para añadir o editar informes.

268

TracQuery

Consultas Trac Tickets Además de los informes, Trac proporciona soporte para las consultas de ticket personalizado, se utiliza para mostrar las listas de tickets estableciendo un conjunto específico de criterios.

Para configurar y ejecutar una consulta personalizada, cámbiese al módulo View Tickets de la barra de navegación, y seleccione el enlace Consulta personalizada.

Filtros La primera vez que vaya a la página de consulta de los filtros por defecto se mostrarán todas las incidencias abiertas, o si está logueado, en ella se mostrarán los tickets abiertos asignados a usted. Filtros actuales pueden eliminarse haciendo clic en el botón a la derecha con el signo menos en la etiqueta. Los filtros nuevos se añaden en la lista desplegable de la esquina inferior derecha de la caja de filtros. Los filtros con un cuadro de texto o un menú desplegable de opciones se pueden agregar varias veces para realizar un criterio or.

Usted puede utilizar los campos justo debajo de la caja de filtros para agrupar los resultados basados en un campo, o mostrar la descripción completa para cada ticket.

Una vez que haya editado los filtros, haga clic en el botón Update para actualizar sus resultados.

269

Entradas Navegando Al hacer clic en uno de los resultados de la consulta le llevará al ticket. Usted puede navegar a través de los resultados haciendo clic en los enlaces Next Ticket o Previous Ticket justo debajo de la barra de menú principal, o haga clic en el enlace Back to Query para volver a la página de la consulta.

Usted puede seguramente editar cualquiera de los tickets y continuar navegando a través de los resultados con los enlaces Next/Previous/Back to Query después de guardar los resultados. Cuando regrese a la consulta de los tickets, cualquier ticket que se haya editado se mostrará con el texto en cursiva. Si se ha editado una de los tickets de tal manera que ya no coincide con los criterios de consulta, el texto también estará en gris.

Por último, si un nuevo ticket que se ajuste a los criterios de consulta se ha creado, se mostrará en negrita.

Los resultados de la consulta pueden ser renovados y limpiados de estos indicadores de estado haciendo clic en el botón Update de nuevo.

Guardar consultas Mientras que Trac aún no permita guardar una consulta por nombre y de alguna manera hacerlo disponible en una lista navegable, usted puede guardar las referencias a las consultas en un contenido de Wiki, como se describe a continuación.

Usando TracLinks Es posible que desee guardar algunas consultas para que pueda volver a ellos más tarde. Usted puede hacer esto haciendo un enlace a la consulta de cualquier página de Wiki. [query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0] Esto utiliza un lenguaje de consulta muy sencilla para especificar los criterios.

Alternativamente, usted puede copiar la cadena de consulta de una consulta y pegarla en el enlace Wiki, incluido el carácter principal „?‟: [query:?status=new&status=assigned&status=reopened&group=owner tickets by owner]

Assigned

270

Usando el macro [[TicketQuery]] La macro TicketQuery le permite visualizar listas de tickets que coincidan con determinados criterios en cualquier lugar donde pueda utilizar WikiFormatting.

Ejemplo: [[TicketQuery(version=0.6|0.7&resolution=duplicate)]] Al igual que la query:wiki links, el parámetro de este macro espera una cadena de consulta con formato de acuerdo a las normas de ticket query language.

Una representación más compacta sin los resúmenes de ticket también está disponible: [[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]] Por último, si desea recibir sólo el número de defectos que coinciden con la consulta utilice el parámetro count. [[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]] Personalización el formato de la tabla También puede personalizar las columnas mostradas en el formato de tabla (format=table) con col=<field> - usted puede especificar varios campos y en qué orden se mostrarán, mediante la colocación de una barra vertical (|) entre las columnas, como a continuación: [[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=res olution|summary|owner|reporter)]] Lenguaje de consulta query: TracLinks y el macro [[TicketQuery]] utilizan un mini “query language” para especificar los filtros de consulta. Básicamente, los filtros están separados por los símbolos de unión (&). Cada filtro consiste entonces en el nombre del campo del ticket, un operador, y uno o más valores. Más de un valor están separados por una barra vertical (|), lo que significa que el filtro coincide con alguno de los valores.

Los operadores disponibles son:

271

= El contenido del campo coincide exactamente con uno de los valores ~ = El contenido del campo contiene uno o más de los valores ^ = El contenido del campo comienza con uno de los valores $ = El contenido del campo termina con uno de los valores de Todos estos operadores también pueden ser negados: !=

El contenido del campo coincide con ninguno de los valores

~=

El contenido del campo no contiene ninguno de los valores

!^=

El contenido del campo no se inicia con cualquiera de los valores

!$=

El contenido del campo no termina con uno de los valores

TracRoadmap

La Hoja de Ruta Trac La hoja de ruta ofrece una vista sobre el sistema de tickets que ayuda a planificar y gestionar el futuro desarrollo de un proyecto.

Ver la Hoja de Ruta Básicamente, el plan de trabajo es sólo una lista de hitos futuros. Usted puede agregar una descripción de los hitos (utilizando WikiFormatting) describiendo los objetivos

272

principales, por ejemplo. Además, el objetivo de los tickets para un hito son agregados, y la relación entre activo y resuelto de los tickets se muestran como una barra de progreso del hito.

La Vista de Milestone Es posible profundizar en esta estadística simple de ver las páginas de hito individuales.

De forma predeterminada, la relación activo/resuelto se agrupan y se muestran por componente. También puede reagrupar el estado por otros criterios, como pro el propietario del ticket o la gravedad. El número de tickets son relacionados con consultas personalizadas listando los tickets correspondientes.

Administración del Roadmap Es posible agregar, modificar y eliminar los hitos usando el TracAdmin o la interfaz web.

Nota: Las descripciones de los hitos en la actualidad sólo pueden ser editadas desde la interfaz web. Con los permisos apropiados, usted podrá ver los botones para la gestión de hitos en las páginas Roadmap y milestone.

Soporte iCalendar Roadmap es compatible con el formato iCalendar para hacer un seguimiento de los hitos y con los tickets previstos desde su software de calendario favorito. Las aplicaciones de calendario que soportan la especificación iCalendar incluyendo el Apple iCal para Mac OS X y a través de plataformas Mozilla Calendar, y Chandler. Korganizer (la aplicación de calendario del proyecto KDE) y Evolution también soportan iCalendar.

Para suscribirse al Roadmap, copiae el enlace de iCalendar (que se encuentra en la parte inferior de la página) y en su aplicación de calendario elija la opción "Subscribe to remote calenda" (o similar), e inserte la URL acaba de copiar.

273

ANEXO 5: GUIA PARA EMPEZAR A TRABAJAR CON ORACLE

274

TRABAJANDO CON ORACLE Uso del programa de manejo de versiones Uno de los problemas en la vida de una aplicación es de saber cual es la versión actual (en producción) de los archivos, sin tener que sacar una copia de la producción, de poder retroceder hacia una versión anterior. Otro problema es el desarrollo concurrente (varios programadores trabajando sobre un mismo código).

Para contestar estos problemas existen los programas de manejo de versiones. Estos programas van a guardar todos los archivos en un repositorio. Se incrementará automáticamente el número de versión de un archivo cada vez que se guarda una nueva versión del archivo en el repositorio, y se le podrá adjuntar un comentario con el fin de poder trazar el histórico del archivo.

En un sistema típico de cliente servidor, una sola persona puede tener el derecho de escribir en el archivo, los demás solo lo pueden leer. Si dos personas leen el mismo archivo, lo modifican cada uno de su lado y luego lo escriben, la segunda persona va a sobrescribir los cambios hechos por la primera persona, perdiendo su trabajo.

Para evitar este problema de sobre escritura, existen dos soluciones: la solución bloquear-modificar-desbloquear y la solución copiar-modificar-fusionar

Solución bloquear-modificar-desbloquear Cuando se trabaja con archivos no-fusionables como lo son los archivos compilados de Oracle form builder es necesario trabajar con este tipo de solución, ya que no pueden haber dos personas trabajando sobre el mismo archivo concurrentemente, lo que no es así cuando se trabaja con archivos de texto plano donde los cambios sí se pueden fusionar.

Es igual que con las imágenes, si dos personas editan una imagen al mismo tiempo sus cambios sobrescribirán a la imagen anterior de acuerdo al orden de quien hizo commit sobre sus cambios primero, sin embargo se podrá acceder a la imagen anterior por su número de revisión.

Pero con el sistema de bloqueo, un usuario podrá bloquear un archivo, lo que impedirá que cualquier otro usuario lo pueda modificar hasta que el bloqueo haya sido quitado.

275

Con este sistema, un archivo solo puede ser utilizado por un usuario. No se permite el desarrollo concurrente.

Esto asegura que al momento de guardar su copia, nadie ha modificado el archivo desde el bloqueo.

Puede sobrescribir el archivo en el repositorio sin riesgo de sobrescribir los cambios hechos por otro usuario.

Ejemplo: Harry primero debe bloquear el fichero antes de que pueda empezar a hacer cambios en él. 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.

¿Cómo se hace esto en un caso práctico?

276

Comienza el día y Harry quiere empezar a trabajar en el sistema académico, para eso primero tiene que hacer update del archivo y así obtener los últimos cambios:

Y lo segundo que debe hacer antes de empezar, es bloquearlo:

277

Una vez bloqueado, comienza a trabajar:

278

Mientras tanto Sally recién llega y quiere trabajar en el mismo archivo, hace update y luego quiere bloquearlo:

Como Harry ya bloqueó el archivo, obtendrá el siguiente mensaje de error:

279

Ahora Sally tendrá que esperar a que Harry termine de trabajar en ese archivo y lo desbloquee para recién trabajar en él, pero supongamos que Sally hace caso omiso de las reglas y empieza a editar el archivo, termina lo que quería hacer y ahora quiere hacer commit:

280

Por lo que obtiene un mensaje de error y no hace commit

En este caso y para que lo que Sally haya hecho no se pierda, tendr谩 que realizar un respaldo del archivo en una carpeta aparte, para que luego, cuando Harry desbloquee el archivo, ella lo actualice, bloquee, y a nivel c贸digo ingresar el c贸digo del archivo de respaldo al nuevo archivo actualizado con los cambios de Harry.

281

Continuando con Harry, él por fin termina de trabajar en el archivo, para lo que debe realizar commit, y así Sally pueda acceder a él:

Cabe recalcar que esto lo debe realizar sin desbloquear el archivo.

282

Terminado el commit, el archivo se desbloqueará automáticamente, siendo accesible para Sally trabajar con él.

Sin embargo cuando Sally mande a bloquear el archivo sin hacer update primero, Subversion le avisará que existe una nueva versión del archivo y que si desea actualizar, Sally presiona update, y como ella había realizado cambios, se genera un conflicto:

Ahora lo que Sally debe hacer es resolver el conflicto:

283

Esto eliminará los cambios de Sally, y dejará al archivo tal como Harry lo dejó.

Ahora Sally podrá editar el archivo, e ingresar el código que posee en el archivo de respaldo.

Por lo tanto para trabajar de forma armónica en el equipo estos no deben olvidar que: Siempre tienen que hacer un update y un bloqueo del archivo antes de trabajar con él.

Si el archivo ya estaba bloqueado por alguien más, esperar a que lo desbloqueen o arriesgarse a repetir el trabajo.

Siempre al terminar de trabajar en un archivo, realizar el commit para que el archivo actualizado quede disponible para el resto del equipo.

Nota: Siempre comenten los cambios que realizaron en las ventanas del commit, para que todos estén al tanto de lo que se hizo.