Manejo De Control De Versiones

:)

Equipo Eclipse somos:

Elizabeth Duran Leyva moc.liamg|otreicnoc.ne.anom#moc.liamg|otreicnoc.ne.anom
Carlos Aguilar Castañeda moc.liamtoh|2acip_uhcacip#moc.liamtoh|2acip_uhcacip
Gutberto Ramíriez Hernández moc.liamtoh|onileusoj#moc.liamtoh|onileusoj
Rene Montoya Flores moc.liamtoh|57ognalyhc#moc.liamtoh|57ognalyhc

Control de Versiones

Control de versiones es la gestión de las actualizaciones continuas de software y los métodos que se emplean, para tener resultados óptimos y correctos con ello.

Cuando se está desarrollando un proyecto de programación, uno quisiera hacer una marca en el proyecto cuando se tiene un punto estable; o sea guardar una versión preferentemente correcta del proyecto. La idea de guardar versiones es que si los nuevos cambios quedan mal, la marca nos servirá para volver al punto estable y recomenzar desde ahí. Si las cosas salen bien y se alcanza una nueva estabilidad, se pone otra marca.

El problema es aún más difícil si trabajamos con más personas en el mismo proyecto. ¿Cómo mezclar el trabajo de todos de forma que quede consistente? La solución es utilizar un sistema de control de versiones

El sistema funciona de la siguiente manera. Se crea un repositorio central al cual todos los involucrados en el proyecto tienen acceso. El repositorio es administrado por un programa que decide como mezclar los cambios hechos por los programadores.

Cada programador tiene una copia local del proyecto sobre la cual trabaja. Las copias locales se crean haciendo un checkout. Una vez que los cambios introducidos al proyecto de manera local funcionan, éstos se envían al repositorio. Al envío le llamamos un commit. Así, el repositorio mantiene la versión más actualizada del proyecto. Cada programador realiza una actualización de su propia copia local pidiéndosela regularmente al repositorio, lo que se llama update.

Existen muchos programas que están enfocados al control de versiones, algunos de ellos son:

SVK
AccuRev
Aldon
Alienbrain
BzrEclipse
CVS
CVSNT

Synergy
Razor
SourceAnywhere
SourceHaven
StarTeam
Subversion

GNU
Surround SCM
SVK
Synergy
Team
Vault
Visual SourceSafe

Esta ocasión analizaremos solo 3 de ellos: SCCS, CVS, GIT.

SCCS - abuelo de los sistemas de control de versiones, muy usado por programadores de C. Es bueno conocerlo para saber las bases y los orígenes del control de versiones

CVS - El que usan desarrolladores de java en la actualidad

Subversion - A donde todos quieren llegar

GIT - competidor de Subversion.

SCCS, Source Code Control System.
Sistema para Control de Código Fuente.

SCCS fue el primer Sistema para control versiones. Fue desarrollado originalmente en los Laboratorios Bell en 1972 por Marc J. Rochking para un Sistema IBM/370 corriendo OS/MVT, después se reescribió para Unix, posteriormente se utilizó en unaPDP-11. Subsecuentemente se incluyó en muchas distribuciones de UNIX. El conjunto de comandos SCCS es ahora parte de la Single Unix Specification.

SCCS fue el sistema dominante de control de versiones hasta la liberación de “Revision Control System”. Hoy en día, SCCS se considera obsoleto. Sin embargo, su formato de archivo es usado internamente por algunos otros programas de control de revisión, incluida BitKeeper y TeamWare. Sablime también permite el uso de archivos SCCS. El formato de archivo de almacenamiento SCCS utiliza una técnica llamada “Interleaved deltas” (“deltas entrelazado” o “tejido”). Esta técnica de almacenamiento es ahora considerado por muchos desarrolladores como la clave para el desarrollo de técnicas avanzadas en Control de Versiones, y su fusión con nuevas técnicas para creación de nuevos modelos, por ejemplo “Precise Codeville” (o pcdv).

Estos son algunos de los primeros Sistemas UNIX que incluyeron SCCS:
Programer’s Workbench UNIX
UNIX system III
UNIX system V

GNU CSSC ("Compatibly Stupid Source Control"), Software que permite la conversion de archivos SCCS (considerados obsoletos) a versiones CVS o Subversion. No se recomienda su uso con proyectos nuevos

El Tejido:
Normalmente se utiliza teniendo en cuenta que estamos trabajando con archivos de texto, aunque nada impide que se aplique en archivos binarios. En este, el archivo contiene todas las líneas entretejidas del texto que existieran en cualquiera de las revisiones del archivo, con un seguimiento continuo de los cambios realizados en las instrucciones, indicando que líneas se modifican en que revisión del archivo. Ej.

/* Autor */ Rev 1^A

/* Autor Me@*/Rev^2A

