From: Leandro Lucarella Date: Thu, 19 May 2005 21:26:10 +0000 (+0000) Subject: Agrego charla de SCMs. X-Git-Tag: svn_import~33 X-Git-Url: https://git.llucax.com/personal/documentos.git/commitdiff_plain/407772cb9c844e59a29d58f496330a8437e58700 Agrego charla de SCMs. --- diff --git a/charla_scm/SCM b/charla_scm/SCM new file mode 100644 index 0000000..99b9877 --- /dev/null +++ b/charla_scm/SCM @@ -0,0 +1,624 @@ + + INTRODUCCIÓN A LOS SISTEMAS DE CONTROL DE VERSIONES + =================================================== + + +El proceso de desarrollo de software +------------------------------------ + +Creo que es importante comenzar mencionando que el desarrollo de software no +sólo es un proceso inherentemente social y creativo, y como tal tenemos que +hacernos de la idea de que la mayoría de los problemas que acarrea son de esta +índole. + +Comencemos por sentar una base común acerca de como se suele desarrollar +software. Esto no tiene nada que ver con todas esas metodologías horrorosas +(Extreme programming, Unified Process, etc, etc), sino con como, en el fondo, +se realiza ese proceso desde el punto de vista de la evolución del código. + +Ya sea que trabajemos en grupo o de forma individual, todos comenzamos con una +hoja en blanco y una idea en la cabeza, que a medida que progresamos va +tomando forma. + +En el caso del software, nosotros en esta charla nos vamos a concentrar un +poco en el código fuente, y no vamos a hablar tanto del tema de diseño o +arquitectura de software porque no nos atañe, robaría mucho tiempo y podemos +enfocarnos en lo que queremos explicar sin necesidad de entrar en esos temas. + +Por lo tanto, nosotros arrancamos con un directorio vació, en el cual vamos +escribiendo, construyendo nuestro software de forma incremental e iterativa, +corrigiendo nuestros propios errores a medida que aparecen, y agregando cosas +nuevas cuando se nos place. + +Detengamonos un poco acá y miremos mejor que pasa con nuestro código a medida +que vamos avanzando en un proyecto: nuestro código va evolucionando, cambiando +con iteraciones pequeñas que nosotros vamos introduciendo por diversos motivos +(normalmente correcciones o características nuevas), porque esa es la manera +en la que vemos y pensamos al software: es como si tuviéramos una escultura +que tiene una forma determinada y nosotros por nuestras arbitrarias razones la +queremos ir modificando. + +Por lo tanto, podemos pensar que el software se va construyendo en base a +modificaciones incrementales que nosotros vamos haciendo. Pero aun más, una +cosa esencial es que esos cambios no son desordenados ni desorganizados +(aunque hay cada uno!): se corresponden con alguna construcción mental +nuestra, porque cuando nosotros pensamos en implementar algo o corregir un +bug, lo tenemos en mente como una unidad, como un objetivo bastante +independiente de como se representa en el código fuente; y nosotros pensamos +en que cambios le tenemos que realizar para lograr ese objetivo propuesto. + +Y ese proceso, esa forma de ver las modificaciones es lo que hace que +desarrollemos de la manera en la que lo hacemos, más allá de que a otro nivel +se usen esos métodos que (ridículamente) se suelen modelar y estudiar, en el +fondo uno piensa las cosas de esa manera, de la misma forma que un escultor +piensa en una nariz, unos ojos, un pliegue de una manta o un gesto con la +mano, y es capaz de ver tanto los objetos individuales como el conjunto que +éstos forman. + +Vamos a bautizar esos cambios de los que estuvimos hablando, porque acá si las +cosas no tienen un nombre con onda y/o una sigla, nadie les da bola. Nosotros +dijimos que pensábamos en los cambios como una entidad en sí misma, y vamos a +llamar "changeset" a eso: a un grupo de cambios que se realizan sobre una base +de código, todos orientados a un fin en común. + + + +Grupos de trabajo +----------------- + +Cuando trabajamos en grupo, surge la necesidad de coordinar el trabajo, no +sólo por una cuestión natural sino también como mecanismo de optimizar los +recursos: cuando faltan dos días para entregar un trabajo, absolutamente nadie +quiere perder tiempo, y menos si eso implica que dos personas hayan estado +trabajando toda una tarde sobre lo mismo. + +Por eso, para desarrollar en grupo es imprescindible la buena comunicación y +entendimiento entre los pares. Esto implica que, en general, los desarrollos +se dan de forma coordinada (ya sea de manera horizontal o vertical, +independientemente del mecanismo que se elija explícita o implícitamente para +ello) al menos en un nivel social, las tareas se reparten y los cambios se +discuten donde afectan al grupo para facilitar el trabajo. + +Claro que el desarrollar en grupo, por más que uno se lleve maravillosamente +bien con la gente involucrada, acarrea ciertas incomodidades que sí son más +técnicas, y que van a constituir gran parte de lo que vamos a hablar acá: al +haber más de una persona modificando el código fuente de forma simultanea, +existe una complejidad, y nada menor, en lo que refiere al hecho de +sincronizarlo y mantenerlo coherente entre todos los miembros del grupo. + +También se dan en un grupo de trabajo relaciones asimétricas respecto del +código, debido a que cada grupo tiene una forma y un flujo de trabajo +particular, en el cual, por ejemplo, se pueden dar relaciones jerárquicas, +revisión de código entre pares, subgrupos, etc. + +Esto va a reflejarse en el código fuente con el surgimiento de una nueva +necesidad, que va a ser la de la integración de múltiples trabajos +individuales, la distribución del mismo en distintas maquinas y la +coordinación para que todos puedan trabajar sobre la misma base de código. + + +Capacidad de revisión +--------------------- + +Justamente con los grupos es donde se ve más fácil una cuestión de gran +importancia, que es la capacidad de revisión, nombre con el que hacemos +referencia a tener la posibilidad de ver lo que hicieron los otros, no sólo +para echarles la culpa (idealmente, esa debería ser la razón menos necesaria +de todas), sino porque es muy importante tener en perspectiva que fue lo que +hicieron los demás para el trabajo que realiza uno. + +Se suelen decir maravillas de la abstracción y todo ese tipo de +construcciones, pero no hay que perder de vista que, si bien son buenos +conceptos, el tener una perspectiva amplia y completa de lo que se está +haciendo y con lo que se está interactuando suele ser beneficioso para todos. +Siguiendo con la analogía del escultor, es como si un grupo de escultores se +decidiera a trabajar con una pieza, tuvieran los planos, dibujos e ideas en +común pero nunca miraran lo que hace el otro. + +Vamos a describir entonces un poco mejor a que nos referimos con "poder +revisar", porque hasta ahora no dijimos bien de que se trataba. Hace un ratito +hablamos de como nosotros pensábamos en las modificaciones a una base de +código como un conjunto de cambios que compartían un fin en común, y los +llamamos "changesets". + +Entonces pensemos un poco acerca de este tema de la revisión: a nosotros +cuando estamos desarrollando y queremos ver como arreglo nuestro compañero ese +bug que estaba en el nuestro programa desde hacia rato y nadie se le animaba, +lo que a nosotros nos va a interesar ver no es el código terminado, porque +normalmente de ahí nos va a costar deducir como fue la solución, y además +quizás ya para cuando lo querramos ver le metimos tanta mano que quedo +irreconocible su solución inicial: lo que nos interesa es ver qué cambios +introdujo desde el código con el error hasta el código sin el error. O sea, +nos interesa poder "leer" el changeset que introdujo. + +Y esto es uno de los pilares del funcionamiento de todo esto que estamos +hablando: podemos pensar en la representación del código ya no sólo como un +conjunto de archivos y directorios en los cuales se encuentra texto; sino que +nos interesa, y mucho, llevar el conjunto de cambios que se han efectuado, que +van acompañando y representando la evolución de nuestro proyecto. + +Esto nos va a permitir poder saber en cualquier instante del tiempo, desde que +empezamos hasta ahora, cómo fue evolucionando el código fuente, y, lo más +importante, qué cambios se fueron produciendo en él. + +El tener el historial de cambios realizados sobre un repositorio nos va a +deparar numerosos beneficios (aparte de poder saber a quien culpar cuando +alguien hace una macana!). Nos va a permitir, en primera instancia, ser +capaces de revisar y deshacer las cosas que nosotros mismos hicimos, aprender +de lo que otros hicieron, nos va a facilitar encontrar errores porque vamos a +poder ver que punto se rompió algo, realizar numerosas pruebas, etc. + +Todas esas cosas las vamos a ver en detalle más adelante porque son muy +divertidas, pero para no irnos demasiado por las nubes, metamos un poco de +realidad en todo este asunto. + + +diff + patch +------------ + +Bueno, hasta ahora nosotros hablamos mucho de changesets y de cambios a una +base de código, e inclusive dijimos lo importante que era poder ver los +cambios, pero todavía no dijimos siquiera como obtenerlos! + +Una de las herramientas más viejas y más usadas (inclusive actualmente), que +constituye uno de las bases sobre las cuales se construyeron la mayoría de los +mecanismos actuales, son dos programas en apariencia muy simples, que se +complementan. + +El primero y más importante se llama "diff", y sirve para saber la diferencia, +en principio, entre dos archivos A y B, comparándolos línea por línea y +produciendo un tercer archivo C. + +El archivo de cambios contiene la información necesaria para, teniendo A, +saber que modificaciones realizarle para llegar a B, es por esto que también se +le suele decir "delta". El formato en el que se este delta (el archivo C) puede +variar, pero todo el mundo en su sano juicio (y de los que no, la mayoría +también) usa uno al que se llama "formato unificado". + +El programa "patch" sirve para hacer el proceso inverso: toma un archivo base +A, y el delta C, y produce un archivo B que resulta de tomar A y aplicarle los +cambios que están descriptos en C. + +Vamos a ver un ejemplito: + +ARCHIVO A ARCHIVO B DIFF UNIFICADO +========= ========= ============== +Gloria a Dios en las alturas, Gloria a Dios en las alturas, --- archivo1 2005-05-17 12:57:00.000000000 -0300 +recogieron las basuras recogieron las basuras +++ archivo2 2005-05-17 12:54:38.000000000 -0300 +de mi calle, ayer a oscuras de mi calle, ayer a oscuras @@ -6,7 +6,7 @@ +y hoy sembrada de bombillas. y hoy sembrada de bombillas. Y colgaron de un cordel + de esquina a esquina un cartel +Y colgaron de un cordel Y colgaron de un cordel y banderas de papel +de esquina a esquina un cartel de esquina a esquina un cartel -verdes, rojas y amarillas. +y banderas de papel y banderas de papel +lilas, rojas y amarillas. +verdes, rojas y amarillas. lilas, rojas y amarillas. + Y al darles el sol la espalda +Y al darles el sol la espalda Y al darles el sol la espalda revolotean las faldas +revolotean las faldas revolotean las faldas @@ -15,7 +15,7 @@ +bajo un manto de guirnaldas bajo un manto de guirnaldas +para que el cielo no vea, para que el cielo no vea, en la noche de San Juan, + cómo comparten su pan, +en la noche de San Juan, en la noche de San Juan, -su tortilla y su gabán, +cómo comparten su pan, cómo comparten su pan, +su mujer y su galán, +su tortilla y su gabán, su mujer y su galán, gentes de cien mil raleas. +gentes de cien mil raleas. gentes de cien mil raleas. + Apurad +Apurad Apurad @@ -35,7 +35,7 @@ +que allí os espero si queréis venir que allí os espero si queréis venir Juntos los encuentra el sol +pues cae la noche y ya se van pues cae la noche y ya se van a la sombra de un farol +nuestras miserias a dormir. nuestras miserias a dormir. empapados en alcohol + -abrazando a una muchacha. +Vamos subiendo la cuesta Vamos subiendo la cuesta +magreando a una muchacha. +que arriba mi calle que arriba mi calle +se vistió de fiesta. se vistió de fiesta. Y con la resaca a cuestas + vuelve el pobre a su pobreza, +Hoy el noble y el villano, Hoy el noble y el villano, @@ -43,8 +43,8 @@ +el prohombre y el gusano el prohombre y el gusano y el señor cura a sus misas. +bailan y se dan la mano bailan y se dan la mano +sin importarles la facha. sin importarles la facha. Se despertó el bien y el mal + -la pobre vuelve al portal +Juntos los encuentra el sol Juntos los encuentra el sol -la rica vuelve al rosal +a la sombra de un farol a la sombra de un farol +la zorra pobre al portal +empapados en alcohol empapados en alcohol +la zorra rica al rosal +abrazando a una muchacha. magreando a una muchacha. y el avaro a las divisas. + +Y con la resaca a cuestas Y con la resaca a cuestas Se acabó, +vuelve el pobre a su pobreza, vuelve el pobre a su pobreza, +vuelve el rico a su riqueza vuelve el rico a su riqueza +y el señor cura a sus misas. y el señor cura a sus misas. + +Se despertó el bien y el mal Se despertó el bien y el mal +la pobre vuelve al portal la zorra pobre al portal +la rica vuelve al rosal la zorra rica al rosal +y el avaro a las divisas. y el avaro a las divisas. + +Se acabó, Se acabó, +que el sol nos dice que llegó el final. que el sol nos dice que llegó el final. +Por una noche se olvidó Por una noche se olvidó +que cada uno es cada cual. que cada uno es cada cual. + +Vamos bajando la cuesta Vamos bajando la cuesta +que arriba en mi calle que arriba en mi calle +se acabó la fiesta. se acabó la fiesta. + + +Si bien parece un poco loco, el formato del diff no sólo es simple, sino que +también es ampliamente legible, y se suele ser la forma preferida de ver los +cambios realizados. Hoy en día es por lejos el formato más usado para ese fin. + +Miremoslo un poco mejor: se compone de un encabezado en el cual se cuentan los +nombres de los archivos involucrados y la hora en la que fueron modificados +por ultima vez, luego una posición, un contexto, y las líneas que cambiaron. + +En este formato, los cambios se representan de una forma algo dual: se dice +que líneas han de ser removidas, y cuales han de ser colocadas en su lugar. +A las primeras se les pone un "-" delante, y a las segundas un "+". Las que no +tienen ni - ni + son líneas de contexto, puestas para hacerlo más legible y +cómodo de manipular. + +Esto se extiende a dos árboles de código haciendo la comparación recursiva, +caminando todos los archivos de la estructura de directorios. + +Así, lo que se hace con esto y a pulmón es tener el código fuente base en un +directorio, copiarlo a otro sobre el cual trabajamos, y cuando estamos +conformes con los cambios realizados, con diff sacamos las diferencias entre +el original y el nuestro, obteniendo la representación de los cambios que +introdujimos, o sea, nuestro preciado changeset. + +Sobre esta base se puede construir mucho más de lo que parece, dado que +podemos ir guardando dichos changesets y armar la historia tal como +describimos arriba. Esto tiene ciertas propiedades muy particulares que lo +hacen extremadamente flexible y útil para muchas formas de trabajo, pero +requiere un esfuerzo importante porque hay que hacer mucho de forma manual. + + +Sistemas para la administración de código fuente +------------------------------------------------ + +Ahora que vimos como hacer para obtener los changesets de los que estuvimos +hablando, dijimos que un tema muy importante era poder manejarlos y +administrarlos: para esto (entre otras cosas) es por lo que surgen los +sistemas por los cuales están uds. leyendo esto y nosotros escribiéndolo: +los sistemas de administración de código fuente. + +Antes de seguir, un pequeño paréntesis importante: hay muchísimas formas de +llamar a estos sistemas, ninguna demasiado convincente. Una que vamos a usar +mucho, que es de las más usadas, es "SCM", que algunos claman que es "software +configuration management", otros "source control management", y otros "source +code management". Saber quien tiene razón es tema para un historiador, +nosotros vamos a hacernos los zonzos y pretender que es una sigla que tiene +sentido. También le suelen decir "Sistemas de control de versiones" o VCS; o +CMS (Code Management System o algo por el estilo) pero es más inusual. Esta +última sigla en particular, es una pésima elección porque hay otro tipo de +sistema muy conocido de esta manera (los Content Management Systems) que NADA +tiene que ver con el manejo de código. + +Entonces, volvamos a estas herramientas: su objetivo es administrar el código +fuente y su evolución, de una forma u otra ir grabando ese proceso, y +presentar al usuario esa información de forma útil y práctica. + +Para entenderlas bien, vamos a presentar un poco los conceptos más importantes +que acarrean, y cómo interactúan las distintas cosas entre sí. + +Comencemos por uno muy básico y que no tiene nada de loco: llamamos +repositorio a un conjunto compuesto por el código fuente en un punto +determinado del tiempo, y la historia asociada a éste. Recordemos que vamos a +pensar la historia de un código fuente como un conjunto de changesets. +Por lo tanto, un repositorio tiene, además del estado del código fuente +actual, un conjunto ordenado (no necesariamente de forma cronológica) de +cambios que se han realizado sobre el mismo para llevarlo a como esta ahora. + +Conociendo los repositorios, entonces decimos que un changeset se "aplica" a +un repositorio cuando se lo introduce ordenadamente, o sea, cuando sobre un +repositorio en un estado A hacemos un cambio que lo lleva a B, el delta entre +los dos estados es, como ya vimos, el changeset. A cada changeset, ahora que +tenemos una herramienta para manejarlo, le podemos asociar información +adicional, como el nombre del autor, la fecha en la cual se incorporió a un +repositorio, etc. + + +Manipulando repositorios +------------------------ + +Ahora que mostramos más o menos las estructuras básicas que manejan los SCMs, +veamos un poco qué podemos hacer con ellas. + +La operación más básica sobre un repositorio se le suele llamar "branch", y en +un principio es simplemente el acto de copiarlo, lo cual nos permite ir +elaborando cambios en dos repositorios independientes que comparten la misma +base. Hay muchos tipos y variaciones de branches, no son todas iguales y este +concepto se ajusta según como lo maneje cada herramienta en particular, aunque +comparten esta misma esencia. + +Así, podemos aplicar distintos changesets en cada repositorio de forma +independiente. Para encontrar un ejemplo práctico de esto no hay que irlo a +buscar muy lejos: pensemos en cualquier trabajo grupal. Si tenemos un +repositorio común, y nos dividimos las tareas entre dos compañeros, ambos +vamos a partir del mismo repositorio base pero a trabajar de forma +independiente. En ese caso, cada uno tendría su repositorio que surge de hacer +un branch de uno común. + +Cuando los dos terminamos nuestro trabajo, queremos "integrar" los cambios de +los dos de tal forma que nos quede un repositorio con el trabajo de ambos. +Para esto elegimos uno base, y aplicamos los changesets que están en el otro +para lograr una combinación. Este acto de combinar dos repositorios se llama +"merge", y como vimos consiste básicamente en incorporar en un repositorio los +cambios que se produjeron en otro de forma independiente. + +Veamos un ejemplo: + +ARCHIVO BASE MODIFICACIÓN A MODIFICACIÓN B +============ ============== ============== +La colina hay que subir, La colina hay que subir, La colina hay que subir, +nada es sencillo aquí, nada es sencillo aquí, nada es sencillo aquí, +y ante todo está El Dragón y ante todo está El Dragón y ante todo está El Dragón +Al Dragón le gusta tirarse panza arriba con su fuego intentará Al Dragón le gusta tirarse panza arriba +y ponerse a leer cuentos alegres parar la construcción y ponerse a leer cuentos alegres +mientras se rasca la barriga. pero habrá una solución mientras se rasca la barriga. +Cuando tiene mucha hambre Cuando tiene mucha hambre Una flor un corazón, +busca bichitos de luz busca bichitos de luz una porción de sol, +y se los come despacito. y se los come despacito. y estas ganas de vivir... + +MERGE DIFF DE MODIFICACIÓN A DIFF DE MODIFICACIÓN B +===== ====================== ====================== +La colina hay que subir, --- base 2005-05-17 13:16:10.0000 --- base 2005-05-17 13:16:10.0000 +nada es sencillo aquí, +++ archivo1 2005-05-17 13:16:39.0000 +++ archivo2 2005-05-17 13:16:57.0000 +y ante todo está El Dragón @@ -1,9 +1,9 @@ @@ -4,7 +4,7 @@ +con su fuego intentará La colina hay que subir, Al Dragón le gusta tirarse panza arriba +parar la construcción nada es sencillo aquí, y ponerse a leer cuentos alegres +pero habrá una solución y ante todo está El Dragón mientras se rasca la barriga. +Una flor un corazón, -Al Dragón le gusta tirarse panza arriba -Cuando tiene mucha hambre +una porción de sol, -y ponerse a leer cuentos alegres -busca bichitos de luz +y estas ganas de vivir... -mientras se rasca la barriga. -y se los come despacito. + +con su fuego intentará +Una flor un corazón, + +parar la construcción +una porción de sol, + +pero habrá una solución +y estas ganas de vivir... + Cuando tiene mucha hambre + busca bichitos de luz + y se los come despacito. + +Cuando al hacer un merge vemos que dos changesets modifican las mismas partes +de un archivo, decimos que hay un "conflicto". El manejo de conflictos es +parte muy importante de cualquier SCM, no sólo por la capacidad de resolución +sino por la capacidad de detectarlos: si un SCM no detecta un conflicto, puede +introducir corrupción en el código, cuyos resultados suelen ser problemáticos. + +Al detectarse un conflicto que el SCM no puede resolver de forma automática, +se informa al usuario y se espera que se resuelva a mano o con alguna de las +herramientas diseñadas para asistir en la resolución de estos problemas. + +Afortunadamente, la mayoría de los SCMs modernos se enfocan muchísimo en este +problema y poseen muy buenos algoritmos de detección y resolución de +conflictos. Al final, en los ejemplos más prácticos, veremos casos reales de +conflictos y como resolverlos. + + +Historia de un repositorio +-------------------------- + +Hace un rato hablamos de la importancia de tener la historia de la evolución +del código, cosa que ahora tenemos representada en un repositorio como un +conjunto de changesets. Esto nos permite manipularlos de forma muy cómoda, +no solo para poder leerlos, sino también vimos que podemos hacer merges entre +dos repositorios y unir dos repositorios que, en base a un ancestro común, +evolucionaron de forma independiente. + +Esta capacidad resulta muy útil en muchos casos, tanto que vamos a hablar un +rato al respecto y mostrar algunos de ellos. + +En principio, una ventaja importante es el poder revisar lo que hizo otro de +forma clara y contenida, concentrándonos sólo en los cambios introducidos y no +en el código preexistente. Esto es útil en muchos casos distintos, desde en un +grupo jerárquico en donde haya gente encargada de revisar y dar vistos buenos +a códigos de sus subordinados, en grupos en donde se dé la revisión entre +pares, o la colaboración, que suele ser moneda corriente (pensemos en el caso +de "esto no me sale, me ayudas?" o "que te parece esto?") en cualquier grupo +humano bien integrado. Nos permite compartir experiencia con nuestros +compañeros, permitiendo que otros vean las soluciones que les dimos a +problemas que surgieron en el pasado y pudiendo aprender de ellas. + +Otra aplicación muy útil, y que se utiliza frecuentemente en proyectos +opensource, es el usar el historial de changesets para ubicar que cambio +introdujo un bug. Si conocemos una versión que no tiene un bug y otra que sí, +podemos ir buscando hasta encontrar qué changeset fue el que introdujo el bug, +haciendo más fácil la comprensión del mismo y su posterior arreglo. + +También es posible combinar esto con tests de regresión, de forma tal que, +usando un mecanismo similar al descripto recién para los bugs, cuando notamos +que falla algún test, podemos ubicar qué cambio fue el que hizo que comience a +fallar. Inclusive algunos SCMs incorporan funcionalidad para realizar este +tipo de operaciones de forma automática. + +Tener este tipo de información también nos puede resultar útil para saber a +quien referirse acerca de una pieza de código en particular: podemos ver quien +fue el que introdujo o modifico ciertas líneas de código, y así saber a quien +recurrir en caso de problemas o necesitar consejo sobre las mismas. Esto es +especialmente importante en proyectos grandes o de larga vida en la cual es +probable que los desarrolladores originales hayan dejado el proyecto para +concentrarse en otras cosas y para el grupo que queda a cargo suele ser +importante saber a quien recurrir. + +Pero quizás la utilidad más importante de todas no provenga de la información +misma, sino de la forma en la que se genera: el hecho de que nosotros tengamos +que pensar en changesets nos ayuda a trabajar de forma más ordenada y prolija, +concentrándonos en un problema a la vez y atacándolo sin mezclar las cosas, +correspondiéndose con la forma de pensarlo abstractamente. + +Es por esto que estas herramientas no son simples ayudas técnicas: afectan +nuestra forma de crear software, y deben acompañar y ajustarse a la manera en +la que concebimos y desarrollamos el software. + + + +Dos formas de ver a los SCMs +---------------------------- + +Todo lo que hablamos hasta ahora lo vimos de una forma relativamente general, +pero hay muchas cosas que al llevarlas a la práctica se pueden abordar de +formas distintas, y que implican formas distintas de trabajar. + +Existen dos "paradigmas" (a todo el mundo le encanta esa palabra, no? Se +sienten re importantes sabiendo lo que quiere decir =) para el funcionamiento +de los SCMs: centralizados y distribuidos. + +Aclaremos que el concepto de distribuido no es el que se suele usar en algunos +ámbitos como "algo que usa la red", sino el que se suele usar más comúnmente +(o más correctamente), que significa que no existe un punto central, sino que +las cosas están repartidas de forma más o menos horizontal. Algo así como la +diferencia entre peer-to-peer y cliente-servidor. + + + +SCMs centralizados +------------------ + +Los SCMs centralizados, como es de suponerse, se basan en un repositorio único +central con todas las letras (es decir, que guarda la historia de changesets), +al que todos los desarrolladores se conectan para reportar cambios (aplicar +changesets). Por otro lado aparece el concepto de lo que se conoce como +"working copy" (WC), que podría pensarse, según lo visto anteriormente, como +un branch muy particular, que no tiene historia (más allá de que algunos SCM +le ponen algo de historia para facilitar algunas operaciones offline). + +Al haber un sólo repositorio, éste debe ser el encargado de manejar los +branches, quedando todos dentro de éste. Es decir, en un mismo repositorio +tengo 2 (o más) caminos evolutivos distintos del mismo programa. La forma en que +se implementa esto, varía de SCM en SCM, pero el concepto general se mantiene. + +A diferencia de los SCM distribuido (que son algo así como el caso más general), +los SCM centralizados suelen basarse en una línea de tiempo. Es decir, los +cambios guardan una dependencia lineal en el tiempo. Es decir, para obtener un +changeset X, debo obtener, en orden cronológico, todos los changesets que se han +aplicado anteriormente. + +Otra cosa a tener en cuenta a la hora de elegir un SCM es que los centralizados, +al ser naturalmente cliente-servidor, necesitan un servidor (que probablemente +esté prendido todo el tiempo y con conexión permanente) y que debe ser +configurado, con algún sistema de autenticación y permisos. Es decir, la +configuración puede ser algo más compleja, claro que todo depende de qué +necesitemos hacer. La configuración puede ser tan simple o compleja como +queramos dependiendo del uso que vamos a darle (por lo general hacer un +repositorio local es trivial). + +Otra "contra" que acarrea su naturaleza cliente-servidor, es que, generalmente, +todas las operaciones del SCM son online (es decir, requieren conexión con el +servidor). Por ejemplo para ver la historia del repositorio, para obtener un +chageset determinado, para aplicar un changeset, etc... + +Generalmente hay 2 tipos de SCM centralizados, los que usan el modelo +Lock-Modify-Unlock y los que usan el modelo Copy-Modify-Merge. El primero es el +más simple y limitado, y consiste en que cada vez que un usuario quiere +modificar un archivo, este archivo se "lockea" y no puede ser modificado por +nadie más hasta que este usuario termine de editarlo. Este modelo, además de ser +muy limitado e incómodo, rompe bastante el concepto de changeset, ya que los +cambios están centrados en archivos y en cambios al repositorio como un todo. +El segundo modelo propone lo siguiente: se hace una copia del estado actual del +repositorio (sería nuestra WC), se modifica y se aplica el changeset al +repositorio central haciendo un merge. Cualquier SCM mínimamente serio ofrece +esta forma de trabajo. + + +Caso de estudio de SCM Centralizado: Subversion +----------------------------------------------- + +Una de las principales características de subversion, es que fue pensado como +un reemplazo natural a CVS, por lo que es una excelente transición si se quiere +pasar de CVS a otro SCM un poco más serio o incluso si se quiere seguir +trabajando con un modelo centralizado, ya que soluciona la mayoría de sus +problemas técnicos y conceptuales. + +Subversion usa el modelo Copy-Modify-Merge y trata siempre de optimizar el uso +de ancho de banda y de hacer todas las operaciones posible sin necesidad de +conexión. Esto lo hace simplemente guardando una copia intacta del estado del +repositorio y otra para que modifiquemos (algo así como guardar un pedacito de +historia). De esta manera, hay algunas operaciones que pueden hacerse offline. +Entre ellas, la más importante es el diff, ya que de esta manera puede enviar al +servidor solamente el changeset (otros SCM más viejitos, CVS incluido, tienen +que mandar los archivos modificados enteros y hacer el diff en el servidor). +Es decir, el uso de ancho de banda en subversion al aplicar un changeset es +proporcional al tamaño de los cambios y no de los archivos enteros, como pasa en +otros SCMs. + +Otro concepto muy fuerte en Subversion, es que es un filesystem versionado. Es +decir, un sistema de archivo (conjunto organizado jerárquicamente de +directorios y archivos, y sus contenidos, por supuesto). Es por esto que provee +las operaciones comunes de cualquier filesystem (crear un directorio, copiar un +archivo, mover un archivo, borrar un archivo, etc), con algunas +particularidades. Como subversion piensa a los repositorios como una línea de +tiempo, la hacer una copia de un archivo A a B, en realidad no se copia el +archivo sino que se dice que el archivo copiado B es una bifurcación en la línea +de tiempo del archivo A. Es decir: + ARCHIVO A + ========= + | + Revision 1 + | + Revision 2 ------- ARCHIVO B + | ========= + Revision 3 | + | | + | Revisión 4 + | | + +Es decir, la historia del archivo B, será su historia propia más la historia del +archivo A hasta la revisión 2. Las revisiones serían los changesets que se +fueron aplicando al repositorio (que como son cronológicamente ordenados, se +numeran secuencialmente). + +A esta característica se la llama "cheap copy" (copia barata) y es la manera en +la que subversion implementa los branches. Es decir, suponganse que en vez de +ser archivos son directorios, lo que tenemos son 2 evoluciones distintas de la +misma base de código. Por supuesto en un determinado momento podemos aplicar los +changesets de un branch en el otro a través de un merge. +Ahora, si los branches se almacenan en el repositorio como simples directorios, +es necesario tener una estructura particular en él, que nos permita ubicar +fácilmente distintos branches de un proyecto, o su línea de desarrollo +principal, etc. Lo que propone el manual, y uno de los esquemas más utilizados, +es crear 3 dirctorios en la raíz del repositorio apenas se lo crea, llamdos +'trunk' (línea principal de desarrollo), 'branches' y 'tags' (tag es un nombre +utilizado generalmente para indicar un estado significativo del respositorio, en +general realeases). De esta forma, hacer un branch sería tan simple como copiar +'trunk' a 'branches/mi_branch' para crear el branch 'mi_branch'. + +Un par de características agradables de subversion, que no tiene demasiado que +ver con la teoría que estuvimos introduciendo, son la alta disponibilidad de +clientes (hay para todos los gustos y OSs, tanto de consola como gráficos) y +las propiedades. Estas últimas son metainformación arbitraria o con significado +especial que se asocia a un archivo o directorio. A través de estas propiedades +subversion maneja algunas cosas interesantes, como el tipo de fin de línea, si +es un archivo binario y de qué tipo (para utilizar la herramienta de diff +correcta), si es ejecutable, etc. Con respecto a los clientes, sólo voy a decir +que nosotros nos centraremos en el cliente "oficial" llamado svn, que es un +cliente de consola multiplataforma (la gente que use WIN32 tal vez quiera darle +una mirada a Tortoise, un cliente gráfico que se integra con el shell). + + +SCMs distribuidos +----------------- + +La idea detrás de los SCMs distribuidos es que no exista un repositorio +central obligatoriamente, sino que basan su comportamiento en la existencia y +el uso de múltiples repositorios "hermanos", que pueden intercambiarse cambios +unos con otros. No hay un repositorio "maestro" con el cual todos se comparan. + +Esto hace que la operación de "merge" que hablamos antes se vuelva muy +importante, dado que se realiza de forma muy frecuente al pasar los cambios de +un repositorio a otro. + +La forma de trabajo descentralizada nos permite que dos desarrolladores tomen +un mismo repositorio, hagan cada uno su propio branch, trabajen sobre él de +forma independiente, integrando luego los cambios entre sí de forma natural, +manteniendo en todo momento la historia y la consistencia. + +Hay varios SCMs distribuidos, últimamente están bastante de moda, algunos +ejemplos son Darcs, Arch, Monotone, Codeville y Bitkeeper. + + + +Ejemplos prácticos +------------------ + +En el directorio 'ejemplos' hay algunas páginas HTML con ejemplos prácticos, +tanto de darcs como de subversion. + + diff --git a/charla_scm/ejemplos/darcs/1-basico.html b/charla_scm/ejemplos/darcs/1-basico.html new file mode 100644 index 0000000..770ecfc --- /dev/null +++ b/charla_scm/ejemplos/darcs/1-basico.html @@ -0,0 +1,185 @@ + + +darcs :: Ejemplo 1 + + + + +

