Universidad Simón Bolívar Sistemas de Operación II (CI-4821) Intensivo 2014 MANEJADORES DE CONTROL DE VERSIONES David Prieto Karen Troiano 08-10899 09-10855.

Presentación del tema: "Universidad Simón Bolívar Sistemas de Operación II (CI-4821) Intensivo 2014 MANEJADORES DE CONTROL DE VERSIONES David Prieto Karen Troiano 08-10899 09-10855."— Transcripción de la presentación:

1 Universidad Simón Bolívar Sistemas de Operación II (CI-4821) Intensivo 2014 MANEJADORES DE CONTROL DE VERSIONES David Prieto Karen Troiano 08-10899 09-10855

2 Agenda: Sistema de control de versiones (SCV) Definición Conceptos Básicos Evolución Características Clasificación CVS Subversion GIT

3 Definición de SCV Es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que se pueda recuperar versiones específicas de los mismos en un determinado momento. Un SVC posee tres capacidades importantes: Reversibilidad: Retornar a un estado anterior del proyecto en caso de fallas. Concurrencia: Muchas personas modificando el mismo código o documento. Anotación: Adjuntar información relevante de los cambios realizados.

4 Conceptos Básicos de SCV Repositorio: lugar en el que se almacenan los datos actualizados e históricos de cambios (sistema de archivos en un disco duro, un banco de datos, etc). Revisión: Versión determinada de la información que se gestiona. Tags: Permiten identificar de forma fácil revisiones importantes en el proyecto. Módulo: Conjunto de directorios y/o archivos dentro del repositorio que pertenecen a un proyecto común. Branch: Es una copia del proyecto aislada, de forma que los cambios realizados no afecten al resto del proyecto y vice versa, excepto cuando los cambios sean "unidos" de un lado al otro.

5 Conceptos Básicos de SCV Baseline: Una revisión aprobada de un documento o fichero fuente, a partir del cual se pueden realizar cambios subsiguientes. Checkout: Crea una copia de trabajo local desde el repositorio. Commit: Consiste en realizar un cambio local en el proyecto y luego almacenar dicho cambio en el repositorio. Merge: Une dos grupos de cambios en un archivo (o grupo de archivos), generando una revisión unificada. Conflicto: Sucede cuando dos o más personas intentan realizar diferentes cambios en la misma porción de código.

6 Conceptos Básicos de SCV Update: Integra los cambios que han sido realizados en el repositorio en la copia de trabajo local. Change set: Conjunto de cambios realizados en un único commit.

7 Evolución de SCV GeneraciónComunicaciónOperacionesConcurrenciaEjemplos PrimeraNingunaUn archivo a la vezBloqueosRCS, SCCS SegundaCentralizadaMultiarchivoMerge antes de Commit CVS, SourceSafe, Subversion TerceraDistribuidaConjunto de cambios Commit antes de Merge Bazaar, Git, Mercurial

8 Características de SCV Un sistema de control de versiones debe proporcionar: Mecanismo de almacenamiento de los elementos que deba gestionar. (Ejm: archivos de texto, imágenes, documentación...). Posibilidad de realizar cambios sobre los elementos almacenados. (Ejm: modificaciones parciales, añadir, borrar, renombrar o mover elementos). Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos (normalmente pudiendo volver o extraer un estado anterior del producto).

9 Clasificación de SCV Sistema de control de versiones locales: Información acerca de cambios se mantiene en un repositorio local.

10 Clasificación de SCV Sistema de control de versiones centralizados: Necesitan el uso de un servidor y repositorio central.

11 Clasificación de SCV Sistema de control de versiones distribuidos: Permiten el uso de múltiples repositorios, y sincronización entre ellos.

12 CVS CVS es el sucesor de RCS. Pertenece a la segunda generación de manejadores. Pasó a manejar proyectos completos en vez de un solo archivo. Desarrollado por Dick Grune y dos de sus alumnos (1984 y 1985). Escrito en C para trabajar en un compilador de C. Introduce el concepto de ramificación al control de versiones en CVS. La última versión fue publicada en el 2008. Todavía está en uso pero por la manera en que está implementado es inferior a los manejadores actuales.

13 CVS Solamente lleva el historial de ficheros individuales. Está limitado al versionado de ficheros, operaciones como copiar y renombrar no son soportadas. No puede reemplazar un fichero versionado con algo nuevo que lleve el mismo nombre sin que el nuevo elemento herede el historial del fichero antiguo. Los commits no son atómicos. Las operaciones de ramificación son muy costosas. No es distribuido.

14 Subversion Sistema de control de versiones libre. Código fuente abierto. Maneja ficheros y directorios a través del tiempo. Hay un árbol de ficheros en un repositorio central. El repositorio es como un servidor de ficheros ordinario, excepto porque recuerda todos los cambios hechos a sus ficheros y directorios. Puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. Fomenta la colaboración: capacidad para que varias personas puedan modificar y administrar el mismo conjunto de datos. Es un sistema general que puede ser usado para administrar cualquier conjunto de ficheros.

