--- /dev/null
+
+ 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.
+
+
--- /dev/null
+<html>
+<head>
+<title>darcs :: Ejemplo 1</title>
+<link rel="stylesheet" type="text/css" href="../style.css">
+</head>
+<body>
+
+<h2>Ejemplo 1 - En la cueva</h2>
+
+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.<p>
+
+Antes que nada, creamos el repositorio<br>
+
+<pre>
+<tt class=nota>Creamos el directorio del repo</tt>
+# mkdir recetas
+# cd recetas
+
+<tt class=nota>Creamos el repo con darcs</tt>
+# darcs init
+
+<tt class=nota>Vemos que se crea el directorio especial</tt>
+# ls -l
+total 8
+drwxr-xr-x 6 root root 4096 May 17 22:43 _darcs
+#
+</pre>
+
+Ahora agregamos el primer archivo<br>
+
+<pre>
+<tt class=nota>Creamos un archivo nuevo editandolo</tt>
+# vi arroz
+#
+<tt class=nota>Lo incorporamos al repositorio</tt>
+# darcs add arroz
+#
+</pre>
+<p>
+
+Y hacemos un record para grabar el cambio en el repositorio:
+
+<pre>
+# darcs record
+<tt class=nota>Solo la primera vez nos pregunta nombre y email</tt>
+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>
+
+<tt class=nota>Nos pregunta cambio por cambio que queremos hacer</tt>
+<tt class=nota>El primero es la incorporacion del archivo</tt>
+addfile ./arroz
+Shall I record this patch? (1/2) [ynWsfqadjk], or ? for help: y
+
+<tt class=nota>Y el segundo el contenido del mismo</tt>
+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
+<tt class=nota>Ahora nos pide un nombre corto para el patch</tt>
+What is the patch name? Agregamos una receta para el arroz
+<tt class=nota>Y, opcionalmente, podemos poner una descripcion larga</tt>
+Do you want to add a long comment? [yn] n
+Finished recording patch 'Agregamos una receta para el arroz'
+</pre>
+
+Vemos el historial de cambios<br>
+
+<pre>
+# darcs changes
+Tue May 17 22:45:00 ART 2005 Alberto Bertogli <albertogli@telpin.com.ar>
+ * Agregamos una receta para el arroz
+#
+</pre>
+
+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.<br>
+
+<pre>
+<tt class=nota>Editamos un poco</tt>
+# vi arroz
+#
+<tt class=nota>Vemos los cambios</tt>
+# 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)
+
+#
+<tt class=nota>Nos parecio bien lo que ibamos a cambiar, asi que hacemos el
+record</tt>
+# 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
+<tt class=nota>Aca abre el editor de texto y escribimos una descripcion un
+poco mas larga</tt>
+Finished recording patch 'Unos pequeños cambios.'
+#
+</pre>
+
+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.<br>
+Vamos a mostrar ahora la salida un poco resumida, para no cargar de cosas que
+ya vimos y no son relevantes.<br>
+
+<pre>
+<tt class=nota>Primero editamos</tt>
+# vi arroz
+# darcs diff -u
+[...]
+#
+<tt class=nota>Aca llamamos a nuestra mama, y se horroriza. Volvemos todo para
+atras, hasta el ultimo record que hicimos</tt>
+# darcs revert
+<tt class=nota>(nos muestra los cambios uno por uno, como cuando hacemos un
+record, y elegimos que volvemos atras y que no)</tt>
+[...]
+Shall I revert this patch? (1/1) [ynWsfqadjk], or ? for help: y
+Do you really want to do this? y
+Finished reverting.
+#
+</pre>
+
+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.
+
+<pre>
+# 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
+#
+</pre>
+
+Bueno, ya vimos bastante acerca de como trabajar solos, salgamos un poco al
+mundo y veamos que hay ahi afuera.<p>
+
+</body>
+</html>
+
--- /dev/null
+<html>
+<head>
+<title>darcs :: Ejemplo 2</title>
+<link rel="stylesheet" type="text/css" href="../style.css">
+</head>
+<body>
+
+<h2>Ejemplo 1 - Vemos la luz</h2>
+
+Ahora que ya sabemos operar con las cosas mas comunes, vamos a ver como
+interactuamos con otros repositorios, sean o no nuestros.<p>
+
+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.<br>
+Vamos a usar un repositorio real, chico y con pocos cambios.<br>
+
+<pre>
+# darcs get http://auriga.wearlab.de/~alb/repos/libfilo
+Copying patch 23 of 23... done!
+Applying patches to the "working" directory...
+..............................................
+Finished getting.
+#
+<tt class=nota>Vemos que se bajo el repo</tt>
+# 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
+#
+<tt class=nota>Revisamos los ultimos 5 cambios, de chusmas nomas</tt>
+# 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.
+#
+</pre>
+
+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".<p>
+
+Un rato despues queremos actualizar nuestro repositorio, bajandonos cualquier
+cambio que este en el remoto que nosotros no tengamos.<br>
+
+<pre>
+<tt class=nota>Le pasamos como primer parametro el repositorio del cual
+queremos ver los cambios, y si lo omitimos usa el ultimo que usamos.</tt>
+# darcs pull
+Pulling from "http://auriga.wearlab.de/~alb/repos/libfilo"...
+No remote changes to pull in!
+#
+<tt class=nota>No habia nada que traer! Pero mas tarde, volvemos a probar</tt>
+# 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.
+#
+</pre>
+
+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.<br>
+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.<br>
+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.<br>
+
+<pre>
+<tt class=nota>Alternativa 1: darcs manda el mail</tt>
+# 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>.
+#
+<tt class=nota>Aca, el mail se le envio a Arcadio con esos cambios</tt>
+</pre>
+
+<pre>
+<tt class=nota>Alternativa 2: darcs nos deja un archivo para enviar adjunto</tt>
+# 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
+#
+<tt class=nota>Aca nos dejo el archivo "/tmp/enviar" con los cambios
+seleccionados</tt>
+</pre>
+
+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.<br>
+
+<pre>
+# darcs apply /tmp/para_aplicar
+Finished applying...
+#
+<tt class=nota>Termino de aplicar, miramos el changelog de curiosos nomas</tt>
+# 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.
+#
+</pre>
+
+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.<p>
+
+</body>
+</html>
+
--- /dev/null
+<html>
+<head>
+<title>darcs :: Ejemplo 3</title>
+<link rel="stylesheet" type="text/css" href="../style.css">
+</head>
+<body>
+
+<h2>Ejemplo 3 - Chocamos</h2>
+
+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.<br>
+Veamos como generar uno simple, y como corregirlo.<p>
+
+Vamos a arrancar con un repositorio base del cual hacemos get para obtener dos
+repositorios independientes, en los cuales realizamos cambios de forma
+aislada.<br>
+
+<pre>
+<tt class=nota>Partimos de una base comun; mostramos los cambios</tt>
+# cd base
+# darcs chan
+Wed May 18 02:57:06 ART 2005 Base <base@ej.com.ar>
+ * Agregamos el archivo inicial.
+<tt class=nota>Mostramos un poco del archivo "cancion"</tt>
+# 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 ..
+#
+<tt class=nota>Hacemos un get de base, creando un nuevo repo A</tt>
+# darcs get base A
+Copying patch 1 of 1... done!
+Finished getting.
+#
+<tt class=nota>Y ahora creamos B</tt>
+# darcs get base B
+Copying patch 1 of 1... done!
+Finished getting.
+#
+</pre>
+
+<pre>
+<tt class=nota>Tenemos tres repos iguales, vamos a hacer un cambio en A y a
+arreglar un poco el archivo de arriba.</tt>
+# cd A
+# vi cancion
+<tt class=nota>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</tt>
+# 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 ..
+#
+<tt class=nota>Vamos ahora a hacer un cambio en B.</tt>
+# cd B
+# vi cancion
+<tt class=nota>Como antes, arreglamos "cancion", cambiando 'k's por 'e's</tt>
+# 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 ..
+#
+</pre>
+
+Miremos un poco como estan los archivos hasta ahora.<br>
+
+<pre>
+<tt class=nota>El archivo base</tt>
+# 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.
+[...]
+#
+<tt class=nota>El archivo del repositorio A</tt>
+# 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.
+[...]
+#
+<tt class=nota>El archivo del repositorio B</tt>
+# 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.
+[...]
+#
+</pre>
+
+Vamos a tratar de incorporar los cambios de B en A.
+
+<pre>
+# 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.
+#
+</pre>
+
+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.<p>
+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.<br>
+
+<pre>
+# 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.
+[...]
+#
+<tt class=nota>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.</tt>
+# 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.
+[...]
+#
+<tt class=nota>Entonces hacemos un record, para grabar este patch
+"conciliador"</tt>
+# darcs record
+[...]
+#
+<tt class=nota>Vemos todo el historial de cambios</tt>
+# 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.
+#
+</pre>
+
+</body>
+</html>
+
--- /dev/null
+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.
+
--- /dev/null
+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.
+
--- /dev/null
+--- 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ó,
--- /dev/null
+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.
+
--- /dev/null
+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...
+
--- /dev/null
+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.
+
--- /dev/null
+--- 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.
--- /dev/null
+--- 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...
+
--- /dev/null
+--- 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...
+
--- /dev/null
+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...
+
--- /dev/null
+
+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;
+}
+
+
--- /dev/null
+<html>
+<head>
+<title>darcs :: Ejemplo 1</title>
+<link rel="stylesheet" type="text/css" href="../style.css">
+</head>
+<body>
+
+<h2>Ejemplo 1 - En la cueva</h2>
+
+Yadda, yadda, yadda (mismo ejemplo 1 que en darcs)
+
+<pre>
+<tt class=nota>Creamos el repo</tt>
+# svnadmin create repo
+# cd repo
+
+<tt class=nota>Vemos que se crea el directorio especial</tt>
+# 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
+#
+</pre>
+
+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.
+
+<pre>
+<tt class=nota>Obtenemos un WC</tt>
+# svn co file://$PWD/repo wc
+#
+</pre>
+
+Ahora creamos la estructura básica para branches (en este caso es un poco
+overkill, pero lo hacemos a modo demostrativo).
+
+<pre>
+<tt class=nota>Obtenemos un WC</tt>
+# cd wc
+# svn mkdir trunk
+A trunk
+# svn mkdir branches
+A branches
+# svn mkdir tags
+A tags
+#
+<tt class=nota>Hacemos un commit para poner registrar la estructura</tt>
+# svn ci -m 'Estructura general del repositorio.'
+Añadiendo branches
+Añadiendo tags
+Añadiendo trunk
+#
+</pre>
+
+Ahora agregamos el primer archivo<br>
+
+<pre>
+<tt class=nota>Creamos un archivo nuevo editandolo</tt>
+# cd trunk
+# vi arroz
+#
+<tt class=nota>Lo incorporamos al repositorio</tt>
+# svn add arroz
+A arroz
+#
+<tt class=nota>Vemos el estado del repositorio</tt>
+# svn st
+A arroz
+#
+</pre>
+<p>
+
+Y volvemos a hacer un commit para grabar el cambio en el repositorio:
+
+<pre>
+# svn ci -m 'Nueva receta para hacer arroz.'
+Añadiendo trunk/arroz
+Transmitiendo contenido de archivos .
+Commit de la revisión 2.
+#
+</pre>
+
+Vemos el historial de cambios<br>
+
+<pre>
+# svn log arroz
+<tt class=nota>Muestra sólo las revisiones en dónde cambió este archivo</tt>
+------------------------------------------------------------------------
+r2 | guestlabi | 2005-05-18 15:31:13 -0300 (mié, 18 may 2005) | 1 line
+
+Nueva receta para hacer arroz.
+------------------------------------------------------------------------
+#
+</pre>
+
+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.<br>
+
+<pre>
+<tt class=nota>Editamos un poco</tt>
+# vi arroz
+<tt class=nota>Vemos qué cambió</tt>
+# svn st
+M arroz
+#
+<tt class=nota>Vemos los cambios</tt>
+# 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)
+
+#
+<tt class=nota>Nos parecio bien lo que ibamos a cambiar, asi que hacemos el ci</tt>
+# svn ci -m 'Unos pequeños cambios.'
+Enviando trunk/arroz
+Transmitiendo contenido de archivos .
+Commit de la revisión 3.
+#
+</pre>
+
+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.<br>
+Vamos a mostrar ahora la salida un poco resumida, para no cargar de cosas que
+ya vimos y no son relevantes.<br>
+
+<pre>
+<tt class=nota>Primero editamos</tt>
+# vi arroz
+# svn diff
+[...]
+#
+<tt class=nota>Aca llamamos a la mamá de Alberto, y se horroriza. Volvemos todo para
+atrás, hasta el último commit que hicimos</tt>
+# svn revert arroz
+<tt class=nota>(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)</tt>
+Se revirtió 'arroz'
+#
+</pre>
+
+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.
+
+<pre>
+# svn mv arroz arroz-solo
+<tt class=nota>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
+#
+</pre>
+
+Bueno, ya vimos bastante acerca de como trabajar solos, salgamos un poco al
+mundo y veamos que hay ahi afuera.<p>
+
+</body>
+</html>
+
--- /dev/null
+<html>
+<head>
+<title>darcs :: Ejemplo 2</title>
+<link rel="stylesheet" type="text/css" href="../style.css">
+</head>
+<body>
+
+<h2>Ejemplo 1 - Vemos la luz</h2>
+
+Ahora que ya sabemos operar con las cosas mas comunes, vamos a ver como
+interactuamos con otros repositorios, sean o no nuestros.<p>
+
+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).<br>
+Vamos a usar un repositorio real, chico y con pocos cambios.<br>
+
+<pre>
+# 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
+#
+<tt class=nota>Vemos que se bajo el repo</tt>
+# 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
+#
+</pre>
+
+Para obtener la última versión...
+
+<pre>
+# svn update
+<tt class=nota>No hay nada nuevo</tt>
+En la revisión 1.
+#
+</pre>
+
+Un rato más tarde, luego de que alguien modificó un archivo:
+
+<pre>
+# svn update
+<tt class=nota>Obtenemos los últimos chagesets.</tt>
+M arroz-solo
+Actualizado a la revisión 4.
+#
+</pre>
+
+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.
+
+<pre>
+# svn ci -m Cambios.
+<tt class=nota>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).</tt>
+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
+<tt class=nota>Hace el merge sin problemas (notar la G).</tt>
+G arroz-solo
+Actualizado a la revisión 5.
+#
+</pre>
+
+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.
+
+<pre>
+# svn up
+<tt class=nota>No puede hacer el merge, <strong>PROBLEMAS</strong> (notar la C).</tt>
+C wc/trunk/arroz-solo
+Actualizado a la revisión 6.
+#
+<tt class=nota>Subversion nos deja varios elementos para solucionar el problema:</tt>
+# ls
+ls -l
+total 16
+-rw-rw---- 1 luca luca 471 2005-05-19 18:02 arroz-solo
+<tt class=nota>El archivo con marcas de los conflictos (ya lo veremos en más detalle)</tt>
+-rw-rw---- 1 luca luca 369 2005-05-19 18:02 arroz-solo.mine
+<tt class=nota>Mi versión del archivo.</tt>
+-rw-rw---- 1 luca luca 362 2005-05-19 18:02 arroz-solo.r5
+<tt class=nota>La versión base de archivo, de donde surgió mi version y la nueva
+con la que tiene el conflicto.</tt>
+-rw-rw---- 1 luca luca 362 2005-05-19 18:02 arroz-solo.r6
+<tt class=nota>La versión nueva del archivo que provoca el conflicto con mis
+cambios.<tt>
+# cat arroz-solo
+
+poner agua a hervir con sal (ponerle bastante sal)
+
+cuando hierva agregar el arroz y bajar un poco el fuego
+
+<tt class=nota>Hasta el "=======" es como está en mi versión.</tt>
+<<<<<<< .mine
+cuando este, sacalo colandolo bajo agua fria para cortar la cocción
+=======
+<tt class=nota>Hasta el ">>>>>>> .r6" es como está en la nueva versión.<tt>
+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!
+
+<tt class=nota>Si me olvido que hubo un conflicto y quiero hacer un commit, el
+svn no me deja.</tt>
+# 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
+#
+<tt class=nota>Editamos el archivo para eliminar el conflicto.</tt>
+# 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
+#
+<tt class=nota>Finalmente avisamos al svn que resolvimos el conflicto (es
+análogo a borrar todos los archivos que creó para resolverlo)</tt>
+# svn resolved arroz-solo
+Se resolvió el conflicto de 'arroz-solo'
+# ls
+arroz-solo
+<tt class=nota>Y hacemos el commit.</tt>
+# svn ci -m "Corregido tilde"
+Enviando trunk/arroz-solo
+Transmitiendo contenido de archivos .
+Commit de la revisión 7.
+#
+</pre>
+
+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!
+
+</body>
+</html>
+
--- /dev/null
+%%
+%% 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
+%%
--- /dev/null
+%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!
+
+
--- /dev/null
+%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??? <<huida despavorida>>)
+ 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...
+
projects / personal / documentos.git / commitdiff