Ejemplo 1 - En la cueva

+ +En este primer ejemplo vamos a hablar de varias de las operaciones que ya +mencionamos. Todas van a ser lineales y aisladas, en el sentido de que van a +trabajar sobre un solo repositorio y de forma secuencial.

+ +Antes que nada, creamos el repositorio
+ +

+Creamos el directorio del repo
+# mkdir recetas
+# cd recetas
+
+Creamos el repo con darcs
+# darcs init
+
+Vemos que se crea el directorio especial
+# ls -l
+total 8
+drwxr-xr-x  6 root root 4096 May 17 22:43 _darcs
+#
+
+ +Ahora agregamos el primer archivo
+ +
+Creamos un archivo nuevo editandolo
+# vi arroz
+#
+Lo incorporamos al repositorio
+# darcs add arroz
+#
+
+

+ +Y hacemos un record para grabar el cambio en el repositorio: + +

+# darcs record
+Solo la primera vez nos pregunta nombre y email
+Darcs needs to know what name (conventionally an email address) to use as the
+patch author, e.g. 'Fred Bloggs <fred@bloggs.invalid>'.  If you provide one
+now it will be stored in the file '_darcs/prefs/author' and used as a default
+in the future.  To change your preferred author address, simply delete or edit
+this file.
+
+What is your email address? Alberto Bertogli <albertogli@telpin.com.ar>
+
+Nos pregunta cambio por cambio que queremos hacer
+El primero es la incorporacion del archivo
+addfile ./arroz
+Shall I record this patch? (1/2) [ynWsfqadjk], or ? for help: y
+
+Y el segundo el contenido del mismo
+hunk ./arroz 1
++
++poner agua a hervir con sal (ponerle poca sal)
++
++cuando hierva agregar el arroz y bajar un poco el fuego
++
++cuando este, sacarlo colandolo bajo agua fria para cortar la coccion
++
++ponerle aceite, puede ser de oliva; poner tambien un chorrin en la fuente
++antes, abajo del arroz
++
++cuatro tazas de agua x una de arroz
++una taza de arroz por persona (salen 2 platos)
++
++
+Shall I record this patch? (2/2) [ynWsfqadjk], or ? for help: y
+Ahora nos pide un nombre corto para el patch
+What is the patch name? Agregamos una receta para el arroz
+Y, opcionalmente, podemos poner una descripcion larga
+Do you want to add a long comment? [yn] n
+Finished recording patch 'Agregamos una receta para el arroz'
+
+ +Vemos el historial de cambios
+ +
+# darcs changes
+Tue May 17 22:45:00 ART 2005  Alberto Bertogli 
+  * Agregamos una receta para el arroz
+#
+
+ +Ahora hagamos un cambio chico editando un poco el contenido, y antes de hacer +un record queremos ver el diff, asi nos aseguramos que este todo bien; despues +lo grabamos con un record.
+ +
+Editamos un poco
+# vi arroz
+#
+Vemos los cambios
+# darcs diff -u
+diff -rN -u old-recetas/arroz new-recetas/arroz
+--- old-recetas/arroz   2005-05-17 23:32:18.000000000 -0300
++++ new-recetas/arroz   2005-05-17 23:32:49.000000000 -0300
+@@ -1,5 +1,5 @@
+
+-poner agua a hervir con sal (ponerle poca sal)
++poner agua a hervir con poca sal
+
+ cuando hierva agregar el arroz y bajar un poco el fuego
+
+@@ -8,7 +8,7 @@
+ ponerle aceite, puede ser de oliva; poner tambien un chorrin en la fuente
+ antes, abajo del arroz
+
+-cuatro tazas de agua x una de arroz
++cuatro tazas de agua por una de arroz
+ una taza de arroz por persona (salen 2 platos)
+
+#
+Nos parecio bien lo que ibamos a cambiar, asi que hacemos el
+record
+# darcs record
+hunk ./arroz 2
+-poner agua a hervir con sal (ponerle poca sal)
++poner agua a hervir con poca sal
+Shall I record this patch? (1/2) [ynWsfqadjk], or ? for help: y
+hunk ./arroz 11
+-cuatro tazas de agua x una de arroz
++cuatro tazas de agua por una de arroz
+Shall I record this patch? (2/2) [ynWsfqadjk], or ? for help: y
+What is the patch name? Unos pequeños cambios.
+Do you want to add a long comment? [yn] y
+Aca abre el editor de texto y escribimos una descripcion un
+poco mas larga
+Finished recording patch 'Unos pequeños cambios.'
+#
+
+ +Ahora hacemos otros cambios mas que creemos que estan bien, pero despues +llamamos a nuestra mama y ella nos grita "Horror! No hagas eso nene que se te +va a quemar todo", asi que queremos volver a como estabamos antes de +empezar.
+Vamos a mostrar ahora la salida un poco resumida, para no cargar de cosas que +ya vimos y no son relevantes.
+ +
+Primero editamos
+# vi arroz
+# darcs diff -u
+[...]
+#
+Aca llamamos a nuestra mama, y se horroriza. Volvemos todo para
+atras, hasta el ultimo record que hicimos
+# darcs revert
+(nos muestra los cambios uno por uno, como cuando hacemos un
+record, y elegimos que volvemos atras y que no)
+[...]
+Shall I revert this patch? (1/1) [ynWsfqadjk], or ? for help: y
+Do you really want to do this? y
+Finished reverting.
+#
+
+ +Pero claro, a medida que pasa el tiempo nos vamos poniendo mas cancheros con +el arroz, y decidimos que la receta del arroz tal como esta ahi deberia +llamarse "arroz-solo", asi que la renombramos. + +
+# darcs mv arroz arroz-solo
+# ls -l
+total 16
+4 -rw-r--r--  1 root root  347 May 17 23:51 arroz-solo
+4 drwxr-xr-x  6 root root 4096 May 18 00:14 _darcs
+#
+
+ +Bueno, ya vimos bastante acerca de como trabajar solos, salgamos un poco al +mundo y veamos que hay ahi afuera.

+ + + + diff --git a/charla_scm/ejemplos/darcs/2-comun.html b/charla_scm/ejemplos/darcs/2-comun.html new file mode 100644 index 0000000..81535b2 --- /dev/null +++ b/charla_scm/ejemplos/darcs/2-comun.html @@ -0,0 +1,145 @@ + + +darcs :: Ejemplo 2 + + + + +

Ejemplo 1 - Vemos la luz

+ +Ahora que ya sabemos operar con las cosas mas comunes, vamos a ver como +interactuamos con otros repositorios, sean o no nuestros.

+ +El primer ejemplo va a ser obtener un repositorio existente, que esta +publicado por web. Recordemos que darcs no depende de como se publiquen, +podrian ser locales, remotos por web, etc. Si en lugar de hacer esto, +hicieramos un "cp -a", o nos lo pasaran en un archivo comprimido seria igual +de valido.
+Vamos a usar un repositorio real, chico y con pocos cambios.
+ +

+# darcs get http://auriga.wearlab.de/~alb/repos/libfilo
+Copying patch 23 of 23... done!
+Applying patches to the "working" directory...
+..............................................
+Finished getting.
+#
+Vemos que se bajo el repo
+# ls -l
+total 12
+4 drwxr-xr-x  5 root root 4096 May 18 00:46 libfilo
+# cd libfilo
+# ls -l
+total 44
+drwxr-xr-x  7 root root  4096 May 18 00:50 _darcs
+drwxr-xr-x  2 root root  4096 May 18 00:50 doc
+-rw-r--r--  1 root root  1150 May 18 00:50 INSTALL
+-rw-r--r--  1 root root 12706 May 18 00:50 libfilo.c
+-rw-r--r--  1 root root  2084 May 18 00:50 libfilo.h
+-rw-r--r--  1 root root  1077 May 18 00:50 Makefile
+-rw-r--r--  1 root root  1159 May 18 00:50 README
+drwxr-xr-x  2 root root  4096 May 18 00:50 tests
+#
+Revisamos los ultimos 5 cambios, de chusmas nomas
+# darcs changes --last=5
+Wed Apr 27 18:39:46 ART 2005  Alberto Bertogli <albertogli@telpin.com.ar>
+  tagged 0.11
+
+Wed Apr 27 18:10:46 ART 2005  Jose Aureliano Buendia <jaureliano@buendia.com>
+  * Force the library to be compiled with LFS support.
+
+Wed Apr 27 18:10:15 ART 2005  Remedios Moscote <remedios@moscote.com>
+  * Update the README to add the new manpage.
+
+Wed Apr 27 18:04:24 ART 2005  Alberto Bertogli <albertogli@telpin.com.ar>
+  * Add an INSTALL document.
+
+Wed Apr 27 18:04:09 ART 2005  Alberto Bertogli <albertogli@telpin.com.ar>
+  * Add manpage support in the Makefile.
+#
+
+ +Notemos que el ultimo cambio es distinto, se llama "tag" y lo usamos para +versionar el repositorio, poniendole marcas con nombres a medida que +querramos, que refieren al estado del repositorio en ese momento. Se hacen con +"darcs tag".

+ +Un rato despues queremos actualizar nuestro repositorio, bajandonos cualquier +cambio que este en el remoto que nosotros no tengamos.
+ +

+Le pasamos como primer parametro el repositorio del cual
+queremos ver los cambios, y si lo omitimos usa el ultimo que usamos.
+# darcs pull
+Pulling from "http://auriga.wearlab.de/~alb/repos/libfilo"...
+No remote changes to pull in!
+#
+No habia nada que traer! Pero mas tarde, volvemos a probar
+# darcs pull
+Wed May 18 01:01:00 ART 2005  Amaranta Buendia <amaranta@buendia.com>
+  * Sacar prints de debug innecesarios.
+Shall I pull this patch? (1/1) [ynWvxqadjk], or ? for help: y
+Finished pulling and applying.
+#
+
+ +Ahora trabajamos un poco nosotros en el repositorio, haciendo algunos records +como ya vimos. Y despues de un rato, cuando estamos conformes, decidimos +mandarle a un amigo nuestro los cambios, para que los mire y nos diga que le +parecen.
+Vamos a hacer dos alternativas: o dejar que darcs mande el mail directamente, +o que nos genere un archivo que nosotros mandamos como attach con nuestro +mailer.
+El envio siempre se hace respecto de un repositorio remoto, y mandamos lo que +esta en el nuestro que no este en el otro. En este caso enviamos contra el +publicado.
+ +
+Alternativa 1: darcs manda el mail
+# darcs send http://users.auriga.wearlab.de/~alb/repos/libfilo
+Wed May 18 01:01:00 ART 2005  Aureliano Buendia <aureliano@buendia.com>
+  * Un cambio poco relevante.
+Shall I send this patch? (1/1) [ynWvxqadjk], or ? for help: y
+
+What is the target email address? Arcadio Buendia <arcadio@buendia.com>
+Successfully sent patch bundle to Arcadio Buendia <arcadio@buendia.com>.
+#
+Aca, el mail se le envio a Arcadio con esos cambios
+
+ +
+Alternativa 2: darcs nos deja un archivo para enviar adjunto
+# darcs send -o /tmp/enviar http://users.auriga.wearlab.de/~alb/repos/libfilo
+Wed May 18 01:01:00 ART 2005  Aureliano Buendia <aureliano@buendia.com>
+  * Un cambio poco relevante.
+Shall I send this patch? (1/1) [ynWvxqadjk], or ? for help: y
+#
+Aca nos dejo el archivo "/tmp/enviar" con los cambios
+seleccionados
+
+ +Ahora pensemos que a nosotros nos llega un mail con los cambios en un archivo +adjunto, el cual grabamos en /tmp/para_aplicar y queremos aplicar a nuestro +repositorio.
+ +
+# darcs apply /tmp/para_aplicar
+Finished applying...
+#
+Termino de aplicar, miramos el changelog de curiosos nomas
+# darcs chan --last=2
+Wed May 18 00:24:00 ART 2005  Apolinar Moscote <apolinar@moscote.com>
+  * Reordenamos las funciones, porque si.
+
+Wed May 18 01:01:00 ART 2005  Aureliano Buendia <aureliano@buendia.com>
+  * Un cambio poco relevante.
+#
+
+ +No hay muchas mas operaciones básicas que estas, la gracia del asunto esta en +como la combinacion de las mismas puede presentar situaciones delicadas, que +vamos a ver un poco en el siguiente y ultimo ejemplo.

+ + + + diff --git a/charla_scm/ejemplos/darcs/3-loco.html b/charla_scm/ejemplos/darcs/3-loco.html new file mode 100644 index 0000000..ec64d2e --- /dev/null +++ b/charla_scm/ejemplos/darcs/3-loco.html @@ -0,0 +1,205 @@ + + +darcs :: Ejemplo 3 + + + + +

Ejemplo 3 - Chocamos

+ +Si bien si somos ordenados al trabajar no deberia darse comunmente, los +conflictos entre merges son un tema muy importante porque si no son manejados +correctamente pueden acarrear serios problemas en el repositorio.
+Veamos como generar uno simple, y como corregirlo.

+ +Vamos a arrancar con un repositorio base del cual hacemos get para obtener dos +repositorios independientes, en los cuales realizamos cambios de forma +aislada.
+ +

+Partimos de una base comun; mostramos los cambios
+# cd base
+# darcs chan
+Wed May 18 02:57:06 ART 2005  Base <base@ej.com.ar>
+  * Agregamos el archivo inicial.
+Mostramos un poco del archivo "cancion"
+# cat cancion
+Tú surgías desde el Cono Sur
+y venías desde antes,
+con el amor al mundo bien adentro.
+Fuk unx kstrkllx quk tk puso xquí
+y tk hizo dk kstk pukblo.
+Dk grxtitud nxcikron muchos hombrks
+quk iguxl quk tú,
+no qukríxn quk tk fukrxs
+y son otros desde entonces.
+[...]
+# cd ..
+#
+Hacemos un get de base, creando un nuevo repo A
+# darcs get base A
+Copying patch 1 of 1... done!
+Finished getting.
+#
+Y ahora creamos B
+# darcs get base B
+Copying patch 1 of 1... done!
+Finished getting.
+#
+
+ +
+Tenemos tres repos iguales, vamos a hacer un cambio en A y a
+arreglar un poco el archivo de arriba.
+# cd A
+# vi cancion
+Uno de los problemas con el archivo es que algunas 'a's estan
+cambiadas por 'x's, editamos para arreglar eso; y luego hacemos un record
+# darcs record
+[...]
+# darcs changes --last=1
+Wed May 18 03:01:42 ART 2005  Fulano A <a@fulano.com.ar>
+  * Arreglar la letra A.
+# cd ..
+#
+Vamos ahora a hacer un cambio en B.
+# cd B
+# vi cancion
+Como antes, arreglamos "cancion", cambiando 'k's por 'e's
+# darcs record
+[...]
+# darcs changes --last=1
+Wed May 18 03:08:00 ART 2005  Fulano B <b@fulano.com.ar>
+  * Arreglar la letra E.
+# cd ..
+#
+
+ +Miremos un poco como estan los archivos hasta ahora.
+ +
+El archivo base
+# cat base/cancion
+Tú surgías desde el Cono Sur
+y venías desde antes,
+con el amor al mundo bien adentro.
+Fuk unx kstrkllx quk tk puso xquí
+y tk hizo dk kstk pukblo.
+Dk grxtitud nxcikron muchos hombrks
+quk iguxl quk tú,
+no qukríxn quk tk fukrxs
+y son otros desde entonces.
+[...]
+#
+El archivo del repositorio A
+# cat A/cancion
+Tú surgías desde el Cono Sur
+y venías desde antes,
+con el amor al mundo bien adentro.
+Fuk una kstrklla quk tk puso aquí
+y tk hizo dk kstk pukblo.
+Dk gratitud nacikron muchos hombrks
+quk igual quk tú,
+no qukrían quk tk fukras
+y son otros desde entonces.
+[...]
+#
+El archivo del repositorio B
+# cat B/cancion
+Tú surgías desde el Cono Sur
+y venías desde antes,
+con el amor al mundo bien adentro.
+Fue unx estrellx que te puso xquí
+y te hizo de este pueblo.
+De grxtitud nxcieron muchos hombres
+que iguxl que tú,
+no queríxn que te fuerxs
+y son otros desde entonces.
+[...]
+#
+
+ +Vamos a tratar de incorporar los cambios de B en A. + +
+# cd A
+# darcs pull ../B
+Wed May 18 03:08:00 ART 2005  Fulano B <b@fulano.com.ar>
+  * Arreglar la letra E.
+Shall I pull this patch? (1/1) [ynWvxqadjk], or ? for help: y
+We have conflicts in the following files:
+./cancion
+Finished pulling and applying.
+#
+
+ +Como vemos, nos dijo que habia conflictos en el archivo. Esto es esperable, +dado que darcs solo no puede resolver los cambios pues afectan a las mismas +lineas de los archivos, y no hay una forma en la que pueda aplicar los cambios +sin garantizar que no se generan problemas.

