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