Sistemas de Control de Versiones

Transcripción

1 Sistemas de Control de Versiones Sebastián Viviani Abril de 2010 Resumen La vida, por corta que parezca,da tiempo para todo (A.Bioy Casares) El presente documento tiene como objetivo explicar en que consiste un Sistema de Control de Versiones, qué usos se le puede dar, el procedimiento y los requerimientos para acceder y utilizar el mismo, y los comandos y funciones básicas que se pueden realizar (modificar un proyecto, generar un nuevo proyecto, controlar el historial de cambios, ver los proyectos existentes, etc). Este tutorial se basará en un sistema en especial, el subversion, de uso bastante difundido en ambientes de desarrollo de software académicos y profesionales. No obstante, las nociones básicas son aplicables a otros sistemas que manejen la misma filosofía, como el también popular cvs 1. Filosofía del sistema En cualquier proyecto de desarrollo de software, es común que haya más de un desarrollador involucrado. Incluso en la codificación de sistemas pequeños, como puede ser el firmware de un microcontrolor de 8 bits, o una aplicación que correrá en un sistema embedded. Ya sea para programar el código, para controlar y validar el avance del mismo, para revisarlo, etc. Y es lógico que cada desarrollador trabaje en su propia computadora, por un tema de performance (no suena muy práctico que se vayan turnando para utilizar el teclado y el monitor). Es necesario, por lo tanto, encontrar una forma de poder compartir los archivos de código fuente, evitando las limitaciones físicas conocidas y los posibles conflictos al realizar cambios en los mismos. Normalmente, una arquitectura modular, bien diseñada, es solución suficiente para asegurarse que los programadores puedan trabajar en diferentes módulos (o archivos), sin pisar su trabajo entre ellos. Y un File Server central, donde se almacene el código, un método sencillo de que todos tengan acceso al proyecto completo. Esta aproximación, bastante simple y rústica, es ampliamente utilizada en pequeñas, medianas y grandes empresas, con relativo éxito. Pero tiene severas limitaciones, empezando por la performance (pensar que TODOS los desarrolladores estarán accediendo al código a través de la LAN), la ortogonalidad del trabajo de cada uno está sujeta a la buena voluntad de cada miembro, y es dificil rastrear los cambios realizados. Sin mencionar que limita a que cada desarrollador, para poder trabajar tenga que tener acceso a la LAN, aunque sea remoto, pero de forma permanente. Existen sistemas de control de versiones que trabajan con ese enfoque, y agregan ciertas funcionalidades, como el SourceSafe o el PVCS (no confundir con el CVS). En general, la vuelta de tuerca que agiliza y soluciona parcialmente los problemas es que el usuario trabaja sobre una copia local, que se copia cuando la pide al servidor (operación de lock). Este lleva un registro de los archivos pedidos, y no permite que dos personas trabajen en el mismo archivo, además de advertir a un usuario cuando pide un archivo que depende de otro que ya está pedido (es decir, depende de algo que probablemente cambie). 1