/* Autor Me, Ver 3.0@*/Rev^1B

#include <stdio.h> main() / Rev 1^A Rev^2A Rev^1B

int x = 0;{ Rev 1^A Rev^2A Rev^1B

char a = G Rev^2A Rev^1B

G = get char; Rev^2A Rev^1B

if (G==2) Rev^2A ; Rev^1B

{ Rev^2A

} Rev^2A

printf ("Hola Mundo\n" & o) ; Rev 1^A

printf ("Hola Mundo, Esoy feliz\n") ; Rev 1^A Rev^2A Rev^1B

return 0; Rev 1^A Rev^2A Rev^1B

} Rev 1^A Rev^2A Rev^1B

El tiempo que toma la reconstrucción de cualquier revisión, es proporcional al tamaño del archivo. Mientras más grande es archivo más difícil es convertirlo a caracteres. Pero en general crece con cada nueva revisión en proporción al número de líneas que se modificaron de la nueva versión con respecto a la anterior.

El método de tejido tiene la ventaja restaurar los cambios a un momento dado en cada una de las revisiones de un archivo. Desafortunadamente ya no es sea un método que se utilice demasiado, además es difícil de implementar y actualmente ya se encuentra en muy pocas implementaciones de código abierto, si es que todavía hay y que estén disponibles.

Subversion

Subversion es un software de sistema de control de versiones diseñado específicamente para reemplazar al CVS. Es software libre bajo una licencia de tipo Apache/BSD y se lo conoce también como svn por ser ese el nombre de la herramienta de línea de comandos. Una característica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un número de revisión independiente. En cambio, todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en cierto punto del tiempo.

Free software/open source, con respaldo empresarial (CollabNet)
Multiplataforma (Windows, Linux, Mac OS, … )
Sucesor natural de CVS
Probada robustez
Usado por la mayoría de los proyectos de software open source más grandes
KDE
GCC
Apache

Adoptado por grandes empresas
Desarrollo constante.No, creo que le toco subversion.

Ventajas

  • Se sigue la historia de los archivos y directorios a través de copias y renombrados.
  • Las modificaciones (incluyendo cambios a varios archivos) son atómicas.
  • La creación de ramas y etiquetas es una operación más eficiente.
  • Tiene costo de complejidad constante (O(1)) y no lineal (O(n)) como en CVS.
  • Se envían sólo las diferencias en ambas direcciones (en CVS siempre se envían al servidor archivos completos).
  • Puede ser servido mediante Apache, sobre WebDAV/DeltaV. Esto permite que clientes WebDAV utilicen Subversion en forma transparente.
  • Maneja eficientemente archivos binarios (a diferencia de CVS que los trata internamente como si fueran de texto).
  • Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse fácilmente, conviene que no sean editados por más de una persona a la vez.
  • Cuando se usa integrado a Apache permite utilizar todas las opciones que este servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM, etc.).

Trabajo colaborativo

Muchas personas pueden estar trabajando sobre el mismo proyecto.

Cada uno sobre una parte distinta, pero sólo funciona como la suma de los esfuerzos.

Copia local permite cierto grado de independencia.

Hacer cambios, cometer errores y corregirlos.

Hasta que no haga commit, nadie se entera.

Libre de jugar con todos los documentos sin molestar a nadie.

Desventajas

El manejo de cambio de nombres de archivos no es completo. Lo maneja como la suma de una operación de copia y una de borrado.

*Subversion no implementa algunas operaciones administrativas.
*Subversion requiere que cada carpeta en el lado del cliente incluya una carpeta oculta".svn".
*No resuelve el problema de aplicar repetidamente parches entre ramas, no facilita el llevar la cuenta de qué cambios se han trasladado. Esto se resuelve siendo cuidadoso con los mensajes de commit.

EJEMPLO

Ana, Beto y Carlos pueden estar trabajando en componentes interrelacionadas. Si Ana hizo commit de un cambio, y Beto y Carlos están en su propio trabajo,

¿Cómo se enteran del commit que realizó Ana?

Beto y Carlos deben, periódicamente, preguntar si hubo cambios:

Efectúan update sobre sus copias locales

Ahora su copia local está sincronizada con los últimos cambios

Deben revisar si su trabajo está consistente con las nuevas versiones.

Si Beto o Carlos olvidan hacer update, e intentan hacer commit de sus cambios, SVN no los deja.

Es necesario tener la última versión de lo demás y verificar que los cambios tienen sentido.

/Trabajar sobre un mismo documento/

Es probable que Ana y Beto trabajen a la vez en el mismo documento. Su copia local se encuetra desconectada del repositorio y ninguno de los dos sabes que están trabajando en el mismo documento.

Pueden pasar varias cosas:

1. Uno de los dos revierte sus cambios.
2. Uno de los dos puede tomar un lock sobre el documento y nadie más puede editarlo hasta que lo libere.
3. Ana hace commit de sus cambios antes que Beto y existe una Pposibilidad de conflicto.

Conflictos y merging

Si Ana cambia el documento sobre el cual está trabajando B, puede haber un conflicto

Le cambiaron la base común a Beto!.

Afortunadamente, SVN puede resolver el problema automáticamente en muchos casos.

Al detectar el problema en B, intentará hacer un merge(fusión) de los cambios de ambos.

Si Ana cambio el capítulo 1, y B está trabajando sobre el 2, no hay razón por la cual no se puedan combinar ambos cambios.

La trampa: Sólo funciona para algunos tipos de documentos SVN solo puede interpretar archivos de texto plano!

… pero los casos más comunes (código de programas de computador) lo son!.

Conflictos sin solución

Si Ana y Beto cambiaron la misma sección del texto, o SVN no puede. entender el archivo, no puede hacer nada.

Avisa: hay conflicto, humano debe resolverlo.

Entrega ambas versiones de documentos en conflicto.

Pide que le avisen cuando esté resuelto.

Buenas prácticas para trabajar en equipo.

Hay una serie de pasos que es recomendable seguir al momento de hacer un commit.

¿Cómo quiero que se vean mis cambios en la historia?.

Que los cambios sean en incrementos completos y cohesionados.

Mejor hacer muchos commits pequeños que uno grande.

No debo romper el código para mis compañeros que están trabajando en paralelo.

Ninguna revisión intermedia del repositorio debe estar “mala”.

Checklist antes de hacer commit.

1. ¿Están agregados todos los archivos nuevos que yo pueda haber creado?.

No agregar archivos temporales, generados, etc.

2. ¿El nuevo estado resultante es “consistente” (compila)?.

3. Hacer update para verificar sincronización.

Si había cambios externos, asegurarse de nuevo que compila, con los nuevos cambios.

4. ¿Los cambios son un incremento cohesionado? ¿Conviene quizás separarlo en dos transacciones?

5. ¿El mensaje de log es suficientemente descriptivo y claro?.

Algunas interfaces para Subversion.

TortoiseSVN. Provee integración con el explorador de Windows.
Subclipse. "Plugin" que integra Subversion al entorno Eclipse.
Subversive. "Plugin" alternativo para Eclipse.
Cervisia Programa para interacción para linux, combinada con Quanta Plus.
ViewVC. Interfaz web, que también trabaja delante de CVS.
Para mac, pueden emplearse los interfaces SvnX, RapidSVN y Zigversion
RapidSVN también corre en Linux.
KDESvn. Provee integración con el escritorio KDE a TortoiseSVN
EasyEclipse es un paquete basado en eclipse, con algunos plugins de código abierto.
sventon Interfaz web.

Puntos importantes para recordar.

*Desarrollo en equipo.
*Integración de cambios(merge).
*Guarda historial.
*Recuperación de versiones.

GIT

Git es un software de sistema de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y confiabilidad de mantenimiento de versiones de aplicaciones con una enorme cantidad de archivos de código fuente.

El diseño de Git se basó en BitKeeper y en Monotone.[1] [2] En principio, Git se pensó como un motor de bajo nivel que otros pudieran usar para escribir front end como Cogito o StGIT.[3] Sin embargo, Git se ha convertido desde entonces un sistema de control de versiones con funcionalidad plena.[4] Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo del sistema operativo Linux.

Características

El diseño de Git resulta de la experiencia del diseñador de Linux, Linus Torvalds, manteniendo una enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación.

Entre las características más relevantes (no necesariamente positivas) se encuentran:

Fuerte incidencia en la no linealidad de los cambios, por ende rapidez en la gestión de ramificaciones y mezclado de diferentes versiones.

Gestión distribuida. Los cambios se importan como ramificaciones, y pueden ser mezcladas en la manera en que lo hace una ramificación del almacenamiento en local.

Los almacenes de información pueden publicarse por HTTP, FTP, SSH, rsync o mediante un protocolo nativo, aparte de ser posible emular CVS.

Resulta algo más caro trabajar con ficheros concretos frente a proyectos, eso diferencia el trabajo frente a CVS, que trabaja en base a cambios de fichero, pero mejora el trabajo con afectaciones de código que concurren en operaciones similares en varios archivos.

Los renombrados se trabajan en base a similitudes entre ficheros, aparte de nombres de ficheros, pero no se hacen marcas explícitas de cambios de nombre en base a supuestos nombres únicos de nodos de sistema de ficheros, lo que evita posibles, y posiblemente desastrosas, coincidencias de ficheros diferentes en un único nombre.

Realmacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (en base a diferencias) no ocurre cada cierto tiempo.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License