SCMs: Mitos y verdades
Todo lo que siempre quiso saber sobre SCMs
y nunca se animó a preguntar
Leandro Lucarella (llucare@fi.uba.ar)
Alberto Bertogli (albertogli@telpin.com.ar)
LUGFI
18 de Mayo de 2005
(página 1)
Introducción
- Devuelvanme los colores! Viva Rainbow Brite!
- Motivación (estamos motivaaaaaaadooosssss!)
- Subjetividad (acaso existe una opinión distinta a la nuestra?)
(página 2)
El proceso de desarrollo de software
- Proceso social y creativo
- Concentrarnos en el código fuente y no en metodologías
- Construcción iterativa y lógica
- Evolución del software con cambios
- Changesets, porque los nombres tienen que tener onda
(página 3)
Grupos de trabajo
- Coordinación del trabajo
- Imprescindible la buena comunicación y coordinación
- Complejidad respecto del código: trabajo en simultáneo
- Relaciones asimétricas y flujo de trabajo
(página 4)
Capacidad de revisión
- Poder ver qué cambios fueron introducidos
- Revisión y abstracción
- Capacidad de manejar y leer changesets
- Representación del código como una base y su conjunto de changesets
- Historial de cambios
- Dejemos de mentir un poco y veamos la realidad
(página 5)
diff + patch
- Herramientas más viejas y usadas
- diff
- patch
- Formato unificado del diff
- Lectura de diffs
- Operación "a pulmón" con estas herramientas
(página 6)
Sistemas para la administración de código fuente
- Vimos la importancia de manejar y administrar changesets
- A eso vinimos: a hablar de los sistemas que los administran (como? esto no es Análisis II??? <>)
- Formas de llamarlos (se acuerdan de las siglas copadas?): SCM, VCS, CMS
- Objetivo básico de los SCMs
- Repositorios
- Aplicación de changesets
(página 7)
Manipulando repositorios
- Branches
- Aplicación de changesets en distintos branches
- Merges: integración de cambios
- Conflictos
(página 8)
Historia de un repositorio
- Importancia de la historia de la evolución del código
- Revisión de cambios
- Grupos con estructuras jerárquicas
- Revisión entre pares
- Colaboración
- Aprender de los aciertos y errores anteriores
- Backtracking de bugs
- Tests de regresión
- Ver quién manipuló el código
- Pensar en changesets
(página 9)
Dos formas de ver a los SCMs
- Formas de encarar el problema en la práctica
- Distribuidos
- Centralizados
- Una viñetita nada más? Qué vergüenza!!!
(página 10)
SCMs Centralizados
- Un sólo repositorio con todas las letras
- El repositorio central incluye los branches
- Working copy, un branch "rarito"
- Noción de línea de tiempo
- Al haber un servidor el setup suele ser más complejo
- La mayoría de las operaciones necesitan conexión
(página 11)
Caso de estudio: Subversion
- Características generales
- Un nombre re copado
- Evolución natural de CVS (migración fácil)
- Clientes para todos los gustos
- Modelo Copy-Modify-Merge
- Filosofía "El espacio en HD es más barato que el BW" (operación "offline siempre que sea posible)
- Filesystem versionado
- Muy bueno porque es muy flexible
- Muy malo porque es muy flexible
- "Copias baratas" (cheap copy) como mecanismo de branching
- Conviene elegir un esquema al crear un repositorio
- Propiedades (metainformación)
- Propiedades especiales: ignore, keywords, executable, eol-style, mime-type, externals
- Propiedades muy muy especiales: author, log, date, revision, etc...
- Propiedades arbitrarias (para la gente creativa)
(página 12)
SCMs Distribuidos
- No existe un repositorio central, son todos pares
- No necesariamente basados en líneas de tiempo
- Permiten el trabajo "offline"
- Se concentran en mantener la historia
- El merge cobra mayor importancia
(página 13)
Caso de estudio: Darcs
- Características generales
- Basado en una teoria de patches magica
- Muy facil de usar y de entender
- Flexible y transparente con los repositorios
- Los branches son simples copias del repositorio
- Orientado a cambios mas que a versiones
- Formas de trabajo
- Simplifica el trabajo en paralelo
- Flujos de trabajo distribuidos
(página 14)
Ejemplos!
- Para los que todavía estén despiertos...
(página 15)