2 Ahora, casi como un ejercicio de pensamiento lateral, hay que plantear otro forma de atacar el problema. Se va a mantener el almacenamiento centralizado del código fuente, en un servidor remoto, al que llamaremos repositorio. Cada desarrollador tendrá una copia completa del proyecto, en el disco local de su computadora, que deberá sincronizar periodicamente con el repositorio. A esta operación de sincronizar la copia, la llamaremos operación de update. Sobre su copia local, podrá hacer todos los cambios que quiera, a todos los archivos que quiera. Dispone de total libertad para trabajar con ellos. Periodicamente, cuando tenga partes del código listas y probadas, que deban incluirse en el proyecto reportará los cambios al repositorio, transmitiendo solamente las diferencias entre este y su copia local. Y lo más importante, en cada reporte indicará de forma clara y amplia, que cambios realizó y porque. A esta operación de reportar los cambios, la llamaremos operación de commit. Si miramos ahora el cuadro completo, vemos que este nuevo enfoque es mucho más eficiente, práctico y flexible. Los desarrolladores solo necesitan conectarse al repositorio para actualizar o reportar cambios, tienen la libertad de explorar y modificar el código para rastrear bugs o encontrar mejoras, y se lleva un registro claro de quien modificó cada parte del proyecto, y cuándo lo hizo. Al trabajar en una copia local, casi que no se debe luchar contra anchos de banda ni throughputs, y un backup periódico del server, o un mirror, ayuda a ganar en confiabilidad y seguridad al sistema. Obviamente, surgen aspectos de seguridad informática a tener en cuenta, y otros temas que se verán más adelante en lo que respecta a la operación, pero las ventajas son evidentes. Esta filosofia es la que emplea el subversion, y fue implementada originalmente por el cvs (del inglés Concurrent Version System). Esta forma de trabajar tiene un problema, y es el que se da cuando dos (o más) usuarios realizan cambios en el mismo archivo, y tratan de reportarlos. El sistema detecta estos casos, y normalmente resuelve los conflicos de forma automática (puede ser que realicen cambios en diferentes partes del mismo archivo, sin que esto sea un conflicto). Y en los casos donde hay una porción común de código involucrada, deja a criterio del último en reportar que hacer, si pisar los cambios o no. Esta operación se llama merge. Estos conflicos se evitan normalmente si el usuario tiene la precaución de realizar updates antes de comenzar a trabajar en el código, para asegurarse de que arranca con una versión actualizada. IMPORTANTE: La resolución de conflictos se realiza asumiendo que los archivos son de texto plano! La reacción del sistema ante conflictos en archivos binarios es impredecible, asi que no se recomienda incluirlos con los archivos de cógido fuente del proyecto. 2. Requerimientos 2.1. Repositorio El repositorio es básicamente un directorio, que se accede por medio de una url. Como todo servicio, tiene un port asignado, el 3690, que se usará en caso de que la url sea de la forma svn://direccion-repositorio:/proyecto El acceso también puede configurarse por medio de un modulo de un servidor web, como el popular apache. En ese caso, se utilizan el port 80 normal, y se puede aprovechar para encriptar la conexión (y por ende, proteger la información transmitida) con el protocolo https. El repositorio se organiza en directorios, y los permisos de cada directorio son similares a los del filesystem de Unix. Se pueden agrupar por proyectos, por usuarios, etc, según el criterio del administrador. Es importante (y aunque suene un poco trivial, no está de más la aclaración) resaltar que si el repositorio está en una LAN, y debe ser accesible desde internet, el port correspondiente en el Gateway debe estar redireccionado a la IP local del server. 2

3 En este documento no se analizará como instalar y/o configurar un repositorio. Queda a cargo del lector, si está interesado, googlear el tema Clientes Un cliente svn es una aplicación que se conecta al repositorio, y actua sobre un directorio local. Esta aplicación es la que ejecuta los diferentes comandos del protocolo, que incluyen los ya mencionados update y commit, además de otros útiles para ver el contenido del repositorio, de sus directorios, generar nuevos, ver el número de revisión, el historial, comparar versiones, agregar o quitar archivos, etc. Normalmente, se genera un subdirectorio oculto, llamado SVN o.svn en el directorio local. Este subdirectorio contiene información que utiliza el subversion, y no debe ser alterado manualmente por el usuario. El cliente más simple, sobre el que se darán los ejemplos de este documento, se ejecuta por línea de comandos. Aunque no es el único disponible. Actualmente también hay versiones más amigables al usuario, que se integran al Windows TM Explorer o a los diferentes Window Managers de Linux. Incluso muchos IDE s tienen plugins que permiten sincronizar directamente el proyecto actual. En esos casos, suelen configurarse los parámetros desde una ventana, y luego se utilizan de la misma forma que al ejecutar los procedimientos desde la consola, pero de forma automática. No debería ser muy dificil que el lector pueda trasladar lo explicado en esta guia a cada caso particular. Por lo tanto, para empezar, con asegurarse de que el paquete subversion está instalado, es suficiente. En las distribuciones Debian, esto se realiza ejecutando apt-get install subversion Los usuarios de Windows TM pueden descargar e instalar el TortoiseSVN, un cliente que se integra al GUI del sistema Usuarios Para poder realizar operaciones en el repositorio, primero se debe tener autorización para hacerlo. La forma de otorgar y controlar el acceso normalmente es por medio de un username y un password que se utilizan en cada transacción. Suele existir, en los proyectos open-source que están disponibles en Internet, un usuario especial, que se llama anonymous. Dicho usuario suele tener sólo permisos de lectura, y su fin es que se pueda acceder al código para su estudio sin necesidad de estar registrado. Es responsabilidad del administrador del repositorio generar los pares de username y password de los usuarios que trabajarán, y otorgarle los permisos correctos a cada uno. 3. Operaciones básicas Una vez que tenemos acceso a un repositorio, a través de una url conocida, con un username y password autorizados, podemos comenzar a utilizar el svn. Para ver una lista de comandos, o las opciones específicas de cada uno, podemos ejecutar svn help Para todos los ejemplos, supondremos que el repositorio se encuentra en electron.frba.utn.edu.ar:8008/td3demo y que los datos de la cuenta son los del SGE del alumno. Es decir, utilizará el usuario del sistema del departamento, y el mismo password. Esta información es generada por el personal de IT del laboratorio del departamento de electrónica. 3

