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