2 INTRODUCCIÓN A LOS SISTEMAS DE CONTROL DE VERSIONES
3 ===================================================
6 El proceso de desarrollo de software
7 ------------------------------------
9 Creo que es importante comenzar mencionando que el desarrollo de software no
10 sólo es un proceso inherentemente social y creativo, y como tal tenemos que
11 hacernos de la idea de que la mayoría de los problemas que acarrea son de esta
14 Comencemos por sentar una base común acerca de como se suele desarrollar
15 software. Esto no tiene nada que ver con todas esas metodologías horrorosas
16 (Extreme programming, Unified Process, etc, etc), sino con como, en el fondo,
17 se realiza ese proceso desde el punto de vista de la evolución del código.
19 Ya sea que trabajemos en grupo o de forma individual, todos comenzamos con una
20 hoja en blanco y una idea en la cabeza, que a medida que progresamos va
23 En el caso del software, nosotros en esta charla nos vamos a concentrar un
24 poco en el código fuente, y no vamos a hablar tanto del tema de diseño o
25 arquitectura de software porque no nos atañe, robaría mucho tiempo y podemos
26 enfocarnos en lo que queremos explicar sin necesidad de entrar en esos temas.
28 Por lo tanto, nosotros arrancamos con un directorio vació, en el cual vamos
29 escribiendo, construyendo nuestro software de forma incremental e iterativa,
30 corrigiendo nuestros propios errores a medida que aparecen, y agregando cosas
31 nuevas cuando se nos place.
33 Detengamonos un poco acá y miremos mejor que pasa con nuestro código a medida
34 que vamos avanzando en un proyecto: nuestro código va evolucionando, cambiando
35 con iteraciones pequeñas que nosotros vamos introduciendo por diversos motivos
36 (normalmente correcciones o características nuevas), porque esa es la manera
37 en la que vemos y pensamos al software: es como si tuviéramos una escultura
38 que tiene una forma determinada y nosotros por nuestras arbitrarias razones la
39 queremos ir modificando.
41 Por lo tanto, podemos pensar que el software se va construyendo en base a
42 modificaciones incrementales que nosotros vamos haciendo. Pero aun más, una
43 cosa esencial es que esos cambios no son desordenados ni desorganizados
44 (aunque hay cada uno!): se corresponden con alguna construcción mental
45 nuestra, porque cuando nosotros pensamos en implementar algo o corregir un
46 bug, lo tenemos en mente como una unidad, como un objetivo bastante
47 independiente de como se representa en el código fuente; y nosotros pensamos
48 en que cambios le tenemos que realizar para lograr ese objetivo propuesto.
50 Y ese proceso, esa forma de ver las modificaciones es lo que hace que
51 desarrollemos de la manera en la que lo hacemos, más allá de que a otro nivel
52 se usen esos métodos que (ridículamente) se suelen modelar y estudiar, en el
53 fondo uno piensa las cosas de esa manera, de la misma forma que un escultor
54 piensa en una nariz, unos ojos, un pliegue de una manta o un gesto con la
55 mano, y es capaz de ver tanto los objetos individuales como el conjunto que
58 Vamos a bautizar esos cambios de los que estuvimos hablando, porque acá si las
59 cosas no tienen un nombre con onda y/o una sigla, nadie les da bola. Nosotros
60 dijimos que pensábamos en los cambios como una entidad en sí misma, y vamos a
61 llamar "changeset" a eso: a un grupo de cambios que se realizan sobre una base
62 de código, todos orientados a un fin en común.
69 Cuando trabajamos en grupo, surge la necesidad de coordinar el trabajo, no
70 sólo por una cuestión natural sino también como mecanismo de optimizar los
71 recursos: cuando faltan dos días para entregar un trabajo, absolutamente nadie
72 quiere perder tiempo, y menos si eso implica que dos personas hayan estado
73 trabajando toda una tarde sobre lo mismo.
75 Por eso, para desarrollar en grupo es imprescindible la buena comunicación y
76 entendimiento entre los pares. Esto implica que, en general, los desarrollos
77 se dan de forma coordinada (ya sea de manera horizontal o vertical,
78 independientemente del mecanismo que se elija explícita o implícitamente para
79 ello) al menos en un nivel social, las tareas se reparten y los cambios se
80 discuten donde afectan al grupo para facilitar el trabajo.
82 Claro que el desarrollar en grupo, por más que uno se lleve maravillosamente
83 bien con la gente involucrada, acarrea ciertas incomodidades que sí son más
84 técnicas, y que van a constituir gran parte de lo que vamos a hablar acá: al
85 haber más de una persona modificando el código fuente de forma simultanea,
86 existe una complejidad, y nada menor, en lo que refiere al hecho de
87 sincronizarlo y mantenerlo coherente entre todos los miembros del grupo.
89 También se dan en un grupo de trabajo relaciones asimétricas respecto del
90 código, debido a que cada grupo tiene una forma y un flujo de trabajo
91 particular, en el cual, por ejemplo, se pueden dar relaciones jerárquicas,
92 revisión de código entre pares, subgrupos, etc.
94 Esto va a reflejarse en el código fuente con el surgimiento de una nueva
95 necesidad, que va a ser la de la integración de múltiples trabajos
96 individuales, la distribución del mismo en distintas maquinas y la
97 coordinación para que todos puedan trabajar sobre la misma base de código.
100 Capacidad de revisión
101 ---------------------
103 Justamente con los grupos es donde se ve más fácil una cuestión de gran
104 importancia, que es la capacidad de revisión, nombre con el que hacemos
105 referencia a tener la posibilidad de ver lo que hicieron los otros, no sólo
106 para echarles la culpa (idealmente, esa debería ser la razón menos necesaria
107 de todas), sino porque es muy importante tener en perspectiva que fue lo que
108 hicieron los demás para el trabajo que realiza uno.
110 Se suelen decir maravillas de la abstracción y todo ese tipo de
111 construcciones, pero no hay que perder de vista que, si bien son buenos
112 conceptos, el tener una perspectiva amplia y completa de lo que se está
113 haciendo y con lo que se está interactuando suele ser beneficioso para todos.
114 Siguiendo con la analogía del escultor, es como si un grupo de escultores se
115 decidiera a trabajar con una pieza, tuvieran los planos, dibujos e ideas en
116 común pero nunca miraran lo que hace el otro.
118 Vamos a describir entonces un poco mejor a que nos referimos con "poder
119 revisar", porque hasta ahora no dijimos bien de que se trataba. Hace un ratito
120 hablamos de como nosotros pensábamos en las modificaciones a una base de
121 código como un conjunto de cambios que compartían un fin en común, y los
122 llamamos "changesets".
124 Entonces pensemos un poco acerca de este tema de la revisión: a nosotros
125 cuando estamos desarrollando y queremos ver como arreglo nuestro compañero ese
126 bug que estaba en el nuestro programa desde hacia rato y nadie se le animaba,
127 lo que a nosotros nos va a interesar ver no es el código terminado, porque
128 normalmente de ahí nos va a costar deducir como fue la solución, y además
129 quizás ya para cuando lo querramos ver le metimos tanta mano que quedo
130 irreconocible su solución inicial: lo que nos interesa es ver qué cambios
131 introdujo desde el código con el error hasta el código sin el error. O sea,
132 nos interesa poder "leer" el changeset que introdujo.
134 Y esto es uno de los pilares del funcionamiento de todo esto que estamos
135 hablando: podemos pensar en la representación del código ya no sólo como un
136 conjunto de archivos y directorios en los cuales se encuentra texto; sino que
137 nos interesa, y mucho, llevar el conjunto de cambios que se han efectuado, que
138 van acompañando y representando la evolución de nuestro proyecto.
140 Esto nos va a permitir poder saber en cualquier instante del tiempo, desde que
141 empezamos hasta ahora, cómo fue evolucionando el código fuente, y, lo más
142 importante, qué cambios se fueron produciendo en él.
144 El tener el historial de cambios realizados sobre un repositorio nos va a
145 deparar numerosos beneficios (aparte de poder saber a quien culpar cuando
146 alguien hace una macana!). Nos va a permitir, en primera instancia, ser
147 capaces de revisar y deshacer las cosas que nosotros mismos hicimos, aprender
148 de lo que otros hicieron, nos va a facilitar encontrar errores porque vamos a
149 poder ver que punto se rompió algo, realizar numerosas pruebas, etc.
151 Todas esas cosas las vamos a ver en detalle más adelante porque son muy
152 divertidas, pero para no irnos demasiado por las nubes, metamos un poco de
153 realidad en todo este asunto.
159 Bueno, hasta ahora nosotros hablamos mucho de changesets y de cambios a una
160 base de código, e inclusive dijimos lo importante que era poder ver los
161 cambios, pero todavía no dijimos siquiera como obtenerlos!
163 Una de las herramientas más viejas y más usadas (inclusive actualmente), que
164 constituye uno de las bases sobre las cuales se construyeron la mayoría de los
165 mecanismos actuales, son dos programas en apariencia muy simples, que se
168 El primero y más importante se llama "diff", y sirve para saber la diferencia,
169 en principio, entre dos archivos A y B, comparándolos línea por línea y
170 produciendo un tercer archivo C.
172 El archivo de cambios contiene la información necesaria para, teniendo A,
173 saber que modificaciones realizarle para llegar a B, es por esto que también se
174 le suele decir "delta". El formato en el que se este delta (el archivo C) puede
175 variar, pero todo el mundo en su sano juicio (y de los que no, la mayoría
176 también) usa uno al que se llama "formato unificado".
178 El programa "patch" sirve para hacer el proceso inverso: toma un archivo base
179 A, y el delta C, y produce un archivo B que resulta de tomar A y aplicarle los
180 cambios que están descriptos en C.
182 Vamos a ver un ejemplito:
184 ARCHIVO A ARCHIVO B DIFF UNIFICADO
185 ========= ========= ==============
186 Gloria a Dios en las alturas, Gloria a Dios en las alturas, --- archivo1 2005-05-17 12:57:00.000000000 -0300
187 recogieron las basuras recogieron las basuras +++ archivo2 2005-05-17 12:54:38.000000000 -0300
188 de mi calle, ayer a oscuras de mi calle, ayer a oscuras @@ -6,7 +6,7 @@
189 y hoy sembrada de bombillas. y hoy sembrada de bombillas. Y colgaron de un cordel
190 de esquina a esquina un cartel
191 Y colgaron de un cordel Y colgaron de un cordel y banderas de papel
192 de esquina a esquina un cartel de esquina a esquina un cartel -verdes, rojas y amarillas.
193 y banderas de papel y banderas de papel +lilas, rojas y amarillas.
194 verdes, rojas y amarillas. lilas, rojas y amarillas.
195 Y al darles el sol la espalda
196 Y al darles el sol la espalda Y al darles el sol la espalda revolotean las faldas
197 revolotean las faldas revolotean las faldas @@ -15,7 +15,7 @@
198 bajo un manto de guirnaldas bajo un manto de guirnaldas
199 para que el cielo no vea, para que el cielo no vea, en la noche de San Juan,
200 cómo comparten su pan,
201 en la noche de San Juan, en la noche de San Juan, -su tortilla y su gabán,
202 cómo comparten su pan, cómo comparten su pan, +su mujer y su galán,
203 su tortilla y su gabán, su mujer y su galán, gentes de cien mil raleas.
204 gentes de cien mil raleas. gentes de cien mil raleas.
206 Apurad Apurad @@ -35,7 +35,7 @@
207 que allí os espero si queréis venir que allí os espero si queréis venir Juntos los encuentra el sol
208 pues cae la noche y ya se van pues cae la noche y ya se van a la sombra de un farol
209 nuestras miserias a dormir. nuestras miserias a dormir. empapados en alcohol
210 -abrazando a una muchacha.
211 Vamos subiendo la cuesta Vamos subiendo la cuesta +magreando a una muchacha.
212 que arriba mi calle que arriba mi calle
213 se vistió de fiesta. se vistió de fiesta. Y con la resaca a cuestas
214 vuelve el pobre a su pobreza,
215 Hoy el noble y el villano, Hoy el noble y el villano, @@ -43,8 +43,8 @@
216 el prohombre y el gusano el prohombre y el gusano y el señor cura a sus misas.
217 bailan y se dan la mano bailan y se dan la mano
218 sin importarles la facha. sin importarles la facha. Se despertó el bien y el mal
219 -la pobre vuelve al portal
220 Juntos los encuentra el sol Juntos los encuentra el sol -la rica vuelve al rosal
221 a la sombra de un farol a la sombra de un farol +la zorra pobre al portal
222 empapados en alcohol empapados en alcohol +la zorra rica al rosal
223 abrazando a una muchacha. magreando a una muchacha. y el avaro a las divisas.
225 Y con la resaca a cuestas Y con la resaca a cuestas Se acabó,
226 vuelve el pobre a su pobreza, vuelve el pobre a su pobreza,
227 vuelve el rico a su riqueza vuelve el rico a su riqueza
228 y el señor cura a sus misas. y el señor cura a sus misas.
230 Se despertó el bien y el mal Se despertó el bien y el mal
231 la pobre vuelve al portal la zorra pobre al portal
232 la rica vuelve al rosal la zorra rica al rosal
233 y el avaro a las divisas. y el avaro a las divisas.
236 que el sol nos dice que llegó el final. que el sol nos dice que llegó el final.
237 Por una noche se olvidó Por una noche se olvidó
238 que cada uno es cada cual. que cada uno es cada cual.
240 Vamos bajando la cuesta Vamos bajando la cuesta
241 que arriba en mi calle que arriba en mi calle
242 se acabó la fiesta. se acabó la fiesta.
245 Si bien parece un poco loco, el formato del diff no sólo es simple, sino que
246 también es ampliamente legible, y se suele ser la forma preferida de ver los
247 cambios realizados. Hoy en día es por lejos el formato más usado para ese fin.
249 Miremoslo un poco mejor: se compone de un encabezado en el cual se cuentan los
250 nombres de los archivos involucrados y la hora en la que fueron modificados
251 por ultima vez, luego una posición, un contexto, y las líneas que cambiaron.
253 En este formato, los cambios se representan de una forma algo dual: se dice
254 que líneas han de ser removidas, y cuales han de ser colocadas en su lugar.
255 A las primeras se les pone un "-" delante, y a las segundas un "+". Las que no
256 tienen ni - ni + son líneas de contexto, puestas para hacerlo más legible y
259 Esto se extiende a dos árboles de código haciendo la comparación recursiva,
260 caminando todos los archivos de la estructura de directorios.
262 Así, lo que se hace con esto y a pulmón es tener el código fuente base en un
263 directorio, copiarlo a otro sobre el cual trabajamos, y cuando estamos
264 conformes con los cambios realizados, con diff sacamos las diferencias entre
265 el original y el nuestro, obteniendo la representación de los cambios que
266 introdujimos, o sea, nuestro preciado changeset.
268 Sobre esta base se puede construir mucho más de lo que parece, dado que
269 podemos ir guardando dichos changesets y armar la historia tal como
270 describimos arriba. Esto tiene ciertas propiedades muy particulares que lo
271 hacen extremadamente flexible y útil para muchas formas de trabajo, pero
272 requiere un esfuerzo importante porque hay que hacer mucho de forma manual.
275 Sistemas para la administración de código fuente
276 ------------------------------------------------
278 Ahora que vimos como hacer para obtener los changesets de los que estuvimos
279 hablando, dijimos que un tema muy importante era poder manejarlos y
280 administrarlos: para esto (entre otras cosas) es por lo que surgen los
281 sistemas por los cuales están uds. leyendo esto y nosotros escribiéndolo:
282 los sistemas de administración de código fuente.
284 Antes de seguir, un pequeño paréntesis importante: hay muchísimas formas de
285 llamar a estos sistemas, ninguna demasiado convincente. Una que vamos a usar
286 mucho, que es de las más usadas, es "SCM", que algunos claman que es "software
287 configuration management", otros "source control management", y otros "source
288 code management". Saber quien tiene razón es tema para un historiador,
289 nosotros vamos a hacernos los zonzos y pretender que es una sigla que tiene
290 sentido. También le suelen decir "Sistemas de control de versiones" o VCS; o
291 CMS (Code Management System o algo por el estilo) pero es más inusual. Esta
292 última sigla en particular, es una pésima elección porque hay otro tipo de
293 sistema muy conocido de esta manera (los Content Management Systems) que NADA
294 tiene que ver con el manejo de código.
296 Entonces, volvamos a estas herramientas: su objetivo es administrar el código
297 fuente y su evolución, de una forma u otra ir grabando ese proceso, y
298 presentar al usuario esa información de forma útil y práctica.
300 Para entenderlas bien, vamos a presentar un poco los conceptos más importantes
301 que acarrean, y cómo interactúan las distintas cosas entre sí.
303 Comencemos por uno muy básico y que no tiene nada de loco: llamamos
304 repositorio a un conjunto compuesto por el código fuente en un punto
305 determinado del tiempo, y la historia asociada a éste. Recordemos que vamos a
306 pensar la historia de un código fuente como un conjunto de changesets.
307 Por lo tanto, un repositorio tiene, además del estado del código fuente
308 actual, un conjunto ordenado (no necesariamente de forma cronológica) de
309 cambios que se han realizado sobre el mismo para llevarlo a como esta ahora.
311 Conociendo los repositorios, entonces decimos que un changeset se "aplica" a
312 un repositorio cuando se lo introduce ordenadamente, o sea, cuando sobre un
313 repositorio en un estado A hacemos un cambio que lo lleva a B, el delta entre
314 los dos estados es, como ya vimos, el changeset. A cada changeset, ahora que
315 tenemos una herramienta para manejarlo, le podemos asociar información
316 adicional, como el nombre del autor, la fecha en la cual se incorporió a un
320 Manipulando repositorios
321 ------------------------
323 Ahora que mostramos más o menos las estructuras básicas que manejan los SCMs,
324 veamos un poco qué podemos hacer con ellas.
326 La operación más básica sobre un repositorio se le suele llamar "branch", y en
327 un principio es simplemente el acto de copiarlo, lo cual nos permite ir
328 elaborando cambios en dos repositorios independientes que comparten la misma
329 base. Hay muchos tipos y variaciones de branches, no son todas iguales y este
330 concepto se ajusta según como lo maneje cada herramienta en particular, aunque
331 comparten esta misma esencia.
333 Así, podemos aplicar distintos changesets en cada repositorio de forma
334 independiente. Para encontrar un ejemplo práctico de esto no hay que irlo a
335 buscar muy lejos: pensemos en cualquier trabajo grupal. Si tenemos un
336 repositorio común, y nos dividimos las tareas entre dos compañeros, ambos
337 vamos a partir del mismo repositorio base pero a trabajar de forma
338 independiente. En ese caso, cada uno tendría su repositorio que surge de hacer
339 un branch de uno común.
341 Cuando los dos terminamos nuestro trabajo, queremos "integrar" los cambios de
342 los dos de tal forma que nos quede un repositorio con el trabajo de ambos.
343 Para esto elegimos uno base, y aplicamos los changesets que están en el otro
344 para lograr una combinación. Este acto de combinar dos repositorios se llama
345 "merge", y como vimos consiste básicamente en incorporar en un repositorio los
346 cambios que se produjeron en otro de forma independiente.
350 ARCHIVO BASE MODIFICACIÓN A MODIFICACIÓN B
351 ============ ============== ==============
352 La colina hay que subir, La colina hay que subir, La colina hay que subir,
353 nada es sencillo aquí, nada es sencillo aquí, nada es sencillo aquí,
354 y ante todo está El Dragón y ante todo está El Dragón y ante todo está El Dragón
355 Al Dragón le gusta tirarse panza arriba con su fuego intentará Al Dragón le gusta tirarse panza arriba
356 y ponerse a leer cuentos alegres parar la construcción y ponerse a leer cuentos alegres
357 mientras se rasca la barriga. pero habrá una solución mientras se rasca la barriga.
358 Cuando tiene mucha hambre Cuando tiene mucha hambre Una flor un corazón,
359 busca bichitos de luz busca bichitos de luz una porción de sol,
360 y se los come despacito. y se los come despacito. y estas ganas de vivir...
362 MERGE DIFF DE MODIFICACIÓN A DIFF DE MODIFICACIÓN B
363 ===== ====================== ======================
364 La colina hay que subir, --- base 2005-05-17 13:16:10.0000 --- base 2005-05-17 13:16:10.0000
365 nada es sencillo aquí, +++ archivo1 2005-05-17 13:16:39.0000 +++ archivo2 2005-05-17 13:16:57.0000
366 y ante todo está El Dragón @@ -1,9 +1,9 @@ @@ -4,7 +4,7 @@
367 con su fuego intentará La colina hay que subir, Al Dragón le gusta tirarse panza arriba
368 parar la construcción nada es sencillo aquí, y ponerse a leer cuentos alegres
369 pero habrá una solución y ante todo está El Dragón mientras se rasca la barriga.
370 Una flor un corazón, -Al Dragón le gusta tirarse panza arriba -Cuando tiene mucha hambre
371 una porción de sol, -y ponerse a leer cuentos alegres -busca bichitos de luz
372 y estas ganas de vivir... -mientras se rasca la barriga. -y se los come despacito.
373 +con su fuego intentará +Una flor un corazón,
374 +parar la construcción +una porción de sol,
375 +pero habrá una solución +y estas ganas de vivir...
376 Cuando tiene mucha hambre
377 busca bichitos de luz
378 y se los come despacito.
380 Cuando al hacer un merge vemos que dos changesets modifican las mismas partes
381 de un archivo, decimos que hay un "conflicto". El manejo de conflictos es
382 parte muy importante de cualquier SCM, no sólo por la capacidad de resolución
383 sino por la capacidad de detectarlos: si un SCM no detecta un conflicto, puede
384 introducir corrupción en el código, cuyos resultados suelen ser problemáticos.
386 Al detectarse un conflicto que el SCM no puede resolver de forma automática,
387 se informa al usuario y se espera que se resuelva a mano o con alguna de las
388 herramientas diseñadas para asistir en la resolución de estos problemas.
390 Afortunadamente, la mayoría de los SCMs modernos se enfocan muchísimo en este
391 problema y poseen muy buenos algoritmos de detección y resolución de
392 conflictos. Al final, en los ejemplos más prácticos, veremos casos reales de
393 conflictos y como resolverlos.
396 Historia de un repositorio
397 --------------------------
399 Hace un rato hablamos de la importancia de tener la historia de la evolución
400 del código, cosa que ahora tenemos representada en un repositorio como un
401 conjunto de changesets. Esto nos permite manipularlos de forma muy cómoda,
402 no solo para poder leerlos, sino también vimos que podemos hacer merges entre
403 dos repositorios y unir dos repositorios que, en base a un ancestro común,
404 evolucionaron de forma independiente.
406 Esta capacidad resulta muy útil en muchos casos, tanto que vamos a hablar un
407 rato al respecto y mostrar algunos de ellos.
409 En principio, una ventaja importante es el poder revisar lo que hizo otro de
410 forma clara y contenida, concentrándonos sólo en los cambios introducidos y no
411 en el código preexistente. Esto es útil en muchos casos distintos, desde en un
412 grupo jerárquico en donde haya gente encargada de revisar y dar vistos buenos
413 a códigos de sus subordinados, en grupos en donde se dé la revisión entre
414 pares, o la colaboración, que suele ser moneda corriente (pensemos en el caso
415 de "esto no me sale, me ayudas?" o "que te parece esto?") en cualquier grupo
416 humano bien integrado. Nos permite compartir experiencia con nuestros
417 compañeros, permitiendo que otros vean las soluciones que les dimos a
418 problemas que surgieron en el pasado y pudiendo aprender de ellas.
420 Otra aplicación muy útil, y que se utiliza frecuentemente en proyectos
421 opensource, es el usar el historial de changesets para ubicar que cambio
422 introdujo un bug. Si conocemos una versión que no tiene un bug y otra que sí,
423 podemos ir buscando hasta encontrar qué changeset fue el que introdujo el bug,
424 haciendo más fácil la comprensión del mismo y su posterior arreglo.
426 También es posible combinar esto con tests de regresión, de forma tal que,
427 usando un mecanismo similar al descripto recién para los bugs, cuando notamos
428 que falla algún test, podemos ubicar qué cambio fue el que hizo que comience a
429 fallar. Inclusive algunos SCMs incorporan funcionalidad para realizar este
430 tipo de operaciones de forma automática.
432 Tener este tipo de información también nos puede resultar útil para saber a
433 quien referirse acerca de una pieza de código en particular: podemos ver quien
434 fue el que introdujo o modifico ciertas líneas de código, y así saber a quien
435 recurrir en caso de problemas o necesitar consejo sobre las mismas. Esto es
436 especialmente importante en proyectos grandes o de larga vida en la cual es
437 probable que los desarrolladores originales hayan dejado el proyecto para
438 concentrarse en otras cosas y para el grupo que queda a cargo suele ser
439 importante saber a quien recurrir.
441 Pero quizás la utilidad más importante de todas no provenga de la información
442 misma, sino de la forma en la que se genera: el hecho de que nosotros tengamos
443 que pensar en changesets nos ayuda a trabajar de forma más ordenada y prolija,
444 concentrándonos en un problema a la vez y atacándolo sin mezclar las cosas,
445 correspondiéndose con la forma de pensarlo abstractamente.
447 Es por esto que estas herramientas no son simples ayudas técnicas: afectan
448 nuestra forma de crear software, y deben acompañar y ajustarse a la manera en
449 la que concebimos y desarrollamos el software.
453 Dos formas de ver a los SCMs
454 ----------------------------
456 Todo lo que hablamos hasta ahora lo vimos de una forma relativamente general,
457 pero hay muchas cosas que al llevarlas a la práctica se pueden abordar de
458 formas distintas, y que implican formas distintas de trabajar.
460 Existen dos "paradigmas" (a todo el mundo le encanta esa palabra, no? Se
461 sienten re importantes sabiendo lo que quiere decir =) para el funcionamiento
462 de los SCMs: centralizados y distribuidos.
464 Aclaremos que el concepto de distribuido no es el que se suele usar en algunos
465 ámbitos como "algo que usa la red", sino el que se suele usar más comúnmente
466 (o más correctamente), que significa que no existe un punto central, sino que
467 las cosas están repartidas de forma más o menos horizontal. Algo así como la
468 diferencia entre peer-to-peer y cliente-servidor.
475 Los SCMs centralizados, como es de suponerse, se basan en un repositorio único
476 central con todas las letras (es decir, que guarda la historia de changesets),
477 al que todos los desarrolladores se conectan para reportar cambios (aplicar
478 changesets). Por otro lado aparece el concepto de lo que se conoce como
479 "working copy" (WC), que podría pensarse, según lo visto anteriormente, como
480 un branch muy particular, que no tiene historia (más allá de que algunos SCM
481 le ponen algo de historia para facilitar algunas operaciones offline).
483 Al haber un sólo repositorio, éste debe ser el encargado de manejar los
484 branches, quedando todos dentro de éste. Es decir, en un mismo repositorio
485 tengo 2 (o más) caminos evolutivos distintos del mismo programa. La forma en que
486 se implementa esto, varía de SCM en SCM, pero el concepto general se mantiene.
488 A diferencia de los SCM distribuido (que son algo así como el caso más general),
489 los SCM centralizados suelen basarse en una línea de tiempo. Es decir, los
490 cambios guardan una dependencia lineal en el tiempo. Es decir, para obtener un
491 changeset X, debo obtener, en orden cronológico, todos los changesets que se han
492 aplicado anteriormente.
494 Otra cosa a tener en cuenta a la hora de elegir un SCM es que los centralizados,
495 al ser naturalmente cliente-servidor, necesitan un servidor (que probablemente
496 esté prendido todo el tiempo y con conexión permanente) y que debe ser
497 configurado, con algún sistema de autenticación y permisos. Es decir, la
498 configuración puede ser algo más compleja, claro que todo depende de qué
499 necesitemos hacer. La configuración puede ser tan simple o compleja como
500 queramos dependiendo del uso que vamos a darle (por lo general hacer un
501 repositorio local es trivial).
503 Otra "contra" que acarrea su naturaleza cliente-servidor, es que, generalmente,
504 todas las operaciones del SCM son online (es decir, requieren conexión con el
505 servidor). Por ejemplo para ver la historia del repositorio, para obtener un
506 chageset determinado, para aplicar un changeset, etc...
508 Generalmente hay 2 tipos de SCM centralizados, los que usan el modelo
509 Lock-Modify-Unlock y los que usan el modelo Copy-Modify-Merge. El primero es el
510 más simple y limitado, y consiste en que cada vez que un usuario quiere
511 modificar un archivo, este archivo se "lockea" y no puede ser modificado por
512 nadie más hasta que este usuario termine de editarlo. Este modelo, además de ser
513 muy limitado e incómodo, rompe bastante el concepto de changeset, ya que los
514 cambios están centrados en archivos y en cambios al repositorio como un todo.
515 El segundo modelo propone lo siguiente: se hace una copia del estado actual del
516 repositorio (sería nuestra WC), se modifica y se aplica el changeset al
517 repositorio central haciendo un merge. Cualquier SCM mínimamente serio ofrece
518 esta forma de trabajo.
521 Caso de estudio de SCM Centralizado: Subversion
522 -----------------------------------------------
524 Una de las principales características de subversion, es que fue pensado como
525 un reemplazo natural a CVS, por lo que es una excelente transición si se quiere
526 pasar de CVS a otro SCM un poco más serio o incluso si se quiere seguir
527 trabajando con un modelo centralizado, ya que soluciona la mayoría de sus
528 problemas técnicos y conceptuales.
530 Subversion usa el modelo Copy-Modify-Merge y trata siempre de optimizar el uso
531 de ancho de banda y de hacer todas las operaciones posible sin necesidad de
532 conexión. Esto lo hace simplemente guardando una copia intacta del estado del
533 repositorio y otra para que modifiquemos (algo así como guardar un pedacito de
534 historia). De esta manera, hay algunas operaciones que pueden hacerse offline.
535 Entre ellas, la más importante es el diff, ya que de esta manera puede enviar al
536 servidor solamente el changeset (otros SCM más viejitos, CVS incluido, tienen
537 que mandar los archivos modificados enteros y hacer el diff en el servidor).
538 Es decir, el uso de ancho de banda en subversion al aplicar un changeset es
539 proporcional al tamaño de los cambios y no de los archivos enteros, como pasa en
542 Otro concepto muy fuerte en Subversion, es que es un filesystem versionado. Es
543 decir, un sistema de archivo (conjunto organizado jerárquicamente de
544 directorios y archivos, y sus contenidos, por supuesto). Es por esto que provee
545 las operaciones comunes de cualquier filesystem (crear un directorio, copiar un
546 archivo, mover un archivo, borrar un archivo, etc), con algunas
547 particularidades. Como subversion piensa a los repositorios como una línea de
548 tiempo, la hacer una copia de un archivo A a B, en realidad no se copia el
549 archivo sino que se dice que el archivo copiado B es una bifurcación en la línea
550 de tiempo del archivo A. Es decir:
556 Revision 2 ------- ARCHIVO B
563 Es decir, la historia del archivo B, será su historia propia más la historia del
564 archivo A hasta la revisión 2. Las revisiones serían los changesets que se
565 fueron aplicando al repositorio (que como son cronológicamente ordenados, se
566 numeran secuencialmente).
568 A esta característica se la llama "cheap copy" (copia barata) y es la manera en
569 la que subversion implementa los branches. Es decir, suponganse que en vez de
570 ser archivos son directorios, lo que tenemos son 2 evoluciones distintas de la
571 misma base de código. Por supuesto en un determinado momento podemos aplicar los
572 changesets de un branch en el otro a través de un merge.
573 Ahora, si los branches se almacenan en el repositorio como simples directorios,
574 es necesario tener una estructura particular en él, que nos permita ubicar
575 fácilmente distintos branches de un proyecto, o su línea de desarrollo
576 principal, etc. Lo que propone el manual, y uno de los esquemas más utilizados,
577 es crear 3 dirctorios en la raíz del repositorio apenas se lo crea, llamdos
578 'trunk' (línea principal de desarrollo), 'branches' y 'tags' (tag es un nombre
579 utilizado generalmente para indicar un estado significativo del respositorio, en
580 general realeases). De esta forma, hacer un branch sería tan simple como copiar
581 'trunk' a 'branches/mi_branch' para crear el branch 'mi_branch'.
583 Un par de características agradables de subversion, que no tiene demasiado que
584 ver con la teoría que estuvimos introduciendo, son la alta disponibilidad de
585 clientes (hay para todos los gustos y OSs, tanto de consola como gráficos) y
586 las propiedades. Estas últimas son metainformación arbitraria o con significado
587 especial que se asocia a un archivo o directorio. A través de estas propiedades
588 subversion maneja algunas cosas interesantes, como el tipo de fin de línea, si
589 es un archivo binario y de qué tipo (para utilizar la herramienta de diff
590 correcta), si es ejecutable, etc. Con respecto a los clientes, sólo voy a decir
591 que nosotros nos centraremos en el cliente "oficial" llamado svn, que es un
592 cliente de consola multiplataforma (la gente que use WIN32 tal vez quiera darle
593 una mirada a Tortoise, un cliente gráfico que se integra con el shell).
599 La idea detrás de los SCMs distribuidos es que no exista un repositorio
600 central obligatoriamente, sino que basan su comportamiento en la existencia y
601 el uso de múltiples repositorios "hermanos", que pueden intercambiarse cambios
602 unos con otros. No hay un repositorio "maestro" con el cual todos se comparan.
604 Esto hace que la operación de "merge" que hablamos antes se vuelva muy
605 importante, dado que se realiza de forma muy frecuente al pasar los cambios de
606 un repositorio a otro.
608 La forma de trabajo descentralizada nos permite que dos desarrolladores tomen
609 un mismo repositorio, hagan cada uno su propio branch, trabajen sobre él de
610 forma independiente, integrando luego los cambios entre sí de forma natural,
611 manteniendo en todo momento la historia y la consistencia.
613 Hay varios SCMs distribuidos, últimamente están bastante de moda, algunos
614 ejemplos son Darcs, Arch, Monotone, Codeville y Bitkeeper.
621 En el directorio 'ejemplos' hay algunas páginas HTML con ejemplos prácticos,
622 tanto de darcs como de subversion.
projects / personal / documentos.git / blob