4 3.1. Cómo acceder a un proyecto existente Lo primero es ver la lista de proyectos del repositorio. Para esto, hay que usar el comando ls, cuya sintaxis es svn ls --username=<usuariosge> Si los datos son correctos, el programa nos preguntará por la clave para del usuario <usuariosge>, y una vez introducida correctamente, el listado de directorios del repositorio. La salida sería algo similar a lo siguiente: Proyecto de Catedra 2009.doc pepe.txt proyecto1/ sign En este caso, hay tres archivos y un directorios. Estos directorios y archivos están en el server que contiene el repositorio, no en la máquina local. El commando ls también admite más opciones, una interesante (y peligrosa a la vez) es la de pasar el password por línea de comandos, mediante la opción --password=<clavesge>. Esto es útil para cuando se generan copias del proyecto de forma automática, por medio de scripts, actualizadas periódicamente, para ponerse en links de la web (los famosos svn hourly tarball, por ejemplo). Normalmente, el login es necesario hacerlo sólo una vez, ya que luego quedan guardados en el perfil del usuario los datos del server y la cuenta, asi que no será necesario realizar nuevamente la autenticación. Vamos a elegir un proyecto para trabajar, que está en el repositorio, y del que no tenemos una copia local aún. El procedimiento de obtener la copia inicial, de la versión actual del repositorio se denomina checkout. En este ejemplo, vamos a descargar el repositorio completo. Para esto, nos ubicamos en nuestro directorio local de proyectos, y ejecutamos svn co (el comando checkout también puede abreviarse como co). La salida será algo similar a lo siguiente: A td3demo/proyecto de Catedra 2009.doc A td3demo/pepe.txt A td3demo/proyecto1/ A td3demo/sign Checked out revision 6. Ya tenemos la copia local en nuestro directorio de proyectos. Se puede verificar que la operación de checkout generó un directorio td3demo, y que ese directorio contiene los 3 archivos y un directorio. Además, informó el número de revisión del proyecto. También se puede revisar que existe, dentro del directorio del proyecto, el subdirectorio.svn, que indica que el mismo se encuentra bajo un sistema de control de versiones. Es hora de empezar a trabajar editando el código, y hacer cambios, pruebas, etc. El proceso de desarrollo puede durar unos minutos, o varios días, pero esto no es ningún problema para el svn, ya que todo se realizará en una copia local, sin alterar el repositorio. A modo de ejemplo, hagamos de cuenta que trabajamos durante algunas horas en el archivo pepe.txt agregando y depurando funciones de procesamiento digital de señales. Una vez terminado el trabajo, vamos a reportar los cambios al server. Como ya se mencionó antes, esta operación se denomina commit, y se realiza desde el directorio del proyecto, ejecutando: 4

