5 %center, size 7, font "standard", back "white", fore "black"
10 Todo lo que siempre quiso saber sobre SCMs
11 y nunca se animó a preguntar
15 Leandro Lucarella (luca@llucax.hn.org)
16 Alberto Bertogli (albertogli@telpin.com.ar)
27 Devuelvanme los colores! Viva Rainbow Brite!
28 Motivación (estamos motivaaaaaaadooosssss!)
29 Subjetividad (acaso existe una opinión distinta a la nuestra?)
33 El proceso de desarrollo de software
35 Proceso social y creativo
36 Concentrarnos en el código fuente y no en metodologías
37 Construcción iterativa y lógica
38 Evolución del software con cambios
39 Changesets, porque los nombres tienen que tener onda
46 Coordinación del trabajo
47 Imprescindible la buena comunicación y coordinación
48 Complejidad respecto del código: trabajo en simultáneo
49 Relaciones asimétricas y flujo de trabajo
56 Poder ver qué cambios fueron introducidos
57 Revisión y abstracción
58 Capacidad de manejar y leer changesets
59 Representación del código como una base y su conjunto de changesets
63 Dejemos de mentir un poco y veamos la realidad
70 Herramientas más viejas y usadas
73 Formato unificado del diff
75 Operación "a pulmón" con estas herramientas
80 Sistemas para la administración de código fuente
82 Vimos la importancia de manejar y administrar changesets
83 A eso vinimos: a hablar de los sistemas que los administran (como? esto no es Análisis II??? <<huida despavorida>>)
84 Formas de llamarlos (se acuerdan de las siglas copadas?): SCM, VCS, CMS
85 Objetivo básico de los SCMs
87 Aplicación de changesets
92 Manipulando repositorios
95 Aplicación de changesets en distintos branches
96 Merges: integración de cambios
102 Historia de un repositorio
104 Importancia de la historia de la evolución del código
106 Grupos con estructuras jerárquicas
109 Aprender de los aciertos y errores anteriores
112 Ver quién manipuló el código
118 Dos formas de ver a los SCMs
120 Formas de encarar el problema en la práctica
125 Una viñetita nada más? Qué vergüenza!!!
132 Un sólo repositorio con todas las letras
133 El repositorio central incluye los branches
134 Working copy, un branch "rarito"
135 Noción de línea de tiempo
136 Al haber un servidor el setup suele ser más complejo
137 La mayoría de las operaciones necesitan conexión
142 Caso de estudio: Subversion
144 Características generales
146 Evolución natural de CVS (migración fácil)
147 Clientes para todos los gustos
148 Modelo Copy-Modify-Merge
149 Filosofía "El espacio en HD es más barato que el BW" (operación "offline siempre que sea posible)
150 Filesystem versionado
151 Muy bueno porque es muy flexible
152 Muy malo porque es muy flexible
153 "Copias baratas" (cheap copy) como mecanismo de branching
154 Conviene elegir un esquema al crear un repositorio
155 Propiedades (metainformación)
156 Propiedades especiales: ignore, keywords, executable, eol-style, mime-type, externals
157 Propiedades muy muy especiales: author, log, date, revision, etc...
158 Propiedades arbitrarias (para la gente creativa)
165 No existe un repositorio central, son todos pares
166 No necesariamente basados en líneas de tiempo
167 Permiten el trabajo "offline"
168 Se concentran en mantener la historia
169 El merge cobra mayor importancia
174 Caso de estudio: Darcs
176 Características generales
177 Basado en una teoria de patches magica
178 Muy facil de usar y de entender
179 Flexible y transparente con los repositorios
180 Los branches son simples copias del repositorio
181 Orientado a cambios mas que a versiones
183 Simplifica el trabajo en paralelo
184 Flujos de trabajo distribuidos
191 Para los que todavía estén despiertos...