hgbook

annotate es/intro.tex @ 510:98fb436b58c1

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