5 svn commit Esto generará que se abra la aplicación de edición de texto predefinida en el sistema, para que pueda documentar los cambios realizados y registrar cualquier información que crea puede ser necesaria a futuro. Como esta información se podrá consultar en el historial, poner notas y observaciones a tener en cuenta a futuro, ayudamemorias, y esa clase de anexos es una buena idea. Finalizada la documentación del commit, la salida será: Sending pepe.txt Transmitting file data.. Committed revision 7. Y listo, el servidor tendrá las versiones de los archivos con los cambios que hemos realizado, que se trasladarán a los otros integrantes del proyecto cuando ellos sincronicen sus copias locales. Ahora, supongamos que en vez de un par de horas, estuvimos trabajando un par de días en los archivos. Y que otro miembro del proyecto haya realizado un commit para reportar cambios al repositorio. Esto es perfectamente probable, ya que como se mencionó antes, el sistema es concurrente, y normalmente vamos a conservar nuestros archivos locales, no vamos a borrarlos y descargarlos cada vez que empecemos a trabajar. Cómo ya se mencionó antes, esta operación se denomina update, y se realiza desde el directorio del proyecto, ejecutando: svn update Supongamos que obtengo una salida como la siguiente: U pepe.txt Updated to revision 7. Esto significa que alguien realizó un commit con cambios en el archivo pepe.txt. Y que el sistema actualizó la copia local con esos cambios, es decir, que ya tenemos en nuestro disco rígido las modificaciones que realizó otro integrante del proyecto. Es una buena práctica la de realizar update periodicamente, especialmente al empezar a trabajar, para poder estar seguros que trabajamos sobre la versión más actualizada del proyecto. Si queremos ver quien realizó la modifiación, y sus comentarios, debemos ejecutar: svn log La salida nos indicará de forma detallada que usuario realizó el commit, la fecha, la revisión y los comentarios. Por esto es que es muy importante detallar el trabajo realizado, no solo para recordatorio personal, sino para que el resto de los integrantes puedan rastrear potenciales problemas generados por nuestro commit. MUY IMPORTANTE: Nunca se debe hacer un commit de un código que no compile. Hay que ser conscientes de que hacer esto hace que no le compile a nadie más, con el agravante de que el resto tiene que adivinar de dónde vino el problema. Un comando más que puede ser útil, es el comando de status. Este nos muestra las diferencias entre la copia local y el repositorio, tomando como referencia la versión del último update. Simplemente detalla que archivos fueron modificados localmente, y si hay archivos locales que no están en el sistema de versiones, o archivos faltantes. $ svn status? basicdsp.cpp? prueba! pepe.txt 5

6 En este caso, los signos de pregunta indican archivos que existen en el directorio local, pero que no están dentro de la lista de control del svn, y que por lo tanto no se sincronizan con el repositorio. El signo de admiración representa un archivo faltante, que se puede reestablecer con un update. Esta situación puede darse cuando renombramos un file, por ejemplo, o cuando se borra intencionalmente para hacer marcha atrás con todos los cambios realizados. En este caso, se borró el archivo pepe.txt Es importante entender que borrar o renombrar un archivo local NO significa borrar o renombrar un archivo en el repositorio. Para borrar o agregar archivos, hay que usar otros comandos, que se explicarán a continuación Cómo crear un proyecto Supongamos que tenemos un directorio local, en /usr/src/proyecto4, que quiero agregar al repositorio. Lo primero que vamos a hacer es generarle un directorio en el mismo con el comando: svn mkdir Ahora, desde el directorio local que contiene el subdirectorio del proyecto que vamos a subir (es decir, desde /usr/src), hacemos un checkout del directorio que creamos en el repositorio. Esta operación es simplemente para poner el directorio local dentro del svn, y no debería afectar los archivos fuente contenidos en él, ya que está vacio en el repositorio. svn checkout Ahora ya tenemos en el directorio local de proyecto, el subdirectorio.svn que indica que está dentro de un sistema de control de versiones. No obstante, si revisamos el status del proyecto, todos los archivos locales estarán marcados como fuera de la lista de control del.svn. Para agregarlos, y por ende incluirlos en los futuros commit y updates, debemos ejecutar el siguiente comando: svn add archivo1.c archivo1.h... Una vez agregados todos los archivos, al realizar un commit se actualizarán en el repositorio, y estarán sujetos a las reglas de uso del sistema descriptas en la sección anterior. Análogamente, si quisieramos sacar un archivo, debemos ejecutar el comando: svn delete archivo1.c Se debe recordar que todos los cambios realizados, archivos agregados y removidos no se trasladan al repositorio de forma automática, sino cuando se realiza un commit. Otra forma de agregar un proyecto es usando el comando import. Este realiza la operación anterior de forma automática, y agrega todo el directorio local al repositorio, de forma completa. Por lo tanto, es necesario ser cuidadoso al utilizarlo, ya que puede generar una transferencia de un volumen de datos importante, incluyendo archivos binarios y demás, que no siempre suele ser conveniente que estén en el sistema. Siempre es necesario recordar que este sistema está pensado para archivos de código fuente, no para binarios compilados 4. Servidor de pruebas El servidor con el cuál se ilustran los ejemplos anteriores estará disponible durante las primeras semanas de la cursada, para que los alumnos puedan probar y practicar con el sistema. 6

