hgbook

annotate es/intro.tex @ 890:2887b61fa4fe

find changesets by author, revision, files, or words in the commit message
Change fields to fieldsets in the Comment admin model. The 'date'
field isn't working properly for an unknown reason, so it has been
removed from the interface temporarily.
author dukebody <dukebody@gmail.com>
date Sun Oct 11 21:12:46 2009 +0200 (2009-10-11)
parents 3f32047a3f25
children
rev   line source
igor@403 1 \chapter{Introducción}
igor@402 2 \label{chap:intro}
igor@402 3
igor@403 4 \section{Acerca del control de revisiones}
igor@403 5
igor@403 6 El control de revisiones es el proceso de administrar diferentes
igor@403 7 versiones de una pieza de información. En su forma más simple es algo
igor@403 8 que la mayoría de gente hace a mano: cada vez que usted modifica un
jerojasro@509 9 fichero, lo graba con un nuevo nombre que contiene un número, cada uno
jerojasro@509 10 mayor que el anterior.
jerojasro@509 11
jerojasro@509 12 Administrar manualmente muchas versiones de incluso sólo un fichero es una tarea
igor@403 13 propensa a errores, a pesar de que hace bastante tiempo hay
igor@403 14 herramientas que ayudan en este proceso. Las primeras herramientas
igor@403 15 para automatizar el control de revisiones fueron pensadas para que un
igor@403 16 usuario administrara un solo fichero. En las décadas pasadas, el
igor@403 17 alcance de las herramientas de control de revisiones ha ido aumentando
igor@408 18 considerablemente; ahora manejan muchos ficheros y facilitan el
igor@403 19 trabajo en conjunto de varias personas. Las mejores herramientas de
igor@403 20 control de revisiones de la actualidad no tienen problema con miles de
jerojasro@509 21 personas trabajando en proyectos que consisten de cientos de miles de
igor@403 22 ficheros.
igor@403 23
igor@403 24 \subsection{¿Por qué usar control de revisiones?}
igor@403 25
igor@403 26 Hay muchas razones por las cuales usted o su equipo desearía usar una
igor@403 27 herramienta automática de control de revisiones para un proyecto.
igor@402 28 \begin{itemize}
jerojasro@517 29 \item Llevar registro del historial y la evolución de su proyecto, para
jerojasro@509 30 evitar hacer la tarea manualmente. Por cada cambio, tendrá una
igor@403 31 bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
igor@403 32 \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
igor@403 33 \item Cuando trabaja con más personas, los programas de control de
igor@403 34 revisiones facilitan la colaboración. Por ejemplo, cuando varias
jerojasro@509 35 personas hacen cambios potencialmente incompatibles de forma casi
jerojasro@509 36 simultánea, el programa le ayudará a identificar y resolver tales
igor@403 37 conflictos.
igor@403 38 \item Puede ayudarle a recuperarse de equivocaciones. Si aplica un
igor@403 39 cambio que posteriormente se evidencia como un error, puede
igor@403 40 revertirlo a una versión previa a uno o muchos ficheros. De hecho,
igor@403 41 una herramienta \emph{realmente} buena, incluso puede ayudarle
igor@403 42 efectivamente a darse cuenta exactamente cuándo se introdujo el
jerojasro@509 43 error (para más detalles ver la sección~\ref{sec:undo:bisect}).
jerojasro@509 44 \item Le ayudará a trabajar simultáneamente, y a manejar las diferencias
igor@403 45 entre múltiples versiones de su proyecto.
igor@402 46 \end{itemize}
jerojasro@476 47 La mayoría de estas razones son igualmente válidas ---por lo menos en
jerojasro@509 48 teoría--- así esté trabajando en un proyecto solo usted, o con mucha gente.
igor@403 49
igor@403 50 Algo fundamental acerca de lo práctico de un sistema de control de
jerojasro@509 51 revisiones en estas dos escalas (``un hacker solitario'' y ``un equipo
igor@403 52 gigantesco'') es cómo se comparan los \emph{beneficios} con los
igor@403 53 \emph{costos}. Una herramienta de control de revisiones que sea
igor@403 54 difícil de entender o usar impondrá un costo alto.
igor@403 55
igor@403 56 Un proyecto de quinientas personas es muy propenso a colapsar
jerojasro@509 57 solamente con su peso inmediatamente sin una herramienta y un proceso
jerojasro@509 58 de control de versiones. En este caso, el costo de usar control de
jerojasro@476 59 revisiones ni siquiera se tiene en cuenta, puesto que \emph{sin} él,
igor@403 60 el fracaso está casi garantizado.
igor@403 61
igor@403 62 Por otra parte, un ``arreglo rápido'' de una sola persona, excluiría
igor@403 63 la necesidad de usar una herramienta de control de revisiones, porque
igor@403 64 casi seguramente, el costo de usar una estaría cerca del costo del
igor@403 65 proyecto. ¿No es así?
igor@403 66
jerojasro@509 67 Mercurial soporta \emph{ambas} escalas de de desarrollo de manera
jerojasro@509 68 única. Puede aprender lo básico en pocos minutos, y dado su bajo
igor@403 69 sobrecosto, puede aplicar el control de revisiones al proyecto más
igor@403 70 pequeño con facilidad. Su simplicidad significa que no tendrá que
igor@403 71 preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
igor@403 72 por espacio mental con lo que sea que \emph{realmente} esté tratando
igor@403 73 de hacer. Al mismo tiempo, Mercurial tiene alto desempeño y su
jerojasro@509 74 %TODO distribuida? en vez de p2p
igor@403 75 naturaleza peer-to-peer le permite escalar indoloramente para manejar
igor@403 76 grandes proyectos.
igor@403 77
igor@403 78 Ninguna herramienta de control de revisiones puede salvar un
igor@403 79 proyecto mal administrado, pero la elección de herramientas puede
jerojasro@509 80 hacer una gran diferencia en la fluidez con la cual usted puede
jerojasro@509 81 trabajar en un proyecto.
igor@403 82
igor@403 83 \subsection{La cantidad de nombres del control de revisiones}
igor@403 84
jerojasro@509 85 El control de revisiones es un campo amplio, tan amplio que no hay un
igor@403 86 acrónimo o nombre único. A continuación presentamos un listado de
igor@403 87 nombres comunes y acrónimos que se podrían encontrar:
igor@402 88 \begin{itemize}
igor@403 89 \item Control de revisiones (RCS)
jerojasro@510 90 \item Manejo de Configuraciones de Programas (SCM), o administracón de
igor@403 91 configuraciones
igor@403 92 \item Administración de código fuente
igor@403 93 \item Control de Código Fuente, o Control de Fuentes
jerojasro@510 94 \item Control de Versiones (VCS)
igor@402 95 \end{itemize}
igor@403 96 Algunas personas aducen que estos términos tienen significados
jerojasro@526 97 diversos, pero en la práctica se sobreponen tanto que no hay una
jerojasro@509 98 forma acordada o incluso adecuada de separarlos.
igor@403 99
igor@403 100 \section{Historia resumida del control de revisiones}
igor@403 101
igor@403 102 La herramienta de control de revisiones más antigua conocida es SCCS
igor@403 103 (Sistema de Control de Código), escrito por Marc Rochkind en Bell
jerojasro@510 104 Labs, a comienzos de los setentas (1970s). SCCS operaba sobre ficheros
igor@403 105 individuales, y requería que cada persona que trabajara en el proyecto
igor@403 106 tuviera acceso a un espacio compartido en un solo sistema. Solamente
igor@408 107 una persona podía modificar un fichero en un momento dado; el
igor@403 108 arbitramiento del acceso a los ficheros se hacía con candados. Era
igor@403 109 común que la gente pusiera los candados a los ficheros, y que
igor@403 110 posteriormente olvidara quitarlos, impidiendo que otro pudiera
igor@403 111 modificar los ficheros en cuestión sin la intervención del
igor@403 112 administrador.
igor@403 113
jerojasro@509 114 Walter Tichy desarrolló una alternativa gratuita a SCCS a comienzos
jerojasro@510 115 de los ochentas (1980s); llamó a su programa RCS (Sistema de Control de
igor@403 116 Revisiones). Al igual que SCCS, RCS requería que los desarrolladores
igor@403 117 trabajaran en un único espacio compartido y colocaran candados a los
jerojasro@509 118 ficheros para evitar que varias personas los modificaran
igor@403 119 simultáneamente.
igor@403 120
igor@403 121 Después en los ochenta, Dick Grune usó RCS como un bloque de
igor@403 122 construcción para un conjunto de guiones de línea de comando, que
jerojasro@509 123 inicialmente llamó cmt, pero que renombró a CVS (Sistema Concurrente de
igor@403 124 Versiones). La gran innovación de CVS era que permitía a los
igor@403 125 desarrolladores trabajar simultáneamente de una forma más o menos
igor@403 126 independiente en sus propios espacios de trabajo. Los espacios de
jerojasro@509 127 trabajo personales impedían que los desarrolladores se pisaran las
igor@403 128 mangueras todo el tiempo, situación común con SCCS y RCS. Cada
jerojasro@509 129 desarrollador tenía una copia de todos los ficheros del proyecto y podía
jerojasro@509 130 modificar sus copias independientemente, Tenían que fusionar sus
igor@403 131 ediciones antes de consignar los cambios al repositorio central.
igor@403 132
igor@403 133 Brian Berliner tomó los scripts originales de Grune y los reescribió
jerojasro@509 134 en~C, publicando en 1989 el código sobre el cual se ha
jerojasro@509 135 desarrollado la versión moderna de CVS. CVS adquirió posteriormente
igor@403 136 la habilidad de operar sobre una conexión de red, dotándolo de una
igor@403 137 arquitectura, cliente/servidor. La arquitectura de CVS es
jerojasro@516 138 centralizada; el historial del proyecto está únicamente en el
igor@403 139 repositorio central. Los espacios de trabajo de los clientes
igor@403 140 contienen únicamente copias recientes de las versiones de los
igor@403 141 ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
igor@403 142 ha tenido un éxito enorme; Es probablemente el sistema de control de
igor@403 143 revisiones más extendido del planeta.
igor@402 144
jerojasro@509 145 A comienzos de los noventa~(1990s), Sun MicroSystems desarrollo un
jerojasro@509 146 temprano sistema distribuido de control de revisiones llamado
jerojasro@509 147 TeamWare.
jerojasro@517 148 Un espacio de trabajo TeamWare contiene una copia completa del
jerojasro@516 149 historial del proyecto. TeamWare no tiene la noción de repositorio
jerojasro@516 150 central. (CVS se basaba en RCS para el almacenamiento de su historial;
igor@404 151 TeamWare usaba SCCS.)
igor@404 152
jerojasro@509 153 A medida que avanzaba la decada de los noventa, se empezó a
jerojasro@509 154 evidenciar los problemas de CVS. Almacena cambios simultáneos a muchos
igor@408 155 ficheros de forma individual, en lugar de agruparlos como una
igor@404 156 operación única y atómica lógicamente. No maneja bien su jerarquía de
jerojasro@509 157 ficheros; es fácil desordenar un repositorio al renombrar ficheros
igor@404 158 y directorios. Peor aún, su código fuente es difícil de leer y
jerojasro@509 159 mantener, lo que hizo que su ``umbral de dolor'' para arreglar sus
jerojasro@509 160 problemas arquitecturales fuera algo prohibitivo.
igor@404 161
igor@404 162 En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
igor@404 163 trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
igor@404 164 herramienta con mejor arquitectura y código más limpio. El resultado,
igor@404 165 Subversion, no se separó del modelo centralizado cliente/servidor de
igor@404 166 CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
jerojasro@509 167 manejo de espacios de nombres , y otras características que lo hacen
igor@404 168 mejor que CVS. Desde su versión inicial, ha ido creciendo en
jerojasro@509 169 popularidad rápidamente.
igor@404 170
igor@404 171 Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
jerojasro@509 172 ambicioso sistema distribuido de control de versiones que llamó
igor@404 173 Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
igor@404 174 diseño de CVS con una arquitectura peer-to-peer, fue mucho más
jerojasro@509 175 allá de las herramientas anteriores (y posteriores) de
igor@404 176 control de revisiones en varios aspectos innovadores. Usa hashes
igor@404 177 criptográficos como identificadores, y tiene una noción integral de
igor@404 178 ``confianza'' para código de diversas fuentes.
igor@404 179
igor@404 180 Mercurial nació en el 2005. Algunos de sus aspectos de de diseño
igor@404 181 fueron influenciados por Monotone, pero Mercurial se enfoca en la
igor@404 182 facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
igor@404 183 grandes.
igor@404 184
igor@404 185 \section{Tendencias en el control de revisiones}
igor@404 186
jerojasro@509 187 Ha habido una tendencia inconfundible en el desarrollo y uso de las herramientas
jerojasro@509 188 de control de revisiones en las cuatro décadas pasadas, mientras la
jerojasro@509 189 gente se ha hecho familiar con las capacidades de sus herramientas y
jerojasro@509 190 se ha visto restringida por sus limitaciones.
igor@404 191
igor@408 192 La primera generación comenzó administrando ficheros individuales en
igor@404 193 computadores por persona. A pesar de que tales herramientas
igor@404 194 representaron un avance importante frente al control de revisiones
jerojasro@509 195 manual, su modelo de candados y la dependencia a un sólo computador
jerojasro@509 196 los limitó a equipos de trabajo pequeños y acoplados.
igor@404 197
igor@404 198 La segunda generación dejó atrás esas limitaciones moviéndose a
igor@404 199 arquitecturas centradas en redes, y administrando proyectos completos
jerojasro@509 200 a la vez. A medida que los proyectos crecían, nacieron nuevos
igor@404 201 problemas. Con la necesidad de comunicación frecuente con los
igor@404 202 servidores, escalar estas máquinas se convirtió en un problema en
jerojasro@509 203 proyectos realmente grandes. Las redes con poca estabilidad podrían
jerojasro@509 204 impedir que usuarios remotos se conectaran al servidor. A medida que
jerojasro@509 205 los
jerojasro@509 206 proyectos de código abierto comenzaron a ofrecer acceso de sólo lectura
jerojasro@509 207 de forma anónima a cualquiera, la gente sin permiso para consignar
igor@404 208 vio que no podían usar tales herramientas para interactuar en un
igor@404 209 proyecto de forma natural, puesto que no podían guardar sus cambios.
igor@404 210
jerojasro@509 211 La generación actual de herramientas de control de revisiones es
jerojasro@509 212 peer-to-peer por naturaleza. Todos estos sistemas han eliminado la
igor@404 213 dependencia de un único servidor central, y han permitido que la
igor@404 214 gente distribuya sus datos de control de revisiones donde realmente se
igor@404 215 necesita. La colaboración a través de Internet ha cambiado las
jerojasro@509 216 limitantes tecnológicas por la cuestión de elección y consenso. Las
jerojasro@509 217 herramientas modernas pueden operar sin conexión indefinidamente y
igor@404 218 autónomamente, necesitando una conexión de red solamente para
igor@404 219 sincronizar los cambios con otro repositorio.
igor@404 220
igor@404 221 \section{Algunas ventajas del control distribuido de revisiones}
igor@404 222
igor@404 223 A pesar de que las herramientas para el control distribuido de
jerojasro@509 224 revisiones lleva varios años siendo tan robustas y usables como la
jerojasro@509 225 generación previa de sus contrapartes, algunas personas que usan las
jerojasro@509 226 herramientas más antiguas no se han percatado de sus ventajas. Hay
jerojasro@509 227 gran cantidad
igor@404 228 de situaciones en las cuales las herramientas distribuidas brillan
igor@404 229 frente a las centralizadas.
igor@404 230
igor@404 231 Para un desarrollador individual, las herramientas distribuidas casi
igor@404 232 siempre son más rápidas que las centralizadas. Por una razón sencilla:
igor@404 233 Una herramienta centralizada necesita comunicarse por red para las
igor@404 234 operaciones más usuales, debido a que los metadatos se almacenan en
igor@404 235 una sola copia en el servidor central. Una herramienta distribuida
igor@404 236 almacena todos sus metadatos localmente. Con todo lo demás de la
igor@404 237 misma forma, comunicarse por red tiene un sobrecosto en una
igor@404 238 herramienta centralizada. No subestime el valor de una herramienta de
igor@404 239 respuesta rápida: Usted empleará mucho tiempo interactuando con su
igor@404 240 programa de control de revisiones.
igor@404 241
igor@404 242 Las herramientas distribuidas son indiferentes a los caprichos de su
igor@404 243 infraestructura de servidores, de nuevo, debido a la replicación de
igor@404 244 metadatos en tantos lugares. Si usa un sistema centralizado y su
igor@404 245 servidor explota, ojalá los medios físicos de su copia de seguridad
igor@404 246 sean confiables, y que su última copia sea reciente y además
igor@404 247 funcione. Con una herramienta distribuida tiene tantas copias de
igor@404 248 seguridad disponibles como computadores de contribuidores.
igor@404 249
igor@404 250 La confiabilidad de su red afectará las herramientas distribuidas de
jerojasro@509 251 una forma mucho menor que a las herramientas centralizadas. Usted no puede
igor@404 252 siquiera usar una herramienta centralizada sin conexión de red,
jerojasro@509 253 excepto por algunas órdenes muy limitadas. Con herramientas
igor@404 254 distribuidas, si sus conexión cae mientras usted está trabajando,
igor@404 255 podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
igor@404 256 comunicarse con repositorios en otros computadores, algo que es
igor@404 257 relativamente raro comparado con las operaciones locales. Si tiene
jerojasro@509 258 colaboradores remotos en su equipo, puede ser importante.
igor@404 259
igor@404 260 \subsection{Ventajas para proyectos de código abierto}
igor@404 261
igor@404 262 Si descubre un proyecto de código abierto y decide que desea comenzar
igor@404 263 a trabajar en él, y ese proyecto usa una herramienta de control
jerojasro@509 264 distribuido de revisiones, usted es de inmediato un par con la gente que se
jerojasro@509 265 considera el ``alma'' del proyecto. Si ellos publican sus
jerojasro@516 266 repositorios, usted puede copiar inmediatamente el historial del proyecto,
igor@404 267 hacer cambios y guardar su trabajo, usando las mismas herramientas de
igor@404 268 la misma forma que ellos. En contraste, con una herramienta
jerojasro@509 269 centralizada, usted debe usar el programa en un modo ``sólo lectura'' a
igor@404 270 menos que alguien le otorgue permisos para consignar cambios en el
igor@404 271 repositorio central. Hasta entonces, no podrá almacenar sus cambios y
igor@404 272 sus modificaciones locales correrán el riesgo de dañarse cuando trate
igor@404 273 de actualizar su vista del repositorio.
igor@404 274
jerojasro@509 275 \subsubsection{Las bifurcaciones (forks) no son un problema}
igor@404 276
igor@404 277 Se ha mencionado que las herramientas de control distribuido de
igor@404 278 versiones albergan un riesgo a los proyectos de código abierto, puesto
jerojasro@509 279 que se vuelve muy sencillo hacer una ``bifurcación''\ndt{fork.} del
jerojasro@509 280 desarrollo del proyecto. Una bifurcación sucede cuando hay diferencias
jerojasro@509 281 de opinión o actitud entre grupos de desarrolladores que desemboca en
igor@404 282 la decisión de la imposibilidad de continuar trabajando juntos. Cada
igor@404 283 parte toma una copia más o menos completa del código fuente del
igor@404 284 proyecto y toma su propio rumbo.
igor@404 285
igor@404 286 En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
igor@404 287 diferencias. Con un sistema centralizado de control de revisiones, el
igor@404 288 proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
jerojasro@516 289 forma muy manual. Usted tiene que decidir qué historial de revisiones va a
jerojasro@509 290 ``ganar'', e injertar los cambios del otro equipo en el árbol de alguna
igor@404 291 manera. Con esto usualmente se pierde algo o todo del historial de la
igor@404 292 revisión de alguna de las partes.
igor@404 293
igor@404 294 Lo que las herramientas distribuidas hacen con respecto a las
igor@404 295 bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
igor@404 296 desarrollar un proyecto. Cada cambio que usted hace es potencialmente
igor@404 297 un punto de bifurcación. La gran fortaleza de esta aproximación es que
igor@404 298 las herramientas distribuidas de control de revisiones tiene que ser
igor@404 299 bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
igor@404 300 son absolutamente fundamentales: pasan todo el tiempo.
igor@404 301
jerojasro@509 302 Si todas las porciones de trabajo que todos hacen, todo el tiempo, se
jerojasro@509 303 enmarcan en términos de bifurcaciones y fusiones, entonces a aquello a
igor@404 304 lo que se refiere en el mundo del código abierto a una ``bifurcación''
igor@404 305 se convierte \emph{puramente} en una cuestión social. Lo que hacen las
igor@404 306 herramientas distribuidas es \emph{disminuir} la posibilidad de una
igor@404 307 bifurcación porque:
igor@402 308 \begin{itemize}
jerojasro@509 309 \item Eliminan la distinción social que imponen las herramientas
jerojasro@509 310 centralizadas: aquélla entre miembros (personas con permiso de
jerojasro@509 311 consignar) y forasteros (los que no tienen el permiso).
igor@404 312 \item Facilitan la reconciliación después de una bifurcación social,
igor@404 313 porque todo lo que concierne al programa de control de revisiones es
igor@404 314 una fusión.
igor@402 315 \end{itemize}
igor@402 316
igor@404 317 Algunas personas se resisten a las herramientas distribuidas porque
igor@404 318 desean mantener control completo sobre sus proyectos, y creen que las
jerojasro@509 319 herramientas centralizadas les dan tal control. En todo caso, si este
jerojasro@509 320 es su parecer, y usted publica sus repositorios de CVS o Subversion, hay
jerojasro@516 321 muchas herramientas disponibles que pueden obtener el historial
jerojasro@516 322 completo (aunque sea lentamente) y recrearlo en otro sitio que usted no
igor@407 323 controla. Siendo así un control ilusorio, puesto que está impidiendo
igor@407 324 la fluidez de colaboración en lugar de prevenir que alguien se sienta
jerojasro@516 325 impulsado a obtener una copia y hacer una bifurcación con su historial.
igor@407 326
igor@407 327 \subsection{Ventajas para proyectos comerciales}
igor@407 328
igor@407 329 Muchos proyectos comerciales tienen grupos de trabajo distribuidos
igor@407 330 alrededor del globo. Quienes contribuyen y están lejos de un
jerojasro@509 331 repositorio central verán una ejecución más lenta de los comandos y tal
igor@407 332 vez menos confiabilidad. Los sistemas de control de revisión
igor@407 333 comerciales intentan amortiguar estos problemas con adiciones de
igor@407 334 replicación remota que usualmente son muy costosos y complicados de
jerojasro@509 335 administrar. Un sistema distribuido no padece estos problemas. Mejor
igor@407 336 aún, puede colocar varios servidores autorizados, por ejemplo, uno por
igor@407 337 sitio, de tal forma que no haya comunicación redundante entre
igor@407 338 repositorios sobre enlaces de conexión costosos.
igor@407 339
igor@407 340 Los sistemas de control de revisiones distribuidos tienden a ser poco
jerojasro@509 341 escalables. No es inusual que costosos sistemas centralizados caigan
igor@407 342 ante la carga combinada de unas cuantas docenas de usuarios
jerojasro@509 343 concurrentes. De nuevo, las respuestas típicas de replicación tienden
igor@407 344 a ser costosas y complejas de instalar y administrar. Dado que la
igor@407 345 carga en un servidor central---si es que tiene uno---es muchas veces
jerojasro@509 346 menor con una herramienta distribuida (debido a que los datos están
jerojasro@509 347 replicados en todas partes), un solo servidor económico puede tratar
igor@407 348 las necesidades de equipos mucho más grandes, y la replicación para
jerojasro@509 349 balancear la carga se vuelve cosa de guiones.
igor@407 350
igor@407 351 Si tiene un empleado en el campo, se beneficiará grandemente de un
igor@407 352 sistema distribuido de control de versiones al resolver problemas en
igor@407 353 el sitio del cliente. La herramienta le permitirá generar
igor@407 354 construcciones a la medida, probar diferentes arreglos de forma
jerojasro@516 355 independiente y buscar de forma eficiente las fuentes de fallos en el
jerojasro@516 356 historial y regresiones en los ambientes de los clientes, todo sin
igor@407 357 necesidad de conectarse al servidor de su compañía.
igor@407 358
igor@407 359 \section{¿Por qué elegir Mercurial?}
igor@407 360
igor@407 361 Mercurial cuenta con un conjunto único de propiedades que lo hacen
jerojasro@509 362 una elección particularmente buena como sistema de control de
igor@407 363 revisiones, puesto que:
igor@402 364 \begin{itemize}
igor@407 365 \item Es fácil de aprender y usar.
igor@407 366 \item Es liviano.
igor@407 367 \item Escala de forma excelente.
igor@407 368 \item Es fácil de acondicionar.
igor@402 369 \end{itemize}
igor@402 370
igor@407 371 Si los sistemas de control de revisiones le son familiares, debería
jerojasro@509 372 estar listo para usar Mercurial en menos de cinco minutos. Si no, sólo va a
igor@407 373 tomar unos pocos minutos más. Las órdenes de Mercurial y su conjunto
igor@407 374 de características son uniformes y consistentes generalmente, y basta
igor@407 375 con que siga unas pocas reglas generales en lugar de un montón de
igor@407 376 excepciones.
igor@407 377
jerojasro@509 378 En un proyecto pequeño, usted puede comenzar a trabajar con Mercurial en
jerojasro@509 379 pocos momentos. Crear nuevos cambios y ramas, transferir cambios (localmente
jerojasro@516 380 o por la red); y las operaciones relacionadas con el estado y el
jerojasro@516 381 historial son rápidas. Mercurial buscar ser ligero y no incomodar en su
igor@407 382 camino combinando poca sobrecarga cognitiva con operaciones
igor@407 383 asombrosamente rápidas.
igor@407 384
igor@407 385 La utilidad de Mercurial no se limita a proyectos pequeños: está
igor@407 386 siendo usado por proyectos con centenas de miles de contribuyentes,
igor@407 387 cada uno conteniendo decenas de miles de ficheros y centenas de
igor@407 388 megabytes de código fuente
igor@407 389
igor@407 390 Si la funcionalidad básica de Mercurial no es suficiente para usted,
igor@407 391 es muy fácil extenderlo. Mercurial se comporta muy bien con tareas de
igor@407 392 scripting y su limpieza interna junto con su implementación en Python
igor@407 393 permiten añadir características fácilmente en forma de extensiones.
igor@407 394 Hay un buen número de extensiones útiles y populares en este momento,
jerojasro@509 395 desde ayudar a identificar fallos hasta mejorar su desempeño.
igor@407 396
igor@407 397 \section{Comparación de Mercurial con otras herramientas}
igor@407 398
igor@407 399 Antes de leer, por favor tenga en cuenta que esta sección
jerojasro@509 400 necesariamente refleja mis propias experiencias, intereses y (tengo que
igor@407 401 decirlo) mis preferencias. He usado cada una de las herramientas de
igor@407 402 control de versiones listadas a continuación, y en muchos casos por
igor@407 403 varios años.
igor@402 404
igor@402 405
igor@402 406 \subsection{Subversion}
igor@402 407
igor@407 408 Subversion es una herramienta de control de revisiones muy popular,
jerojasro@509 409 desarrollada para reemplazar a CVS. Tiene una arquitectura
jerojasro@509 410 centralizada tipo cliente/servidor.
jerojasro@509 411
jerojasro@509 412 Subversion y Mercurial tienen comandos con nombres similares para hacer
igor@407 413 las mismas operaciones, por lo que si le son familiares en una, será
igor@407 414 sencillo aprender a usar la otra. Ambas herramientas son portables en
igor@407 415 todos los sistemas operativos populares.
igor@407 416
igor@407 417 Antes de la versión 1.5, Subversion no tenía soporte para fusiones. En
igor@407 418 el momento de la escritura, sus capcidades para llevar cuenta de las
igor@407 419 funciones son nuevas,
igor@407 420 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicadas
igor@409 421 y poco estables\ndt{buggy}}.
igor@407 422
jerojasro@509 423 Mercurial tiene una ventaja considerable en desempeño sobre
igor@407 424 Subversion en cualquier operación de control de revisiones que yo haya
igor@407 425 medido. He medido sus ventajas con factores desde dos hasta seis veces
igor@408 426 comparando con almacenamiento de ficheros \emph{ra\_local}
igor@407 427 Subversion~1.4.3, el cual es el método de acceso más rápido. En los
jerojasro@509 428 escenarios más realistas incluyendo almacenamiento con la red de por
igor@407 429 medio, Subversion se encuentra en desventaja aún mayor. Dado que casi
igor@407 430 todas las órdenes de Subversion deben tratar con el servidor y
jerojasro@509 431 Subversion no tiene utilidades de replicación adecuadas, la capacidad
igor@407 432 del servidor y el ancho de banda se convierten en cuellos de botella
igor@407 433 para proyectos modestamente grandes.
igor@407 434
jerojasro@509 435 Adicionalmente, Subversion tiene un sobrecosto considerable en
jerojasro@509 436 almacenamiento para evitar transacciones por red en algunas
jerojasro@509 437 operaciones,
jerojasro@510 438 tales como encontrar ficheros modificados (\texttt{status}) y desplegar
jerojasro@510 439 información frente a la revisión actual (\texttt{diff}). Como
igor@407 440 resultado, la copia de trabajo de Subversion termina siendo del mismo
igor@407 441 tamaño o más grande que un repositorio de Mercurial y el directorio de
jerojasro@516 442 trabajo, a pesar de que el repositorio de Mercurial contiene el
jerojasro@516 443 historial completo del proyecto.
igor@407 444
igor@407 445 Subversion tiene soporte amplio de otras herramientas. Mercurial por
igor@407 446 ahora está bastante atrás en este aspecto. Esta diferencia está
igor@409 447 disminuyendo, y algunas de las herramientas GUI\ndt{Interfaz de
igor@407 448 Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual
igor@407 449 que Mercurial, Subversion tiene un excelente manual de usuario.
igor@402 450
jerojasro@516 451 Dado que Subversion no almacena el historial de revisiones en el
igor@408 452 cliente, es muy bueno para administrar proyectos que tienen muchos
igor@408 453 ficheros binarios grandes y opacos. Si consigna cincuenta revisiones
igor@408 454 de un fichero de 10MB que no es comprimible, el esapacio en el cliente
igor@408 455 de Subversion se mantendrá constante mientras que el espacio usado por
igor@408 456 cualquier Sistema Distribuido de Control de Revisiones crecerá
igor@408 457 rápidamente en proporción con el número de revisiones, debido a que
igor@408 458 las diferencias entre cada revisión es grande.
igor@408 459
igor@408 460 Adicionalmente, generalmente es difícil o más bien, imposible mezclar
igor@408 461 diferentes versiones de un fichero binario. La habilidad de Subversion
igor@408 462 para permitirle al usuario poner una cerradura a un fichero, de modo
igor@408 463 que tenga un permiso exclusivo para consignar cambios, puede ser una
igor@408 464 ventaja significativa en un proyecto donde los ficheros binarios sean
igor@408 465 usados ampliamente.
igor@408 466
jerojasro@516 467 Mercurial puede importar el historial de revisiones de un repositorio
jerojasro@516 468 de Subversion. También puede exportar el historial de revisiones a un
igor@408 469 repositorio de Subversion. De esta forma es sencillo ``dar un
igor@408 470 vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
jerojasro@517 471 a dar el paso. La conversión del historial es incremental, de modo
igor@408 472 que puede aplicar una conversión inicial, y después conversiones
igor@408 473 pequeñas y adicionales posteriormente para traer nuevos cambios.
igor@402 474
igor@402 475 \subsection{Git}
igor@402 476
igor@408 477 Git es una herramienta distribuida de control de revisiones
jerojasro@509 478 desarrollada para administrar el arbol del kernel de Linux. Al igual
igor@408 479 que Mercurial los principios de su diseño fueron influenciados por
igor@408 480 Monotone.
igor@408 481
jerojasro@509 482 Git tiene un conjunto de órdenes muy grande; en la versión~1.5.0
igor@408 483 ofrece~139 órdenes individuales. Tiene cierta reputación de ser
igor@408 484 difícil de aprender. Comparado con Git, Mercurial tiene un fuerte
igor@408 485 enfoque hacia la facilidad.
igor@408 486
igor@408 487 En términos de rendimiento, Git es extremadamente rápido. En muchos
igor@408 488 casos, es más rápido que Mercurial, por lo menos en Linux, mientras
igor@408 489 que Mercurial se comporta mejor en otras operaciones. De todas
igor@408 490 maneras en Windows, el desempeño y el nivel general de soporte que
jerojasro@509 491 ofrece Git, al momento de la escritura, está bastante atrás de
igor@408 492 Mercurial.
igor@408 493
igor@408 494 Mientras que el repositorio de Mercurial no requiere mantenimiento, el
jerojasro@509 495 repositorio de Git requiere frecuentes ``reempaquetados'' de sus metadatos.
jerojasro@509 496 Sin estos, el desempeño se degrada y el uso de espacio crece rápidamente. Un
igor@408 497 servidor que contenga repositorios de Git que no sean reempacados
jerojasro@509 498 rigurosa y frecuentemente requerirá trabajo intenso de disco durante
igor@408 499 las copias de seguridad, y ha habido situaciones en copias de
jerojasro@509 500 seguridad diaria que toman más de~24 horas como resultado. Un
igor@408 501 repositorio recién reempacado de Git es un poco más pequeño que un
igor@408 502 repositorio de Mercurial, pero un repositorio sin reempacar es varios
igor@408 503 órdenes de magnitud más grande.
igor@408 504
igor@408 505 El corazón de Git está escrito en C. Muchas órdenes de Git están
jerojasro@509 506 implementadas como guiones de línea de comandos o de Perl y la calidad de esos
jerojasro@509 507 guiones varía ampliamente. He encontrado muchas situaciones en las
jerojasro@509 508 cuales los guiones no tuvieron en cuenta la presencia de errores que
igor@408 509 podrían haber sido fatales.
igor@408 510
igor@408 511 Mercurial puede importar el historial de revisiones de un repositorio
igor@408 512 de Git.
igor@402 513
igor@402 514 \subsection{CVS}
igor@402 515
igor@408 516 CVS es probablemente la herramienta de control de revisiones más
igor@408 517 ampliamente usada en el planeta. Debido a su edad y su poca pulcritud
jerojasro@509 518 interna, ha sido ligeramente mantenida en muchos años.
igor@408 519
igor@408 520 Tiene una arquitectura centralizada cliente/servidor. No agrupa
jerojasro@509 521 cambios relacionados en consignaciones atómicas, pemitiendo que con
igor@408 522 facilidad la gente ``rompa la construcción'': una persona puede
igor@408 523 consignar exitósamente parte del cambio y estar bloqueada por la
igor@408 524 necesidad de una mezcla, forzando a otras personas a ver solamente una
igor@408 525 porción del trabajo que estaban buscando hacer. Esto afecta también
jerojasro@516 526 la forma como usted trabaja con el historial del proyecto. Si quiere
igor@408 527 ver todas las modificaciones que alguien hizo como parte de una tarea,
igor@408 528 necesitará inspeccionar manualmente las descripciones y las marcas de
jerojasro@509 529 tiempo de cambio de cada fichero involucrado (esto, si usted saber
igor@408 530 cuáles eran tales ficheros).
igor@408 531
igor@408 532 CVS tiene una noción confusa de etiquetas y ramas que yo no trataría
igor@408 533 incluso de describir. No soporta renombramiento de ficheros o
jerojasro@509 534 directorios adecuadamente, facilitando el corromper un
igor@408 535 repositorio. Casi no tiene chequeo de consistencia interna, por lo
igor@408 536 tanto es casi imposible identificar por que o cómo se corrompió un
igor@408 537 repositorio. Yo no recomendaría un repositorio de CVS para proyecto
igor@408 538 alguno, ni existente ni nuevo.
igor@408 539
jerojasro@516 540 Mercurial puede importar el historial de revisiones de CVS. De todas
jerojasro@509 541 maneras hay ciertas precauciones que aplican; las cuales también son
jerojasro@509 542 necesarias para cualquier herramienta importadora de historial de
igor@408 543 CVS. Debido a la falta de atomicidad de cambios y el no versionamiento
jerojasro@509 544 de la jerarquía del sistema de ficheros, es imposible reconstruir
jerojasro@516 545 completamente el historial de CVS con precisión; hay cierto trabajo de
igor@408 546 conjetura involucrado y los renombramientos tampoco se
igor@408 547 mostrarán. Debido a que gran parte de la administración avanzada de
igor@408 548 CVS tiene que hacerse manualmente y por lo tanto es proclive al error,
igor@408 549 es común que los importadores de CVS encuentren muchos problemas con
jerojasro@509 550 repositorios corruptos (marcas de tiempo totalmente desubicadas y
jerojasro@509 551 ficheros que han permanecido con candados por más de una década son
jerojasro@509 552 dos de los problemas menos interesantes de los que puedo retomar de mi
igor@408 553 experiencia personal).
igor@408 554
jerojasro@516 555 Mercurial puede importar el historial de revisiones de un repositorio
igor@408 556 CVS.
igor@408 557
igor@408 558 \subsection{Herramientas comerciales}
igor@408 559
igor@408 560 Perforce tiene una arquitectura centralizada cliente/servidor sin
jerojasro@509 561 almacenamiento de dato alguno de caché en el lado del cliente. A diferencia de
igor@408 562 las herramientas modernas de control de revisiones, Perforce requiere
jerojasro@509 563 que un usuario ejecute un comando para informar al servidor acerca de
igor@408 564 todo fichero que se vaya a editar.
igor@408 565
igor@408 566 El rendimiento de Perforce es muy bueno para equipos pequeños, pero se
igor@408 567 degrada rápidamente cuando el número de usuarios va más allá de pocas
igor@408 568 docenas. Instalaciones modestamente grandes de Perforce requiere la
igor@408 569 organización de proxies para soportar la carga que sus usuarios generan.
igor@408 570
igor@408 571 \subsection{Elegir una herramienta de control de revisiones}
igor@408 572
igor@408 573 Con la excepción de CVS, toda las herramientas que se han listado
jerojasro@509 574 anteriormente tienen fortalezas únicas que las hacen valiosas de acuerdo al
igor@408 575 tipo de trabajo. No hay una única herramienta de control de revisiones
igor@408 576 que sea la mejor en todas las situaciones.
igor@408 577
igor@408 578 Por ejemplo, Subversion es una buena elección para trabajar con
igor@408 579 edición frecuente de ficheros binarios, debido a su naturaleza
igor@408 580 centralizada y soporte para poner candados a ficheros.
igor@408 581
igor@408 582 Personalmente encuentro las propiedades de simplicidad, desempeño, y
igor@408 583 buen soporte de fusiones de Mercurial una combinación llamativa que ha
igor@408 584 dado buenos frutos por varios años.
igor@408 585
igor@408 586
igor@408 587 \section{Migrar de otra herramienta hacia Mercurial}
igor@408 588
igor@408 589 Mercurial viene con una extensión llamada \hgext{convert}, que puede
igor@408 590 importar historiales de revisiones de forma incremental desde varias
igor@408 591 herramientas de control de revisiones. Por ``incremental'', quiero
jerojasro@516 592 decir que puede migrar toda el historial de un proyecto en una primera
igor@408 593 instancia y después volver a ejecutar la migración posteriormente para
igor@408 594 obtener los nuevos cambios que han sucedido después de la migración
igor@408 595 inicial.
igor@408 596
jerojasro@509 597 A continuación presentamos las herramientas de revisiones que soporta
jerojasro@509 598 el comando \hgext{convert}:
igor@402 599 \begin{itemize}
igor@402 600 \item Subversion
igor@402 601 \item CVS
igor@402 602 \item Git
igor@402 603 \item Darcs
igor@402 604 \end{itemize}
igor@402 605
igor@408 606 Adicionalmente, \hgext{convert} puede exportar cambios de Mercurial
igor@408 607 hacia Subversion. Lo que hace posible probar Subversion y Mercurial
igor@408 608 en paralelo antes de lanzarse a un migración total, sin arriesgarse a
igor@408 609 perder trabajo alguno.
igor@408 610
jerojasro@509 611 El comando \hgxcmd{conver}{convert} es sencillo de usar. Basta con
jerojasro@509 612 apuntarlo hacia la ruta o el URL del repositorio fuente, opcionalmente
igor@408 613 darle el nombre del nombre del repositorio destino y comenzará a hacer
igor@408 614 su trabajo. Después de la conversión inicial, basta con invocar de
jerojasro@509 615 nuevo el comando para importar cambios nuevos.
igor@402 616
igor@402 617
igor@402 618 %%% Local Variables:
igor@402 619 %%% mode: latex
igor@402 620 %%% TeX-master: "00book"
igor@402 621 %%% End: