igor@403: \chapter{Introducción}
igor@402: \label{chap:intro}
igor@402: 
igor@403: \section{Acerca del control de revisiones}
igor@403: 
igor@403: El control de revisiones es el proceso de administrar diferentes
igor@403: versiones de una pieza de información. En su forma más simple es algo
igor@403: que la mayoría de gente hace a mano: cada vez que usted modifica un
igor@403: fichero, lo graba con un nuevo nombre que contiene un número, el
igor@403: siguiente mayor que el anterior.
igor@403: 
igor@403: Administrar manualmente muchas versiones de un fichero es una tarea
igor@403: propensa a errores, a pesar de que hace bastante tiempo hay
igor@403: herramientas que ayudan en este proceso.  Las primeras herramientas
igor@403: para automatizar el control de revisiones fueron pensadas para que un
igor@403: usuario administrara un solo fichero.  En las décadas pasadas, el
igor@403: alcance de las herramientas de control de revisiones ha ido aumentando
igor@408: considerablemente; ahora manejan muchos ficheros y facilitan el
igor@403: trabajo en conjunto de varias personas. Las mejores herramientas de
igor@403: control de revisiones de la actualidad no tienen problema con miles de
igor@403: personas trabajando en proyectos que consisten de decenas de miles de
igor@403: ficheros.
igor@403: 
igor@403: \subsection{¿Por qué usar control de revisiones?}
igor@403: 
igor@403: Hay muchas razones por las cuales usted o su equipo desearía usar una
igor@403: herramienta automática de control de revisiones para un proyecto.
igor@402: \begin{itemize}
igor@403: \item Contar con la historia y la evolución de su proyecto, para
igor@403:   evitar hacer la tarea manualmente. Por cada cambio tendrá una
igor@403:   bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
igor@403:   \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
igor@403: \item Cuando trabaja con más personas, los programas de control de
igor@403:   revisiones facilitan la colaboración.  Por ejemplo, cuando varias
igor@403:   personas de forma casi simultanea pueden hacer cambios
igor@403:   incompatibles, el programa le ayudará a identificar y resolver tales
igor@403:   conflictos.
igor@403: \item Puede ayudarle a recuperarse de equivocaciones. Si aplica un
igor@403:   cambio que posteriormente se evidencia como un error, puede
igor@403:   revertirlo a una versión previa a uno o muchos ficheros. De hecho,
igor@403:   una herramienta \emph{realmente} buena, incluso puede ayudarle
igor@403:   efectivamente a darse cuenta exactamente cuándo se introdujo el
igor@403:   error( para más detalles ver la sección~\ref{sec:undo:bisect}).
igor@403: \item Le permitirá trabajar simultáneamente, y manejar las diferencias
igor@403:   entre múltiples versiones de su proyecto.
igor@402: \end{itemize}
igor@403: La mayoría de estas razones son igualmente validas ---por lo menos en
igor@403: teoría--- así esté trabajando en un proyecto solo, o con mucha gente.
igor@403: 
igor@403: Algo fundamental acerca de lo práctico de un sistema de control de
igor@403: revisiones en estas dos escalas (``un hacker solo'' y ``un equipo
igor@403: gigantesco'') es cómo se comparan los \emph{beneficios} con los
igor@403: \emph{costos}.  Una herramienta de control de revisiones que sea
igor@403: difícil de entender o usar impondrá un costo alto.
igor@403: 
igor@403: Un proyecto de quinientas personas es muy propenso a colapsar
igor@403: solamente con su peso inmediatamente sin una herramienta de control de
igor@403: versiones y un proceso. En este caso, el costo de usar control de
igor@403: revisiones ni siquiera se tiene en cueant, puesto que \emph{sin} él,
igor@403: el fracaso está casi garantizado.
igor@403: 
igor@403: Por otra parte, un ``arreglo rápido'' de una sola persona, excluiría
igor@403: la necesidad de usar una herramienta de control de revisiones, porque
igor@403: casi seguramente, el costo de usar una estaría cerca del costo del
igor@403: proyecto. ¿No es así?
igor@403: 
igor@403: Mercurial solamente soporta \emph{ambas} escalas de de
igor@403: desarrollo. Puede aprender lo básico en pocos minutos, y dado su bajo
igor@403: sobrecosto, puede aplicar el control de revisiones al proyecto más
igor@403: pequeño con facilidad. Su simplicidad significa que no tendrá que
igor@403: preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
igor@403: por espacio mental con lo que sea que \emph{realmente} esté tratando
igor@403: de hacer.  Al mismo tiempo, Mercurial tiene alto desempeño y su
igor@403: naturaleza peer-to-peer le permite escalar indoloramente para manejar
igor@403: grandes proyectos.
igor@403: 
igor@403: Ninguna herramienta de control de revisiones puede salvar un
igor@403: proyecto mal administrado, pero la elección de herramientas puede
igor@403: hacer una gran diferencia en la fluidez con la cual puede trabajar en
igor@403: el proyecto.
igor@403: 
igor@403: \subsection{La cantidad de nombres del control de revisiones}
igor@403: 
igor@403: El control de revisiones es un campo amplio, tan ampli que no hay un
igor@403: acrónimo o nombre único. A continuación presentamos un listado de
igor@403: nombres comunes y acrónimos que se podrían encontrar:
igor@402: \begin{itemize}
igor@403: \item Control de revisiones (RCS)
igor@403: \item Manejo de Configuraciones de Programas(SCM), o administracón de
igor@403:   configuraciones
igor@403: \item Administración de código fuente
igor@403: \item Control de Código Fuente, o Control de Fuentes
igor@403: \item Control de Versiones(VCS)
igor@402: \end{itemize}
igor@403: Algunas personas aducen que estos términos tienen significados
igor@403: diversos, pero en la práctica se sobrelapan tanto que no hay un
igor@403: acuerdo o una forma adecuada de separarlos.
igor@403: 
igor@403: \section{Historia resumida del control de revisiones}
igor@403: 
igor@403: La herramienta de control de revisiones más antigua conocida es SCCS 
igor@403: (Sistema de Control de Código), escrito por Marc Rochkind en Bell
igor@408: Labs, a comienzos de los setentas(1970s).  SCCS operaba sobre ficheros
igor@403: individuales, y requería que cada persona que trabajara en el proyecto
igor@403: tuviera acceso a un espacio compartido en un solo sistema.  Solamente
igor@408: una persona podía modificar un fichero en un momento dado; el
igor@403: arbitramiento del acceso a los ficheros se hacía con candados. Era
igor@403: común que la gente pusiera los candados a los ficheros, y que
igor@403: posteriormente olvidara quitarlos, impidiendo que otro pudiera
igor@403: modificar los ficheros en cuestión sin la intervención del
igor@403: administrador.
igor@403: 
igor@403: Walter Tichy desarrolló una alternativa gratutita a SCCS a comienzos
igor@403: de los ochentas(1980s), llamó a su programa RCS(Sistema de Control de
igor@403: Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
igor@403: trabajaran en un único espacio compartido y colocaran candados a los
igor@403: ficheros para evitar que varias personas los estuvieran modificando
igor@403: simultáneamente.
igor@403: 
igor@403: Después en los ochenta, Dick Grune usó RCS como un bloque de
igor@403: construcción para un conjunto de guiones de línea de comando, que
igor@403: inicialmente llamó cmt, pero que renombró a CVS(Sistema Concurrente de
igor@403: Versiones).  La gran innovación de CVS era que permitía a los
igor@403: desarrolladores trabajar simultáneamente de una forma más o menos
igor@403: independiente en sus propios espacios de trabajo. Los espacios de
igor@403: trabajo personales impedian que los desarrolladores se pisaran las
igor@403: mangueras todo el tiempo, situación común con SCCS y RCS.  Cada
igor@403: desarrollador tenía una copia de todo el fichero del proyecto y podía
igor@403: modificar su copia independientemente, Tenían que fusionar sus
igor@403: ediciones antes de consignar los cambios al repositorio central.
igor@403: 
igor@403: Brian Berliner tomó los scripts originales de Grune y los reescribió
igor@403: en~C, haciéndolos públicos en 1989, código sobre el cual se ha
igor@403: desarrollado la versión moderna de CVS.  CVS posteriormente adquirió
igor@403: la habilidad de operar sobre una conexión de red, dotándolo de una
igor@403: arquitectura, cliente/servidor. La arquitectura de CVS es
igor@403: centralizada; La historia del proyecto está únicamente en el
igor@403: repositorio central.  Los espacios de trabajo de los clientes
igor@403: contienen únicamente copias recientes de las versiones de los
igor@403: ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
igor@403: ha tenido un éxito enorme; Es probablemente el sistema de control de
igor@403: revisiones más extendido del planeta.
igor@402: 
igor@404: A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
igor@404: temprano sistema distribuido de revisión de controles llamado TeamWare
igor@404: Un espacio de trabajo TeamWare contiene una copia completa de la
igor@404: historia del proyecto. TeamWare no tiene la noción de repositorio
igor@404: central. (CVS se basaba en RCS para el almacenamiento de su historia;
igor@404: TeamWare usaba SCCS.)
igor@404: 
igor@404: A medida que avanzaba la decada de los noventa, se empezño a
igor@404: evidenciar los problemas de CVS.  Alacena cambios simultáneos a muchos
igor@408: ficheros de forma individual, en lugar de agruparlos como una
igor@404: operación única y atómica lógicamente.  No maneja bien su jerarquía de
igor@404: ficheros bien; es fácil desordenar un repositorio renombrando ficheros
igor@404: y directorios. Peor aún, su código fuente es difícil de leer y
igor@404: mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
igor@404: problemas arquitecturales algo prohibitivo.
igor@404: 
igor@404: En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
igor@404: trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
igor@404: herramienta con mejor arquitectura y código más limpio.  El resultado,
igor@404: Subversion, no se separó del modelo centralizado cliente/servidor de
igor@404: CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
igor@404: manejo de nombres de espacios, y otras características que lo hacen
igor@404: mejor que CVS. Desde su versión inicial, ha ido creciendo en
igor@404: popularidad.
igor@404: 
igor@404: Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
igor@404: sistema distribuido de control de versiones ambicioso que llamó
igor@404: Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
igor@404: diseño de CVS con una arquitectura peer-to-peer, fue mucho más
igor@404: allá(junto con otros proyectos subsecuentes) que unas herramientas de
igor@404: control de revisiones en varios aspectos innovadores. Usa hashes
igor@404: criptográficos como identificadores, y tiene una noción integral de 
igor@404: ``confianza'' para código de diversas fuentes.
igor@404: 
igor@404: Mercurial nació en el 2005.  Algunos de sus aspectos de de diseño
igor@404: fueron influenciados por Monotone, pero Mercurial se enfoca en la
igor@404: facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
igor@404: grandes.
igor@404: 
igor@404: \section{Tendencias en el control de revisiones}
igor@404: 
igor@404: Ha habido varias tendencias en el desarrollo y uso de las herramientas
igor@404: de control de revisiones en las pasadas cuatro décadas, mientras la
igor@404: gente se ha vuelto familiar con las capacidades de sus herramientas
igor@404: así mismo con sus limitaciones.
igor@404: 
igor@408: La primera generación comenzó administrando ficheros individuales en
igor@404: computadores por persona. A pesar de que tales herramientas
igor@404: representaron un avance importante frente al control de revisiones
igor@404: manual, su modelo de candados y la limitación a un sólo computador,
igor@404: determinó equipos de trabajo pequeños y acoplados.
igor@404: 
igor@404: La segunda generación dejó atrás esas limitaciones moviéndose a
igor@404: arquitecturas centradas en  redes, y administrando proyectos completos
igor@404: uno a la vez. A medida que los proyectos crecían, nacieron nuevos
igor@404: problemas. Con la necesidad de comunicación frecuente con los
igor@404: servidores, escalar estas máquinas se convirtió en un problema en
igor@404: proyectos realmente grandes. Las redes con poca estabilidad impidieron
igor@404: que usuarios remotos se conectaran al servidor. A medida que los
igor@404: proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
igor@404: de forma anónima a cualquiera, la gente sin permiso para consignar,
igor@404: vio que no podían usar tales herramientas para interactuar en un
igor@404: proyecto de forma natural, puesto que no podían guardar sus cambios.
igor@404: 
igor@404: La generación actual de herramientas de control de revisiones es de
igor@404: forma natural peer-to-peer.  Todos estos sistemas han eliminado la
igor@404: dependencia de un único servidor central, y han permitido que la
igor@404: gente distribuya sus datos de control de revisiones donde realmente se
igor@404: necesita. La colaboración a través de Internet ha cambiado las
igor@404: limitantes tecnológicas a la cuestión de elección y consenso. Las
igor@404: herramientas modernas pueden operar sin conexión indefinidamenta y
igor@404: autónomamente, necesitando una conexión de red solamente para
igor@404: sincronizar los cambios con otro repositorio.
igor@404: 
igor@404: \section{Algunas ventajas del control distribuido de revisiones}
igor@404: 
igor@404: A pesar de que las herramientas para el control distribuido de
igor@404: revisiones lleva varios años siendo tan robusto y usable como la
igor@404: generación previa de su contraparte, personas que usan herramientas
igor@404: más antiguas no se han percatado de sus ventajas.  Hay gran cantidad
igor@404: de situaciones en las cuales las herramientas distribuidas brillan
igor@404: frente a las centralizadas.
igor@404: 
igor@404: Para un desarrollador individual, las herramientas distribuidas casi
igor@404: siempre son más rápidas que las centralizadas. Por una razón sencilla:
igor@404: Una herramienta centralizada necesita comunicarse por red para las
igor@404: operaciones más usuales, debido a que los metadatos se almacenan en
igor@404: una sola copia en el servidor central. Una herramienta distribuida
igor@404: almacena todos sus metadatos localmente.  Con todo lo demás de la
igor@404: misma forma, comunicarse por red tiene un sobrecosto en una
igor@404: herramienta centralizada. No subestime el valor de una herramienta de
igor@404: respuesta rápida: Usted empleará mucho tiempo interactuando con su
igor@404: programa de control de revisiones.
igor@404: 
igor@404: Las herramientas distribuidas son indiferentes a los caprichos de su
igor@404: infraestructura de servidores, de nuevo, debido a la replicación de
igor@404: metadatos en tantos lugares. Si usa un sistema centralizado y su
igor@404: servidor explota, ojalá los medios físicos de su copia de seguridad
igor@404: sean confiables, y que su última copia sea reciente y además
igor@404: funcione. Con una herramienta distribuida tiene tantas copias de
igor@404: seguridad disponibles como computadores de contribuidores.
igor@404: 
igor@404: La confiabilidad de su red afectará las herramientas distribuidas de
igor@404: una forma mucho menor que las herramientas centralizadas No puede
igor@404: siquiera usar una herramienta centralizada sin conexión de red,
igor@404: excepto con algunas órdenes muy limitadas. Con herramientas
igor@404: distribuidas, si sus conexión cae mientras usted está trabajando,
igor@404: podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
igor@404: comunicarse  con repositorios en otros computadores, algo que es
igor@404: relativamente raro comparado con las operaciones locales. Si tiene
igor@404: colaboradores remotos en su equipo, puede ser significante.
igor@404: 
igor@404: \subsection{Ventajas para proyectos de código abierto}
igor@404: 
igor@404: Si descubre un proyecto de código abierto y decide que desea comenzar
igor@404: a trabajar en él, y ese proyecto usa una herramienta de control
igor@404: distribuido de revisiones, usted es un par con la gente que se
igor@404: considera el ``alma'' del proyecto.  Si ellos publican los
igor@404: repositorios, se puede copiar inmediatamente la historia del proyecto,
igor@404: hacer cambios y guardar su trabajo, usando las mismas herramientas de
igor@404: la misma forma que ellos. En contraste, con una herramienta
igor@404: centralizada, debe usar el programa en un modo ``sólo lectura'' a
igor@404: menos que alguien le otorgue permisos para consignar cambios en el
igor@404: repositorio central. Hasta entonces, no podrá almacenar sus cambios y
igor@404: sus modificaciones locales correrán el riesgo de dañarse cuando trate
igor@404: de actualizar su vista del repositorio.
igor@404: 
igor@404: \subsubsection{Las bifurcaciones(forks) no son un problema}
igor@404: 
igor@404: Se ha mencionado que las herramientas de control distribuido de
igor@404: versiones albergan un riesgo a los proyectos de código abierto, puesto
jerojasro@405: que se vuelve muy sencillo hacer una ``bifurcanción''\ndt{fork.} del
igor@404: desarrollo del proyecto.  Una bifurcación pasa cuando hay diferencias
igor@404: de opinión o actitud entre grupos de desarrolladores que desenvoca en
igor@404: la decisión de la imposibilidad de continuar trabajando juntos. Cada
igor@404: parte toma una copia más o menos completa del código fuente del
igor@404: proyecto y toma su propio rumbo.
igor@404: 
igor@404: En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
igor@404: diferencias. Con un sistema centralizado de control de revisiones, el
igor@404: proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
igor@404: forma muy manual.  Tiene que decidir qué historia de revisiones va a
igor@404: ``win'', e injertar los cambios del otro equipo en el árbol de alguna
igor@404: manera. Con esto usualmente se pierde algo o todo del historial de la
igor@404: revisión de alguna de las partes.
igor@404: 
igor@404: Lo que las herramientas distribuidas hacen con respecto a las
igor@404: bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
igor@404: desarrollar un proyecto. Cada cambio que usted hace es potencialmente
igor@404: un punto de bifurcación. La gran fortaleza de esta aproximación es que
igor@404: las herramientas distribuidas de control de revisiones tiene que ser
igor@404: bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
igor@404: son absolutamente fundamentales: pasan todo el tiempo.
igor@404: 
igor@404: Si todas las porciones de trabajo que todos hacen todo el tiempo, se
igor@404: enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
igor@404: lo que se refiere en el mundo del código abierto a una ``bifurcación''
igor@404: se convierte \emph{puramente} en una cuestión social. Lo que hacen las
igor@404: herramientas distribuidas es \emph{disminuir} la posibilidad de una
igor@404: bifurcación porque:
igor@402: \begin{itemize}
igor@404: \item Eliminan la distinción social que las herramientas centralizadas
igor@404:   imponen: esto entre los miembros (personas con permiso de consignar)
igor@404:   y forasteros(los que no tienen el permiso).
igor@404: \item Facilitan la reconciliación después de una bifurcación social,
igor@404:   porque todo lo que concierne al programa de control de revisiones es
igor@404:   una fusión.
igor@402: \end{itemize}
igor@402: 
igor@404: Algunas personas se resisten a las herramientas distribuidas porque
igor@404: desean mantener control completo sobre sus proyectos, y creen que las
igor@407: herramientas centralizadas les da tal control. En todo caso, si este
igor@404: es su parecer, y publica sus repositorios de CVS o Subversion, hay
igor@404: muchas herramientas disponibles que pueden obtener la historia
igor@404: completa(A pesar de lo lento) y recrearla en otro sitio que usted no
igor@407: controla. Siendo así un control ilusorio, puesto que está impidiendo
igor@407: la fluidez de colaboración en lugar de prevenir que alguien se sienta
igor@407: impulsado a obtener una copia y hacer una bifurcación con su historia.
igor@407: 
igor@407: \subsection{Ventajas para proyectos comerciales}
igor@407: 
igor@407: Muchos proyectos comerciales tienen grupos de trabajo distribuidos
igor@407: alrededor del globo.  Quienes contribuyen y están lejos de un
igor@407: repositorio central verán una ejecución más lenta de las órdenes y tal
igor@407: vez menos confiabilidad. Los sistemas de control de revisión
igor@407: comerciales intentan amortiguar estos problemas con adiciones de
igor@407: replicación remota que usualmente son muy costosos y complicados de
igor@407: administradr. Un sistema distribuido no padece estos problemas. Mejor
igor@407: aún, puede colocar varios servidores autorizados, por ejemplo, uno por
igor@407: sitio, de tal forma que no haya comunicación redundante entre
igor@407: repositorios sobre enlaces de conexión costosos.
igor@407: 
igor@407: Los sistemas de control de revisiones distribuidos tienden a ser poco
igor@407: escalables. No es inusual quw costosos sistemas centralizados caigan
igor@407: ante la carga combinada de unas cuantas docenas de usuarios
igor@407: concurrentes. De nuevo, las respuestas típicas de replibcación tienden
igor@407: a ser costosas y complejas de instalar y administrar. Dado que la
igor@407: carga en un servidor central---si es que tiene uno---es muchas veces
igor@407: menor con una herramienta distribuida(debido a que los datos están
igor@407: replicados en todas partes), un sólo servidor económico puede tratar
igor@407: las necesidades de equipos mucho más grandes, y la replicación para
igor@407: balancear la carga se vuelve cosa de scripts.
igor@407: 
igor@407: Si tiene un empleado en el campo, se beneficiará grandemente de un
igor@407: sistema distribuido de control de versiones al resolver problemas en
igor@407: el sitio del cliente. La herramienta le permitirá generar
igor@407: construcciones a la medida, probar diferentes arreglos de forma
igor@407: independiente y buscar de forma eficiente las fuentes de fallos en la
igor@407: historia y regresiones en los ambientes de los clientes, todo, sin
igor@407: necesidad de conectarse al servidor de su compañía.
igor@407: 
igor@407: \section{¿Por qué elegir Mercurial?}
igor@407: 
igor@407: Mercurial cuenta con un conjunto único de propiedades que lo hacen
igor@407: particularmente una buena elección como un sistema de control de
igor@407: revisiones, puesto que:
igor@402: \begin{itemize}
igor@407: \item Es fácil de aprender y usar.
igor@407: \item Es liviano.
igor@407: \item Escala de forma excelente.
igor@407: \item Es fácil de acondicionar.
igor@402: \end{itemize}
igor@402: 
igor@407: Si los sistemas de control de revisiones le son familiares, debería
igor@407: estar listo para usar Mercurial en menos de cinco minutos. Si no, va a
igor@407: tomar unos pocos minutos más. Las órdenes de Mercurial y su conjunto
igor@407: de características son uniformes y consistentes generalmente, y basta
igor@407: con que siga unas pocas reglas generales en lugar de un montón de
igor@407: excepciones.
igor@407: 
igor@407: En un proyecto pequeño, puede comenzar a trabajar con Mercurial poco a
igor@407: poco. Creando nuevos cambios y ramas, transfiriendo cambios(localmente
igor@407: o por la red); y las operaciones relacionadas con el estado y la
igor@407: historia son rápidas. Mercurial buscar ser ligero y no incomodar en su
igor@407: camino combinando poca sobrecarga cognitiva con operaciones
igor@407: asombrosamente rápidas.
igor@407: 
igor@407: La utilidad de Mercurial no se limita a proyectos pequeños: está
igor@407: siendo usado por proyectos con centenas de miles de contribuyentes,
igor@407: cada uno conteniendo decenas de miles de ficheros y centenas de
igor@407: megabytes de código fuente
igor@407: 
igor@407: Si la funcionalidad básica de Mercurial no es suficiente para usted,
igor@407: es muy fácil extenderlo. Mercurial se comporta muy bien con tareas de
igor@407: scripting y su limpieza interna junto con su implementación en Python
igor@407: permiten añadir características fácilmente en forma de extensiones.
igor@407: Hay un buen número de extensiones útiles y populares en este momento,
igor@407: desde ayudar a identificar fallos hasta el mejoramiento de su
igor@407: desempeño.
igor@407: 
igor@407: \section{Comparación de Mercurial con otras herramientas}
igor@407: 
igor@407: Antes de leer, por favor tenga en cuenta que esta sección
igor@407: necesariamente refleja mis propias experiencias, intereses y(tengo que
igor@407: decirlo) mis preferencias. He usado cada una de las herramientas de
igor@407: control de versiones listadas a continuación, y en muchos casos por
igor@407: varios años.
igor@402: 
igor@402: 
igor@402: \subsection{Subversion}
igor@402: 
igor@407: Subversion es una herramienta de control de revisiones muy popular,
igor@407: desarrollada para reemplazar a CVS.  Su arquitectura es centralizada
igor@407: en cliente/servidor.
igor@407: 
igor@407: Subversion y Mercurial tienen órdenes con nombres similares para hacer
igor@407: las mismas operaciones, por lo que si le son familiares en una, será
igor@407: sencillo aprender a usar la otra. Ambas herramientas son portables en
igor@407: todos los sistemas operativos populares.
igor@407: 
igor@407: Antes de la versión 1.5, Subversion no tenía soporte para fusiones. En
igor@407: el momento de la escritura, sus capcidades para llevar cuenta de las
igor@407: funciones son nuevas,
igor@407: \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicadas
igor@409:   y poco estables\ndt{buggy}}.
igor@407: 
igor@407: Mercurial tiene una ventaja considerable en el desempeño sobre
igor@407: Subversion en cualquier operación de control de revisiones que yo haya
igor@407: medido. He medido sus ventajas con factores desde dos hasta seis veces
igor@408: comparando con almacenamiento de ficheros \emph{ra\_local}
igor@407: Subversion~1.4.3, el cual es el método de acceso más rápido.  En los
igor@407: escenarios más sencillos incluyendo almacenamiento con la red de por
igor@407: medio, Subversion se encuentra en desventaja aún mayor. Dado que casi
igor@407: todas las órdenes de Subversion deben tratar con el servidor y
igor@407: Subversion no tiene utilidades de replicación sencillas, la capacidad
igor@407: del servidor y el ancho de banda se convierten en cuellos de botella
igor@407: para proyectos modestamente grandes.
igor@407: 
igor@407: Adicionalmente, Subversion tiene un sobrecosto en almacentamiento
igor@407: considerable para evitar transacciones por red en algunas operaciones,
igor@407: tales como encontrar ficheros modificados(\texttt{status}) y desplegar
igor@407: información frente a la revisión actual(\texttt{diff}).  Como
igor@407: resultado, la copia de trabajo de Subversion termina siendo del mismo
igor@407: tamaño o más grande que un repositorio de Mercurial y el directorio de
igor@407: trabajo, a pesar de que el repositorio de Mercurial contiene la
igor@407: historia completa  del proyecto.
igor@407: 
igor@407: Subversion tiene soporte amplio de otras herramientas. Mercurial por
igor@407: ahora está bastante atrás en este aspecto.  Esta diferencia está
igor@409: disminuyendo, y algunas de las herramientas GUI\ndt{Interfaz de
igor@407:   Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual
igor@407: que Mercurial, Subversion tiene un excelente manual de usuario.
igor@402: 
igor@408: Dado que Subversion no almacena la historia de revisiones en el
igor@408: cliente, es muy bueno para administrar proyectos que tienen muchos
igor@408: ficheros binarios grandes y opacos. Si consigna cincuenta revisiones
igor@408: de un fichero de 10MB que no es comprimible, el esapacio en el cliente
igor@408: de Subversion se mantendrá constante mientras que el espacio usado por
igor@408: cualquier Sistema Distribuido de Control de Revisiones crecerá
igor@408: rápidamente en proporción con el número de revisiones, debido a que
igor@408: las diferencias entre cada revisión es grande.
igor@408: 
igor@408: Adicionalmente, generalmente es difícil o más bien, imposible mezclar
igor@408: diferentes versiones de un fichero binario. La habilidad de Subversion
igor@408: para permitirle al usuario poner una cerradura  a un fichero, de modo
igor@408: que tenga un permiso exclusivo para consignar cambios, puede ser una
igor@408: ventaja significativa en un proyecto donde los ficheros binarios sean
igor@408: usados ampliamente.
igor@408: 
igor@408: Mercurial puede importar la historia de revisiones de un repositorio
igor@408: de Subversion. También puede exportar historia de revisiones a un
igor@408: repositorio de Subversion.  De esta forma es sencillo ``dar un
igor@408: vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
igor@408: a dar el paso. La conversión de la historia es incremental, de modo
igor@408: que puede aplicar una conversión inicial, y después conversiones
igor@408: pequeñas y adicionales posteriormente para traer nuevos cambios.
igor@402: 
igor@402: \subsection{Git}
igor@402: 
igor@408: Git es una herramienta distribuida de control de revisiones
igor@408: desarrollada para administrar el arbol del Kernel de Linux.  Al igual
igor@408: que Mercurial los principios de su diseño fueron influenciados por 
igor@408: Monotone.
igor@408: 
igor@408: Git tiene un conjunto de órdenes muy grande en la versión~1.5.0
igor@408: ofrece~139 órdenes individuales.  Tiene cierta reputación de ser
igor@408: difícil de aprender. Comparado con Git, Mercurial tiene un fuerte
igor@408: enfoque hacia la facilidad.
igor@408: 
igor@408: En términos de rendimiento, Git es extremadamente rápido. En muchos
igor@408: casos, es más rápido que Mercurial, por lo menos en Linux, mientras
igor@408: que Mercurial se comporta mejor en otras operaciones.  De todas
igor@408: maneras en Windows, el desempeño y el nivel general de soporte que
igor@408: ofrece Git, al momento de la escritura, está lejos detrás de
igor@408: Mercurial.
igor@408: 
igor@408: Mientras que el repositorio de Mercurial no requiere mantenimiento, el
igor@408: repositorio de Git requiere frecuentes ``repacks'' a sus metadatos.
igor@408: Sin estos, el desempeño se degrada y el espacio crece rápidamente. Un
igor@408: servidor que contenga repositorios de Git que no sean reempacados
igor@408: rigurosa y frecuentemente requerirá trabajo-intenso de disco durante
igor@408: las copias de seguridad, y ha habido situaciones en copias de
igor@408: seguridad diaria que toman más de 24 horas como resultado. Un
igor@408: repositorio recién reempacado de Git es un poco más pequeño que un
igor@408: repositorio de Mercurial, pero un repositorio sin reempacar es varios
igor@408: órdenes de magnitud más grande.
igor@408: 
igor@408: El corazón de Git está escrito en C.  Muchas órdenes de Git están
igor@408: implementadas como scripts de shell o Perl y la calidad de esos
igor@408: scripts varía ampliamente. He encontrado muchas situaciones en las
igor@408: cuales los scripts no tuvieron en cuenta la presencia de errores que
igor@408: podrían haber sido fatales.
igor@408: 
igor@408: Mercurial puede importar el historial de revisiones de un repositorio
igor@408: de Git.
igor@402: 
igor@402: \subsection{CVS}
igor@402: 
igor@408: CVS es probablemente la herramienta de control de revisiones más
igor@408: ampliamente usada en el planeta.  Debido a su edad y su poca pulcritud
igor@408: nterna, ha sido ligeramente mantenido en muchos años.
igor@408: 
igor@408: Tiene una arquitectura centralizada cliente/servidor. No agrupa
igor@408: cambios relacionadso en consignaciones atómicas, pemitiendo que con
igor@408: facilidad la gente ``rompa la construcción'': una persona puede
igor@408: consignar exitósamente parte del cambio y estar bloqueada por la
igor@408: necesidad de una mezcla, forzando a otras personas a ver solamente una
igor@408: porción del trabajo que estaban buscando hacer.  Esto afecta también
igor@408: la forma como usted trabaja con la historia del proyecto. Si quiere
igor@408: ver todas las modificaciones que alguien hizo como parte de una tarea,
igor@408: necesitará inspeccionar manualmente las descripciones y las marcas de
igor@408: tiempo de cambio de cada fichero involucrado(esto, si usted saber
igor@408: cuáles eran tales ficheros).
igor@408: 
igor@408: CVS tiene una noción confusa de etiquetas y ramas que yo no trataría
igor@408: incluso de describir.  No soporta renombramiento de ficheros o
igor@408: directorios de buena forma, facilitando el corromper un
igor@408: repositorio. Casi no tiene chequeo de consistencia interna, por lo
igor@408: tanto es casi imposible identificar por que o cómo se corrompió un
igor@408: repositorio. Yo no recomendaría un repositorio de CVS para proyecto
igor@408: alguno, ni existente ni nuevo.
igor@408: 
igor@408: Mercurial puede importar la historia de revisiones de CVS.  De todas
igor@408: maneras hay ciertos trucos para aplicar; los cuales también son
igor@408: necesarios para cualquier herramienta importadora de historial de
igor@408: CVS. Debido a la falta de atomicidad de cambios y el no versionamiento
igor@408: de la jerarquía del sistema de archivos, es imposible reconstruir la
igor@408: completamente la historia de CVS acertadamente; hay cierto trabajo de
igor@408: conjetura involucrado y los renombramientos tampoco se
igor@408: mostrarán. Debido a que gran parte de la administración avanzada de
igor@408: CVS tiene que hacerse manualmente y por lo tanto es proclive al error,
igor@408: es común que los importadores de CVS encuentren muchos problemas con
igor@408: repositorios corruptos( marcas de tiempo totalmente desubicadas y
igor@408: archivos que han permanecido con candados por más de una década son
igor@408: dos de los problemas más interesantes de los que puedo retomar de mi
igor@408: experiencia personal).
igor@408: 
igor@408: Mercurial puede importar la historia de revisiones de un repositorio
igor@408: CVS.
igor@408: 
igor@408: \subsection{Herramientas comerciales}
igor@408: 
igor@408: Perforce tiene una arquitectura centralizada cliente/servidor sin
igor@408: almacenamiento de dato alguno en el lado del cliente. A diferencia de
igor@408: las herramientas modernas de control de revisiones, Perforce requiere
igor@408: que un usuario ejecute una orden para informar al servidor acerca de
igor@408: todo fichero que se vaya a editar.
igor@408: 
igor@408: El rendimiento de Perforce es muy bueno para equipos pequeños, pero se
igor@408: degrada rápidamente cuando el número de usuarios va más allá de pocas
igor@408: docenas. Instalaciones modestamente grandes de Perforce requiere la
igor@408: organización de proxies para soportar la carga que sus usuarios generan.
igor@408: 
igor@408: \subsection{Elegir una herramienta de control de revisiones}
igor@408: 
igor@408: Con la excepción de CVS, toda las herramientas que se han listado
igor@408: anteriormente tienen fortalezas que los hacen valiosos de acuerdo al
igor@408: tipo de trabajo. No hay una única herramienta de control de revisiones
igor@408: que sea la mejor en todas las situaciones.
igor@408: 
igor@408: Por ejemplo, Subversion es una buena elección para trabajar con
igor@408: edición frecuente de ficheros binarios, debido a su naturaleza
igor@408: centralizada y soporte para poner candados a ficheros.
igor@408: 
igor@408: Personalmente encuentro las propiedades de simplicidad, desempeño, y
igor@408: buen soporte de fusiones de Mercurial una combinación llamativa que ha
igor@408: dado buenos frutos por varios años.
igor@408: 
igor@408: 
igor@408: \section{Migrar de otra herramienta hacia Mercurial}
igor@408: 
igor@408: Mercurial viene con una extensión llamada \hgext{convert}, que puede
igor@408: importar historiales de revisiones de forma incremental desde varias
igor@408: herramientas de control de revisiones. Por ``incremental'', quiero
igor@408: decir que puede migrar toda la historia de un proyecto en una primera
igor@408: instancia y después volver a ejecutar la migración posteriormente para
igor@408: obtener los nuevos cambios que han sucedido después de la migración
igor@408: inicial.
igor@408: 
igor@408: A continuación presentamos las herramientas de revisiones que la
igor@408: orden\hgext{convert} soporta:
igor@402: \begin{itemize}
igor@402: \item Subversion
igor@402: \item CVS
igor@402: \item Git
igor@402: \item Darcs
igor@402: \end{itemize}
igor@402: 
igor@408: Adicionalmente, \hgext{convert} puede exportar cambios de Mercurial
igor@408: hacia Subversion.  Lo que hace posible probar Subversion y Mercurial
igor@408: en paralelo antes de lanzarse a un migración total, sin arriesgarse a
igor@408: perder trabajo alguno.
igor@408: 
igor@408: La orden \hgxcmd{conver}{convert} es sencilla de usar. Basta con
igor@408: apuntarla hacia la ruta o el URL del repositorio fuente, opcionalmente
igor@408: darle el nombre del nombre del repositorio destino y comenzará a hacer
igor@408: su trabajo. Después de la conversión inicial, basta con invocar de
igor@408: nuevo la orden para importar nuevos cambios.
igor@402: 
igor@402: 
igor@402: %%% Local Variables: 
igor@402: %%% mode: latex
igor@402: %%% TeX-master: "00book"
igor@402: %%% End: