hgbook
annotate es/intro.tex @ 964:6b680d569bb4
deleting a bunch of files not longer necessary to build the documentation.
Adding missing newly files needed to build the documentation
Adding missing newly files needed to build the documentation
author | Romain PELISSE <belaran@gmail.com> |
---|---|
date | Sun Aug 16 04:58:01 2009 +0200 (2009-08-16) |
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: |