+Por eso nos avisa, para que nosotros "conciliemos" los dos cambios y dejemos +una version valida. Entonces vemos que hay en el archivo con conflictos, y lo +editamos para dejar una version definitiva.
+ +

+# cat cancion
+Tú surgías desde el Cono Sur
+y venías desde antes,
+con el amor al mundo bien adentro.
+v v v v v v v
+Fue unx estrellx que te puso xquí
+y te hizo de este pueblo.
+De grxtitud nxcieron muchos hombres
+que iguxl que tú,
+no queríxn que te fuerxs
+*************
+Fuk una kstrklla quk tk puso aquí
+y tk hizo dk kstk pukblo.
+Dk gratitud nacikron muchos hombrks
+quk igual quk tú,
+no qukrían quk tk fukras
+^ ^ ^ ^ ^ ^ ^
+y son otros desde entonces.
+[...]
+#
+Nos encierra entre "v v v v" y "^ ^ ^ ^" las dos "versiones",
+una de cada cambio, y espera que nosotros dejemos una definitiva, para lo cual
+editamos. En este caso tenemos que hacer varios reemplazos a mano para que
+quede una version completa.
+# vi cancion
+# cat cancion
+Tú surgías desde el Cono Sur
+y venías desde antes,
+con el amor al mundo bien adentro.
+Fue una estrella que te puso aquí
+y te hizo de este pueblo.
+De gratitud nacieron muchos hombres
+que igual que tú,
+no querían que te fueras
+y son otros desde entonces.
+[...]
+#
+Entonces hacemos un record, para grabar este patch
+"conciliador"
+# darcs record
+[...]
+#
+Vemos todo el historial de cambios
+# darcs changes
+Wed May 18 03:21:22 ART 2005  Fulano A <a@fulano.com.ar>
+  * Conciliamos el conflicto.
+
+Wed May 18 03:08:00 ART 2005  Fulano B <b@fulano.com.ar>
+  * Arreglar la letra E.
+
+Wed May 18 03:01:42 ART 2005  Fulano A <a@fulano.com.ar>
+  * Arreglar la letra A.
+
+Wed May 18 02:57:06 ART 2005  Base <base@ej.com.ar>
+  * Agregamos el archivo inicial.
+#
+
+ + + + diff --git a/charla_scm/ejemplos/diff/1-basico/archivo1 b/charla_scm/ejemplos/diff/1-basico/archivo1 new file mode 100644 index 0000000..82bbed0 --- /dev/null +++ b/charla_scm/ejemplos/diff/1-basico/archivo1 @@ -0,0 +1,58 @@ +Gloria a Dios en las alturas, +recogieron las basuras +de mi calle, ayer a oscuras +y hoy sembrada de bombillas. + +Y colgaron de un cordel +de esquina a esquina un cartel +y banderas de papel +verdes, rojas y amarillas. + +Y al darles el sol la espalda +revolotean las faldas +bajo un manto de guirnaldas +para que el cielo no vea, + +en la noche de San Juan, +cómo comparten su pan, +su tortilla y su gabán, +gentes de cien mil raleas. + +Apurad +que allí os espero si queréis venir +pues cae la noche y ya se van +nuestras miserias a dormir. + +Vamos subiendo la cuesta +que arriba mi calle +se vistió de fiesta. + +Hoy el noble y el villano, +el prohombre y el gusano +bailan y se dan la mano +sin importarles la facha. + +Juntos los encuentra el sol +a la sombra de un farol +empapados en alcohol +abrazando a una muchacha. + +Y con la resaca a cuestas +vuelve el pobre a su pobreza, +vuelve el rico a su riqueza +y el señor cura a sus misas. + +Se despertó el bien y el mal +la pobre vuelve al portal +la rica vuelve al rosal +y el avaro a las divisas. + +Se acabó, +que el sol nos dice que llegó el final. +Por una noche se olvidó +que cada uno es cada cual. + +Vamos bajando la cuesta +que arriba en mi calle +se acabó la fiesta. + diff --git a/charla_scm/ejemplos/diff/1-basico/archivo2 b/charla_scm/ejemplos/diff/1-basico/archivo2 new file mode 100644 index 0000000..a3bad46 --- /dev/null +++ b/charla_scm/ejemplos/diff/1-basico/archivo2 @@ -0,0 +1,58 @@ +Gloria a Dios en las alturas, +recogieron las basuras +de mi calle, ayer a oscuras +y hoy sembrada de bombillas. + +Y colgaron de un cordel +de esquina a esquina un cartel +y banderas de papel +lilas, rojas y amarillas. + +Y al darles el sol la espalda +revolotean las faldas +bajo un manto de guirnaldas +para que el cielo no vea, + +en la noche de San Juan, +cómo comparten su pan, +su mujer y su galán, +gentes de cien mil raleas. + +Apurad +que allí os espero si queréis venir +pues cae la noche y ya se van +nuestras miserias a dormir. + +Vamos subiendo la cuesta +que arriba mi calle +se vistió de fiesta. + +Hoy el noble y el villano, +el prohombre y el gusano +bailan y se dan la mano +sin importarles la facha. + +Juntos los encuentra el sol +a la sombra de un farol +empapados en alcohol +magreando a una muchacha. + +Y con la resaca a cuestas +vuelve el pobre a su pobreza, +vuelve el rico a su riqueza +y el señor cura a sus misas. + +Se despertó el bien y el mal +la zorra pobre al portal +la zorra rica al rosal +y el avaro a las divisas. + +Se acabó, +que el sol nos dice que llegó el final. +Por una noche se olvidó +que cada uno es cada cual. + +Vamos bajando la cuesta +que arriba en mi calle +se acabó la fiesta. + diff --git a/charla_scm/ejemplos/diff/1-basico/diferencia b/charla_scm/ejemplos/diff/1-basico/diferencia new file mode 100644 index 0000000..d71cb4d --- /dev/null +++ b/charla_scm/ejemplos/diff/1-basico/diferencia @@ -0,0 +1,40 @@ +--- archivo1 2005-05-17 12:57:00.000000000 -0300 ++++ archivo2 2005-05-17 12:54:38.000000000 -0300 +@@ -6,7 +6,7 @@ + Y colgaron de un cordel + de esquina a esquina un cartel + y banderas de papel +-verdes, rojas y amarillas. ++lilas, rojas y amarillas. + + Y al darles el sol la espalda + revolotean las faldas +@@ -15,7 +15,7 @@ + + en la noche de San Juan, + cómo comparten su pan, +-su tortilla y su gabán, ++su mujer y su galán, + gentes de cien mil raleas. + + Apurad +@@ -35,7 +35,7 @@ + Juntos los encuentra el sol + a la sombra de un farol + empapados en alcohol +-abrazando a una muchacha. ++magreando a una muchacha. + + Y con la resaca a cuestas + vuelve el pobre a su pobreza, +@@ -43,8 +43,8 @@ + y el señor cura a sus misas. + + Se despertó el bien y el mal +-la pobre vuelve al portal +-la rica vuelve al rosal ++la zorra pobre al portal ++la zorra rica al rosal + y el avaro a las divisas. + + Se acabó, diff --git a/charla_scm/ejemplos/diff/2-merge/archivo1 b/charla_scm/ejemplos/diff/2-merge/archivo1 new file mode 100644 index 0000000..ed7a2bd --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/archivo1 @@ -0,0 +1,10 @@ +La colina hay que subir, +nada es sencillo aquí, +y ante todo está El Dragón +con su fuego intentará +parar la construcción +pero habrá una solución +Cuando tiene mucha hambre +busca bichitos de luz +y se los come despacito. + diff --git a/charla_scm/ejemplos/diff/2-merge/archivo2 b/charla_scm/ejemplos/diff/2-merge/archivo2 new file mode 100644 index 0000000..dd1879f --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/archivo2 @@ -0,0 +1,10 @@ +La colina hay que subir, +nada es sencillo aquí, +y ante todo está El Dragón +Al Dragón le gusta tirarse panza arriba +y ponerse a leer cuentos alegres +mientras se rasca la barriga. +Una flor un corazón, +una porción de sol, +y estas ganas de vivir... + diff --git a/charla_scm/ejemplos/diff/2-merge/base b/charla_scm/ejemplos/diff/2-merge/base new file mode 100644 index 0000000..39acfad --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/base @@ -0,0 +1,10 @@ +La colina hay que subir, +nada es sencillo aquí, +y ante todo está El Dragón +Al Dragón le gusta tirarse panza arriba +y ponerse a leer cuentos alegres +mientras se rasca la barriga. +Cuando tiene mucha hambre +busca bichitos de luz +y se los come despacito. + diff --git a/charla_scm/ejemplos/diff/2-merge/diferencia1 b/charla_scm/ejemplos/diff/2-merge/diferencia1 new file mode 100644 index 0000000..0d1d355 --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/diferencia1 @@ -0,0 +1,15 @@ +--- base 2005-05-17 13:16:10.000000000 -0300 ++++ archivo1 2005-05-17 13:16:39.000000000 -0300 +@@ -1,9 +1,9 @@ + La colina hay que subir, + nada es sencillo aquí, + y ante todo está El Dragón +-Al Dragón le gusta tirarse panza arriba +-y ponerse a leer cuentos alegres +-mientras se rasca la barriga. ++con su fuego intentará ++parar la construcción ++pero habrá una solución + Cuando tiene mucha hambre + busca bichitos de luz + y se los come despacito. diff --git a/charla_scm/ejemplos/diff/2-merge/diferencia2 b/charla_scm/ejemplos/diff/2-merge/diferencia2 new file mode 100644 index 0000000..031f762 --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/diferencia2 @@ -0,0 +1,13 @@ +--- base 2005-05-17 13:16:10.000000000 -0300 ++++ archivo2 2005-05-17 13:16:57.000000000 -0300 +@@ -4,7 +4,7 @@ + Al Dragón le gusta tirarse panza arriba + y ponerse a leer cuentos alegres + mientras se rasca la barriga. +-Cuando tiene mucha hambre +-busca bichitos de luz +-y se los come despacito. ++Una flor un corazón, ++una porción de sol, ++y estas ganas de vivir... + diff --git a/charla_scm/ejemplos/diff/2-merge/diferenciaJ b/charla_scm/ejemplos/diff/2-merge/diferenciaJ new file mode 100644 index 0000000..9d25dc8 --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/diferenciaJ @@ -0,0 +1,19 @@ +--- base 2005-05-17 13:16:10.000000000 -0300 ++++ juntos 2005-05-17 13:17:34.000000000 -0300 +@@ -1,10 +1,10 @@ + La colina hay que subir, + nada es sencillo aquí, + y ante todo está El Dragón +-Al Dragón le gusta tirarse panza arriba +-y ponerse a leer cuentos alegres +-mientras se rasca la barriga. +-Cuando tiene mucha hambre +-busca bichitos de luz +-y se los come despacito. ++con su fuego intentará ++parar la construcción ++pero habrá una solución ++Una flor un corazón, ++una porción de sol, ++y estas ganas de vivir... + diff --git a/charla_scm/ejemplos/diff/2-merge/juntos b/charla_scm/ejemplos/diff/2-merge/juntos new file mode 100644 index 0000000..2b7de37 --- /dev/null +++ b/charla_scm/ejemplos/diff/2-merge/juntos @@ -0,0 +1,10 @@ +La colina hay que subir, +nada es sencillo aquí, +y ante todo está El Dragón +con su fuego intentará +parar la construcción +pero habrá una solución +Una flor un corazón, +una porción de sol, +y estas ganas de vivir... + diff --git a/charla_scm/ejemplos/style.css b/charla_scm/ejemplos/style.css new file mode 100644 index 0000000..3612348 --- /dev/null +++ b/charla_scm/ejemplos/style.css @@ -0,0 +1,27 @@ + +h1,h2,h3,h4,h5 { + background-color: #3366cc; + color: #ffffff; + padding-left:3pt; + margin-top:2pt; + margin-bottom:8pt; + border-style:none; + border-width:thin; + width:100%; +} + +pre { + margin-top: 8pt; + margin-bottom: 8pt; + background-color: #E9E9E9; + white-space:pre; + border-style:none; + border-width:thin; + width:100%; +} + +tt.nota { + color: #006600; +} + + diff --git a/charla_scm/ejemplos/svn/1-basico.html b/charla_scm/ejemplos/svn/1-basico.html new file mode 100644 index 0000000..1f4365e --- /dev/null +++ b/charla_scm/ejemplos/svn/1-basico.html @@ -0,0 +1,183 @@ + + +darcs :: Ejemplo 1 + + + + +

Ejemplo 1 - En la cueva

+ +Yadda, yadda, yadda (mismo ejemplo 1 que en darcs) + +
+Creamos el repo
+# svnadmin create repo
+# cd repo
+
+Vemos que se crea el directorio especial
+# ls -l repo
+total 28
+drwxr-xr-x  2 guestlabi guestlabi 4096 2005-05-18 13:49 conf
+drwxr-xr-x  2 guestlabi guestlabi 4096 2005-05-18 13:49 dav
+drwxr-sr-x  2 guestlabi guestlabi 4096 2005-05-18 13:49 db
+-r--r--r--  1 guestlabi guestlabi    2 2005-05-18 13:49 format
+drwxr-xr-x  2 guestlabi guestlabi 4096 2005-05-18 13:49 hooks
+drwxr-xr-x  2 guestlabi guestlabi 4096 2005-05-18 13:49 locks
+-rw-r--r--  1 guestlabi guestlabi  379 2005-05-18 13:49 README.txt
+#
+
+ +Esto es un repositorio central, en el caso de usarlo nosotros solos es un +poco molesto porque hay que obtener una WC para trabajar en él. + +
+Obtenemos un WC
+# svn co file://$PWD/repo wc
+#
+
+ +Ahora creamos la estructura básica para branches (en este caso es un poco +overkill, pero lo hacemos a modo demostrativo). + +
+Obtenemos un WC
+# cd wc
+# svn mkdir trunk
+A         trunk
+# svn mkdir branches
+A         branches
+# svn mkdir tags
+A         tags
+#
+Hacemos un commit para poner registrar la estructura
+# svn ci -m 'Estructura general del repositorio.'
+Añadiendo      branches
+Añadiendo      tags
+Añadiendo      trunk
+#
+
+ +Ahora agregamos el primer archivo
+ +
+Creamos un archivo nuevo editandolo
+# cd trunk
+# vi arroz
+#
+Lo incorporamos al repositorio
+# svn add arroz
+A         arroz
+#
+Vemos el estado del repositorio
+# svn st
+A         arroz
+#
+
+

+ +Y volvemos a hacer un commit para grabar el cambio en el repositorio: + +

+# svn ci -m 'Nueva receta para hacer arroz.'
+Añadiendo      trunk/arroz
+Transmitiendo contenido de archivos .
+Commit de la revisión 2.
+#
+
+ +Vemos el historial de cambios
+ +
+# svn log arroz
+Muestra sólo las revisiones en dónde cambió este archivo
+------------------------------------------------------------------------
+r2 | guestlabi | 2005-05-18 15:31:13 -0300 (mié, 18 may 2005) | 1 line
+
+Nueva receta para hacer arroz.
+------------------------------------------------------------------------
+#
+
+ +Ahora hagamos un cambio chico editando un poco el contenido, y antes de hacer +un commit queremos ver el diff, asi nos aseguramos que este todo bien; despues +lo grabamos con un commit.
+ +
+Editamos un poco
+# vi arroz
+Vemos qué cambió
+# svn st
+M      arroz
+#
+Vemos los cambios
+# svn diff
+Index: arroz
+===================================================================
+--- arroz       (revisión: 2)
++++ arroz       (copia de trabajo)
+@@ -1,5 +1,5 @@
+
+-poner agua a hervir con sal (ponerle poca sal)
++poner agua a hervir con poca sal
+
+ cuando hierva agregar el arroz y bajar un poco el fuego
+
+@@ -8,7 +8,7 @@
+ ponerle aceite, puede ser de oliva; poner tambien un chorrin en la fuente
+ antes, abajo del arroz
+
+-cuatro tazas de agua x una de arroz
++cuatro tazas de agua por una de arroz
+ una taza de arroz por persona (salen 2 platos)
+
+#
+Nos parecio bien lo que ibamos a cambiar, asi que hacemos el ci
+# svn ci -m 'Unos pequeños cambios.'
+Enviando       trunk/arroz
+Transmitiendo contenido de archivos .
+Commit de la revisión 3.
+#
+
+ +Ahora hacemos otros cambios más que creemos que estan bien, pero después +llamamos a la mamá de Alberto y ella nos grita "Horror! No hagas eso nene que se te +va a quemar todo", así que queremos volver a como estabamos antes de +empezar.
+Vamos a mostrar ahora la salida un poco resumida, para no cargar de cosas que +ya vimos y no son relevantes.
+ +
+Primero editamos
+# vi arroz
+# svn diff
+[...]
+#
+Aca llamamos a la mamá de Alberto, y se horroriza. Volvemos todo para
+atrás, hasta el último commit que hicimos
+# svn revert arroz
+(hay que poner explícitamente los archivos a revertir, para evitar errores indeseados,  porque hay que tener en cuenta que esta operación puede borrar cosas importantes sin vuelta atrás)
+Se revirtió 'arroz'
+#
+
+ +Pero claro, a medida que pasa el tiempo nos vamos poniendo mas cancheros con +el arroz, y decidimos que la receta del arroz tal como esta ahi deberia +llamarse "arroz-solo", asi que la renombramos. + +
+# svn mv arroz arroz-solo
+Notar que el mv es un copy + delete, pero como el copy conserva la historia, no hay ningún problema.
+A         arroz-solo
+D         arroz
+# ls -l
+total 4
+-rw-r--r--  1 guestlabi guestlabi 358 2005-05-18 15:49 arroz-solo
+#
+
+ +Bueno, ya vimos bastante acerca de como trabajar solos, salgamos un poco al +mundo y veamos que hay ahi afuera.

+ + + + diff --git a/charla_scm/ejemplos/svn/2-comun.html b/charla_scm/ejemplos/svn/2-comun.html new file mode 100644 index 0000000..7790a0f --- /dev/null +++ b/charla_scm/ejemplos/svn/2-comun.html @@ -0,0 +1,166 @@ + + +darcs :: Ejemplo 2 + + + + +

Ejemplo 1 - Vemos la luz

+ +Ahora que ya sabemos operar con las cosas mas comunes, vamos a ver como +interactuamos con otros repositorios, sean o no nuestros.

+ +El primer ejemplo va a ser obtener un repositorio existente, que esta +publicado por web. Recordemos que svn tiene varios métodos de acceso +(local, ssh, protocolo propio, protocolo sobre webdav).
+Vamos a usar un repositorio real, chico y con pocos cambios.
+ +

+# svn co svn+ssh://luca@svn.llucax.hn.org/var/lib/svn/test wc_test
+Password:
+A  wc_test/link
+A  wc_test/mkfilter
+Revisión obtenida: 1
+# cd wc_test
+#
+Vemos que se bajo el repo
+# ls -l
+total 4
+lrwxrwxrwx  1 guestlabi guestlabi   8 2005-05-18 15:55 link -> mkfilter
+-rwxr-xr-x  1 guestlabi guestlabi 427 2005-05-18 15:55 mkfilter
+#
+
+ +Para obtener la última versión... + +
+# svn update
+No hay nada nuevo
+En la revisión 1.
+#
+
+ +Un rato más tarde, luego de que alguien modificó un archivo: + +
+# svn update
+Obtenemos los últimos chagesets.
+M  arroz-solo
+Actualizado a la revisión 4.
+#
+
+ +Ahora hacemos unos cambios, pero alguien más estuvo haciendo cambios y los +aplicó antes que nosotros. No importa, subversion, mientras pueda, hará un +merge. + +
+# svn ci -m Cambios.
+Como cambió el mismo archivo que nosotros, antes debemos hacer un
+update para que pueda hacer un merge de los cambios en el servidor a los
+nuestros).
+Enviando       wc/trunk/arroz-solo
+svn: Falló el commit (detalles a continuación):
+svn: Out of date: '/trunk/arroz-solo' in transaction '6'
+# svn update
+Hace el merge sin problemas (notar la G).
+G  arroz-solo
+Actualizado a la revisión 5.
+#
+
+ +Finalmente, nuestro grupo humano no es perfecto, hubo falta de comunicación y 2 +personas corregimos el mismo error (o un error en la misma línea, por ejemplo). +Subversion no puede hacer cargo de la situación y nos dice que hay conflicto. + +
+# svn up
+No puede hacer el merge, PROBLEMAS (notar la C).
+C  wc/trunk/arroz-solo
+Actualizado a la revisión 6.
+#
+Subversion nos deja varios elementos para solucionar el problema:
+# ls
+ls -l
+total 16
+-rw-rw----  1 luca luca 471 2005-05-19 18:02 arroz-solo
+El archivo con marcas de los conflictos (ya lo veremos en más detalle)
+-rw-rw----  1 luca luca 369 2005-05-19 18:02 arroz-solo.mine
+Mi versión del archivo.
+-rw-rw----  1 luca luca 362 2005-05-19 18:02 arroz-solo.r5
+La versión base de archivo, de donde surgió mi version y la nueva
+con la que tiene el conflicto.
+-rw-rw----  1 luca luca 362 2005-05-19 18:02 arroz-solo.r6
+La versión nueva del archivo que provoca el conflicto con mis
+cambios.
+# cat arroz-solo
+
+poner agua a hervir con sal (ponerle bastante sal)
+
+cuando hierva agregar el arroz y bajar un poco el fuego
+
+Hasta el "=======" es como está en mi versión.
+<<<<<<< .mine
+cuando este, sacalo colandolo bajo agua fria para cortar la cocción
+=======
+Hasta el ">>>>>>> .r6" es como está en la nueva versión.
+cuando este, sacalo colandolo bajo agua fría para cortar la coccion
+>>>>>>> .r6
+
+ponerle aceite, puede ser de oliva; poner tambien un chorrin en la fuente
+antes, abajo del arroz
+
+cuatro tazas de agua x una de arroz
+una taza de arroz por persona (salen 2 platos)
+
+Listo!
+
+Si me olvido que hubo un conflicto y quiero hacer un commit, el
+svn no me deja.
+# svn ci
+svn: Falló el commit (detalles a continuación):
+svn: Abortando el commit: '/mnt/burns/luca/documentos/charla_scm/ejemplos/svn/wc/trunk/arroz-solo' queda en conflicto
+#
+Editamos el archivo para eliminar el conflicto.
+# vi arroz-solo
+[...]
+# svn diff
+# svn diff
+Index: arroz-solo
+===================================================================
+colordiff 1.0.4 (http://colordiff.sourceforge.net/)
+(C)2002-2004 Dave Ewart, davee@sungate.co.uk
+
+--- arroz-solo  (revisión: 6)
++++ arroz-solo  (copia de trabajo)
+@@ -3,7 +3,7 @@
+
+ cuando hierva agregar el arroz y bajar un poco el fuego
+
+ -cuando este, sacalo colandolo bajo agua fría para cortar la coccion
+ +cuando este, sacalo colandolo bajo agua fría para cortar la cocción
+
+  ponerle aceite, puede ser de oliva; poner tambien un chorrin en la fuente
+  antes, abajo del arroz
+#
+Finalmente avisamos al svn que resolvimos el conflicto (es
+análogo a borrar todos los archivos que creó para resolverlo)
+# svn resolved arroz-solo
+Se resolvió el conflicto de 'arroz-solo'
+# ls
+arroz-solo
+Y hacemos el commit.
+# svn ci -m "Corregido tilde"
+Enviando       trunk/arroz-solo
+Transmitiendo contenido de archivos .
+Commit de la revisión 7.
+#
+
+ +Listo, esta es uno de los problemas más complejos que se pueden presentar usando +subversion, sin incluir los merges entre 2 branches, pero no tienen más magia +que esto: si funciona bien, todos felices, si no, a resolver conflictos! + + + + diff --git a/charla_scm/presentacion/common.mgp b/charla_scm/presentacion/common.mgp new file mode 100644 index 0000000..2ab81d6 --- /dev/null +++ b/charla_scm/presentacion/common.mgp @@ -0,0 +1,25 @@ +%% +%% Seteos comunes basados en el default +%% +%%deffont "standard" xfont "serif" "iso10646" +%%deffont "thick" xfont "sans-serif" "iso10646" +%%deffont "typewriter" xfont "monospace" "iso10646" +%%deffont "standard" xfont "Vera.ttf" +%%deffont "thick" xfont "VeraBd.ttf" +%%deffont "typewriter" xfont "VeraMono.ttf" +%deffont "standard" xfont "Bitstream Vera" +%deffont "thick" xfont "Bitstream Vera:Bold" +%deffont "typewriter" xfont "Bitstream Vera Mono" +%% +%default 1 area 90 90, leftfill, size 1, fore "black", back "white", font "thick" +%default 2 size 7, vgap 10, prefix " " +%default 3 size 2, bar "gray70", vgap 10 +%default 4 size 4, vgap 30, prefix " ", font "standard" +%% +%tab 1 size 4, vgap 40, prefix " ", icon box "black" 50 +%tab 2 size 3, vgap 40, prefix " ", icon arc "black" 50 +%tab 3 size 2, vgap 40, prefix " ", icon delta3 "black" 40 +%% +%% Que cachee la pagina que sigue, sin efectos +%default 1 pcache 1 1 0 1 +%% diff --git a/charla_scm/presentacion/finale.mgp b/charla_scm/presentacion/finale.mgp new file mode 100644 index 0000000..28df945 --- /dev/null +++ b/charla_scm/presentacion/finale.mgp @@ -0,0 +1,29 @@ +%include "common.mgp" +%% +%page + +Links + + Darcs: http://www.darcs.net/ + Subversion: http://subversion.tigris.org/ + LUFGI: http://www.lug.fi.uba.ar/ + + +%page + +Agradecimientos + + LABI + Bedelia + Papi y mami los quiero no cambien nunca + + +%page +%center + +FIN + + +Nada de preguntas! + + diff --git a/charla_scm/presentacion/presentacion.mgp b/charla_scm/presentacion/presentacion.mgp new file mode 100644 index 0000000..e116080 --- /dev/null +++ b/charla_scm/presentacion/presentacion.mgp @@ -0,0 +1,192 @@ +%include "common.mgp" +%% +%page +%nodefault +%center, size 7, font "standard", back "white", fore "black" + +SCMs: Mitos y verdades +%size 4 + +Todo lo que siempre quiso saber sobre SCMs +y nunca se animó a preguntar + +%bar "gray" 5 10 80 + +Leandro Lucarella (luca@llucax.hn.org) +Alberto Bertogli (albertogli@telpin.com.ar) + +LUGFI + +18 de Mayo de 2005 + + +%page + +Introducción + + Devuelvanme los colores! Viva Rainbow Brite! + Motivación (estamos motivaaaaaaadooosssss!) + Subjetividad (acaso existe una opinión distinta a la nuestra?) + +%page + +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 + + +%page + +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 + + +%page + +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 +%pause + + Dejemos de mentir un poco y veamos la realidad + + +%page + +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 + + +%page + +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 + + +%page + +Manipulando repositorios + + Branches + Aplicación de changesets en distintos branches + Merges: integración de cambios + Conflictos + + +%page + +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 + + +%page + +Dos formas de ver a los SCMs + + Formas de encarar el problema en la práctica + Distribuidos + Centralizados +%pause + + Una viñetita nada más? Qué vergüenza!!! + + +%page + +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 + + +%page + +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) + + +%page + +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 + + +%page + +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 + + +%page + +Ejemplos! + + Para los que todavía estén despiertos... +