7 La dirección para que prueben es, por lo tanto, El usuario y el password son los que utiliza el alumno en el Sistema de Gestión Electrónica. Es importante tener en cuenta que cuando se desactive, se borrará el contenido y no se realizará backup del mismo. Si los alumnos tuvieran archivos de código en el mismo, deberán subirlos nuevamente al nuevo servidor. 5. Implementación para TP s Existirá un repositorio de subversion para cada curso, identificado por el día de la semana en que se dictan clases. Es decir, existirán los siguientes 5 (cinco) repositorios: Cada alumno utilizará para realizar las operaciones del sistema el username y el password que utiliza en el SGE. Es responsabilidad del alumno contactarse con el personal del Departamento de Electrónica, si no estuviese aún registrado en el sistema, y gestionar su usuario y clave para poder cumplir con los trabajos prácticos de la materia. Dentro del repositorio correspondiente a su curso, cada estudiante tendrá un directorio con su nombre de usuario, dónde deberá realizar los trabajos prácticos. Se entiende por realizar, el ir actualizando periodicamente el código fuente, a medida que vaya avanzando con los diferentes problemas de la guia de TP. El alumno sólo tendrá permisos de acceso sobre su directorio, y no podrá acceder al resto de los directorios de los otros alumnos del curso, ni a los repositorios de los otros cursos. Cada docente será el encargado de administrar los directorios de su curso. Para esto deberá contar con el nombre del usuario del alumno. El docente NO TENDRA acceso a la clave del alumno, que se gestionará y administrará por los canales normales del Departamento y su sistema de gestión. Los trabajos prácticos son de entrega individual, y parte de la evaluación práctica de la materia. Por lo tanto, se evaluará y calificará al alumno por el contenido del directorio que tiene asignado, no pudiendo otros alumnos realizar trabajos en él. Cada docente tendrá acceso completo al repositorio de su curso, para poder evaluar y medir el avance de la actividad de los alumnos. La evaluación se complementará, de ser necesario, con una breve interpelación sobre el trabajo realizado durante alguna de las clases prácticas, pudiéndo requerirse que el alumno realice correcciones o cambios al código durante la misma. Se recomienda que el alumno genere una estructura de subdirectorios para ordenar sus archivos de código fuente, para facilitar el trabajo y el control del docente. IMPORTANTE El sistema permite registrar la actividad por usuario, identificando quién y cuándo realizó los cambios, y que modificaciones realizó. En caso de registrarse irregularidades, se sancionará a los alumnos involucrados según las normas de la Universidad Tecnológica Nacional. 6. Ejercicio de prueba En el repositorio de pruebas genere un archivo de texto que se llame como el día de la semana que cursa, y agregue en el mismo una línea con los siguientes datos: usuario de SGE, legajo y dirección de correo electrónico. 7