15 Historia de Subversion A principios del 2000: o CollabNet, Inc. comenzó a buscar desarrolladores para escribir un sustituto para CVS. En febrero del 2000: o Contacto con Karl Fogel y con su amigo Jim Blandy. o Ambos estaban frustrados con CVS. o Ya tenían el nombre de “Subversion” y el diseño básico del repositorio de Subversion. En mayo del 2000: o Collabnet contrató a Karl y a Ben Collins-Sussman, y el trabajo detallado de diseño comenzó. o Subversion atrajo rápidamente a una comunidad activa de desarrolladores. Esto vino a demostrar que era mucha la gente que había tenido las mismas frustrantes experiencias con CVS, y que había recibido con agrado la oportunidad de hacer algo al respecto.

16 Historia de Subversion No querían abrir nuevos caminos en la metodología del control de versiones, sólo querían corregir CVS. Después de catorce meses de codificación Subversion pasó a ser “auto-hospedado” el 31 de agosto del 2001. Es decir, los desarrolladores de Subversion dejaron de usar CVS para la administración del propio código fuente de Subversion, y en su lugar empezaron a usar Subversion.

17 Características de Subversion Versionado de directorios. o CVS solamente lleva el historial de ficheros individuales, o Implementa un sistema de ficheros versionado “virtual” que sigue los cambios sobre árboles de directorios completos a través del tiempo. Verdadero historial de versiones. o Con Subversion, usted puede añadir, borrar, copiar, y renombrar ficheros y directorios. Y cada fichero nuevo añadido comienza con un historial nuevo, limpio y completamente suyo. o CVS no hacía esto. Envíos atómicos. Versionado de metadatos. o Cada fichero y directorio tiene un conjunto de propiedades —claves y sus valores — asociado a él.

18 Características de Subversion Elección de las capas de red. o Tiene una noción abstracta del acceso al repositorio, facilitando a las personas implementar nuevos mecanismos de red. o Puede conectarse al servidor HTTP Apache como un módulo de extensión. o Tiene disponible un servidor de Subversion independiente, y más ligero. Manipulación consistente de datos. o Expresa las diferencias del fichero usando un algoritmo de diferenciación binario, que funciona idénticamente con ficheros de texto y ficheros binarios. o Ambos tipos de ficheros son almacenados igualmente comprimidos en el repositorio.

19 Características de Subversion Ramificación y etiquetado eficientes. o El coste de ramificación y etiquetado no necesita ser proporcional al tamaño del proyecto. Hackability. o Está implementado como una colección de bibliotecas compartidas en C con APIs bien definidas. o Esto hace a Subversion extremadamente fácil de mantener y reutilizable por otras aplicaciones y lenguajes.

20 GIT ¿Qué es GIT? Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente. Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux.

21 Historia de GIT Núcleo de Linux (1991): o Durante el mantenimiento de este Software, los cambios realizados se pasaron en forma de parches y archivos. BitKeeper (2002): o El proyecto del núcleo de Linux empezó a usar un sistema de control de versiones propietario llamado BitKeeper. Inicios (2005): o La relación entre la comunidad que desarrollaba el núcleo de Linux y la compañía que desarrollaba BitKeeper se vino abajo, y la herramienta dejó de ser gratuita. o La comunidad de desarrollo de Linux crea una herramienta de control de versiones inspirada en BitKeeper y Monotone. o GIT está escrito en C, Bourne Shell y Perl. o Software libre bajo la licencia GNU.

22 Objetivos de GIT Algunos de los objetivos del nuevo sistema fueron los siguientes: Velocidad. Diseño sencillo. Fuerte apoyo al desarrollo no lineal (miles de ramas paralelas). Completamente distribuido. Capaz de manejar grandes proyectos (como el núcleo de Linux) de manera eficiente (velocidad y tamaño de los datos).

23 Características de GIT Casi cualquier operación es local. Tiene integridad. o Todo en Git es verificado mediante una suma de comprobación antes de ser almacenado, y es identificado a partir de ese momento mediante dicha suma. o El checksum es generado mediante el hash SHA-1 que consiste en una cadena de 40 caracteres hexadecimales. Generalmente solo añade información. Tres estados o Confirmado (committed): Los datos están almacenados de manera segura en tu base de datos local. o Modificado (modified): Has modificado el archivo pero todavía no lo has confirmado a tu base de datos o Preparado (staged): Has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.

24 Secciones de GIT El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para tu proyecto. Es lo que se copia cuando clonas un repositorio desde otro ordenador. El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar. El área de preparación es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación.

25 Operaciones de GIT

26 Diferencias principales Tienden a almacenar los datos como cambios de cada archivo respecto a una versión base. Se almacena la información como instantáneas del proyecto a lo largo del tiempo.