hgbook
view es/intro.tex @ 499:3e176d56ab84
Finished mq-ref.tex translation to spanish
| author | Igor Támara <igor@tamarapatino.org> |
|---|---|
| date | Sat Jan 10 07:58:01 2009 -0500 (2009-01-10) |
| parents | 04ba1c7785ae |
| children | e98a8c3afcef |
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, el
10 siguiente mayor que el anterior.
12 Administrar manualmente muchas versiones de 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 decenas 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 Contar con la historia 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 de forma casi simultanea pueden hacer cambios
36 incompatibles, 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 permitirá trabajar simultáneamente, y 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, 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 solo'' 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 de control de
58 versiones y un proceso. 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 %TODO el sentido de uniquely va más a decir que hace ambas cosas sin problema,
68 % no a que ``apenas''las soporta, no?
69 Mercurial solamente soporta \emph{ambas} escalas de de
70 desarrollo. Puede aprender lo básico en pocos minutos, y dado su bajo
71 sobrecosto, puede aplicar el control de revisiones al proyecto más
72 pequeño con facilidad. Su simplicidad significa que no tendrá que
73 preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
74 por espacio mental con lo que sea que \emph{realmente} esté tratando
75 de hacer. Al mismo tiempo, Mercurial tiene alto desempeño y su
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 puede trabajar en
82 el proyecto.
84 \subsection{La cantidad de nombres del control de revisiones}
86 El control de revisiones es un campo amplio, tan ampli 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 un
99 acuerdo o una forma 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 gratutita 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 estuvieran modificando
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 impedian 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 todo el fichero del proyecto y podía
131 modificar su copia 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, haciéndolos públicos en 1989, código sobre el cual se ha
136 desarrollado la versión moderna de CVS. CVS posteriormente adquirió
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 centralizada; La historia del proyecto está únicamente en el
140 repositorio central. Los espacios de trabajo de los clientes
141 contienen únicamente copias recientes de las versiones de los
142 ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
143 ha tenido un éxito enorme; Es probablemente el sistema de control de
144 revisiones más extendido del planeta.
146 A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
147 temprano sistema distribuido de revisión de controles llamado TeamWare
148 Un espacio de trabajo TeamWare contiene una copia completa de la
149 historia del proyecto. TeamWare no tiene la noción de repositorio
150 central. (CVS se basaba en RCS para el almacenamiento de su historia;
151 TeamWare usaba SCCS.)
153 A medida que avanzaba la decada de los noventa, se empezño a
154 evidenciar los problemas de CVS. Alacena 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 bien; es fácil desordenar un repositorio renombrando ficheros
158 y directorios. Peor aún, su código fuente es difícil de leer y
159 mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
160 problemas arquitecturales 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 nombres de espacios, y otras características que lo hacen
168 mejor que CVS. Desde su versión inicial, ha ido creciendo en
169 popularidad.
171 Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
172 sistema distribuido de control de versiones ambicioso 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á(junto con otros proyectos subsecuentes) que unas herramientas 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 varias tendencias en el desarrollo y uso de las herramientas
188 de control de revisiones en las pasadas cuatro décadas, mientras la
189 gente se ha vuelto familiar con las capacidades de sus herramientas
190 así mismo con 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 limitación a un sólo computador,
196 determinó 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 uno 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 impidieron
204 que usuarios remotos se conectaran al servidor. A medida que los
205 proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
206 de forma anónima a cualquiera, la gente sin permiso para consignar,
207 vio que no podían usar tales herramientas para interactuar en un
208 proyecto de forma natural, puesto que no podían guardar sus cambios.
210 La generación actual de herramientas de control de revisiones es de
211 forma natural peer-to-peer. Todos estos sistemas han eliminado la
212 dependencia de un único servidor central, y han permitido que la
213 gente distribuya sus datos de control de revisiones donde realmente se
214 necesita. La colaboración a través de Internet ha cambiado las
215 limitantes tecnológicas a la cuestión de elección y consenso. Las
216 herramientas modernas pueden operar sin conexión indefinidamenta y
217 autónomamente, necesitando una conexión de red solamente para
218 sincronizar los cambios con otro repositorio.
220 \section{Algunas ventajas del control distribuido de revisiones}
222 A pesar de que las herramientas para el control distribuido de
223 revisiones lleva varios años siendo tan robusto y usable como la
224 generación previa de su contraparte, personas que usan herramientas
225 más antiguas no se han percatado de sus ventajas. Hay gran cantidad
226 de situaciones en las cuales las herramientas distribuidas brillan
227 frente a las centralizadas.
229 Para un desarrollador individual, las herramientas distribuidas casi
230 siempre son más rápidas que las centralizadas. Por una razón sencilla:
231 Una herramienta centralizada necesita comunicarse por red para las
232 operaciones más usuales, debido a que los metadatos se almacenan en
233 una sola copia en el servidor central. Una herramienta distribuida
234 almacena todos sus metadatos localmente. Con todo lo demás de la
235 misma forma, comunicarse por red tiene un sobrecosto en una
236 herramienta centralizada. No subestime el valor de una herramienta de
237 respuesta rápida: Usted empleará mucho tiempo interactuando con su
238 programa de control de revisiones.
240 Las herramientas distribuidas son indiferentes a los caprichos de su
241 infraestructura de servidores, de nuevo, debido a la replicación de
242 metadatos en tantos lugares. Si usa un sistema centralizado y su
243 servidor explota, ojalá los medios físicos de su copia de seguridad
244 sean confiables, y que su última copia sea reciente y además
245 funcione. Con una herramienta distribuida tiene tantas copias de
246 seguridad disponibles como computadores de contribuidores.
248 La confiabilidad de su red afectará las herramientas distribuidas de
249 una forma mucho menor que las herramientas centralizadas No puede
250 siquiera usar una herramienta centralizada sin conexión de red,
251 excepto con algunas órdenes muy limitadas. Con herramientas
252 distribuidas, si sus conexión cae mientras usted está trabajando,
253 podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
254 comunicarse con repositorios en otros computadores, algo que es
255 relativamente raro comparado con las operaciones locales. Si tiene
256 colaboradores remotos en su equipo, puede ser significante.
258 \subsection{Ventajas para proyectos de código abierto}
260 Si descubre un proyecto de código abierto y decide que desea comenzar
261 a trabajar en él, y ese proyecto usa una herramienta de control
262 distribuido de revisiones, usted es un par con la gente que se
263 considera el ``alma'' del proyecto. Si ellos publican los
264 repositorios, se puede copiar inmediatamente la historia del proyecto,
265 hacer cambios y guardar su trabajo, usando las mismas herramientas de
266 la misma forma que ellos. En contraste, con una herramienta
267 centralizada, debe usar el programa en un modo ``sólo lectura'' a
268 menos que alguien le otorgue permisos para consignar cambios en el
269 repositorio central. Hasta entonces, no podrá almacenar sus cambios y
270 sus modificaciones locales correrán el riesgo de dañarse cuando trate
271 de actualizar su vista del repositorio.
273 \subsubsection{Las bifurcaciones(forks) no son un problema}
275 Se ha mencionado que las herramientas de control distribuido de
276 versiones albergan un riesgo a los proyectos de código abierto, puesto
277 que se vuelve muy sencillo hacer una ``bifurcanción''\ndt{fork.} del
278 desarrollo del proyecto. Una bifurcación pasa cuando hay diferencias
279 de opinión o actitud entre grupos de desarrolladores que desenvoca en
280 la decisión de la imposibilidad de continuar trabajando juntos. Cada
281 parte toma una copia más o menos completa del código fuente del
282 proyecto y toma su propio rumbo.
284 En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
285 diferencias. Con un sistema centralizado de control de revisiones, el
286 proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
287 forma muy manual. Tiene que decidir qué historia de revisiones va a
288 ``win'', e injertar los cambios del otro equipo en el árbol de alguna
289 manera. Con esto usualmente se pierde algo o todo del historial de la
290 revisión de alguna de las partes.
292 Lo que las herramientas distribuidas hacen con respecto a las
293 bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
294 desarrollar un proyecto. Cada cambio que usted hace es potencialmente
295 un punto de bifurcación. La gran fortaleza de esta aproximación es que
296 las herramientas distribuidas de control de revisiones tiene que ser
297 bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
298 son absolutamente fundamentales: pasan todo el tiempo.
300 Si todas las porciones de trabajo que todos hacen todo el tiempo, se
301 enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
302 lo que se refiere en el mundo del código abierto a una ``bifurcación''
303 se convierte \emph{puramente} en una cuestión social. Lo que hacen las
304 herramientas distribuidas es \emph{disminuir} la posibilidad de una
305 bifurcación porque:
306 \begin{itemize}
307 \item Eliminan la distinción social que las herramientas centralizadas
308 imponen: esto entre los miembros (personas con permiso de consignar)
309 y forasteros(los que no tienen el permiso).
310 \item Facilitan la reconciliación después de una bifurcación social,
311 porque todo lo que concierne al programa de control de revisiones es
312 una fusión.
313 \end{itemize}
315 Algunas personas se resisten a las herramientas distribuidas porque
316 desean mantener control completo sobre sus proyectos, y creen que las
317 herramientas centralizadas les da tal control. En todo caso, si este
318 es su parecer, y publica sus repositorios de CVS o Subversion, hay
319 muchas herramientas disponibles que pueden obtener la historia
320 completa(A pesar de lo lento) y recrearla en otro sitio que usted no
321 controla. Siendo así un control ilusorio, puesto que está impidiendo
322 la fluidez de colaboración en lugar de prevenir que alguien se sienta
323 impulsado a obtener una copia y hacer una bifurcación con su historia.
325 \subsection{Ventajas para proyectos comerciales}
327 Muchos proyectos comerciales tienen grupos de trabajo distribuidos
328 alrededor del globo. Quienes contribuyen y están lejos de un
329 repositorio central verán una ejecución más lenta de las órdenes y tal
330 vez menos confiabilidad. Los sistemas de control de revisión
331 comerciales intentan amortiguar estos problemas con adiciones de
332 replicación remota que usualmente son muy costosos y complicados de
333 administradr. Un sistema distribuido no padece estos problemas. Mejor
334 aún, puede colocar varios servidores autorizados, por ejemplo, uno por
335 sitio, de tal forma que no haya comunicación redundante entre
336 repositorios sobre enlaces de conexión costosos.
338 Los sistemas de control de revisiones distribuidos tienden a ser poco
339 escalables. No es inusual quw costosos sistemas centralizados caigan
340 ante la carga combinada de unas cuantas docenas de usuarios
341 concurrentes. De nuevo, las respuestas típicas de replibcación tienden
342 a ser costosas y complejas de instalar y administrar. Dado que la
343 carga en un servidor central---si es que tiene uno---es muchas veces
344 menor con una herramienta distribuida(debido a que los datos están
345 replicados en todas partes), un sólo servidor económico puede tratar
346 las necesidades de equipos mucho más grandes, y la replicación para
347 balancear la carga se vuelve cosa de scripts.
349 Si tiene un empleado en el campo, se beneficiará grandemente de un
350 sistema distribuido de control de versiones al resolver problemas en
351 el sitio del cliente. La herramienta le permitirá generar
352 construcciones a la medida, probar diferentes arreglos de forma
353 independiente y buscar de forma eficiente las fuentes de fallos en la
354 historia y regresiones en los ambientes de los clientes, todo, sin
355 necesidad de conectarse al servidor de su compañía.
357 \section{¿Por qué elegir Mercurial?}
359 Mercurial cuenta con un conjunto único de propiedades que lo hacen
360 particularmente una buena elección como un sistema de control de
361 revisiones, puesto que:
362 \begin{itemize}
363 \item Es fácil de aprender y usar.
364 \item Es liviano.
365 \item Escala de forma excelente.
366 \item Es fácil de acondicionar.
367 \end{itemize}
369 Si los sistemas de control de revisiones le son familiares, debería
370 estar listo para usar Mercurial en menos de cinco minutos. Si no, va a
371 tomar unos pocos minutos más. Las órdenes de Mercurial y su conjunto
372 de características son uniformes y consistentes generalmente, y basta
373 con que siga unas pocas reglas generales en lugar de un montón de
374 excepciones.
376 En un proyecto pequeño, puede comenzar a trabajar con Mercurial poco a
377 poco. Creando nuevos cambios y ramas, transfiriendo cambios(localmente
378 o por la red); y las operaciones relacionadas con el estado y la
379 historia son rápidas. Mercurial buscar ser ligero y no incomodar en su
380 camino combinando poca sobrecarga cognitiva con operaciones
381 asombrosamente rápidas.
383 La utilidad de Mercurial no se limita a proyectos pequeños: está
384 siendo usado por proyectos con centenas de miles de contribuyentes,
385 cada uno conteniendo decenas de miles de ficheros y centenas de
386 megabytes de código fuente
388 Si la funcionalidad básica de Mercurial no es suficiente para usted,
389 es muy fácil extenderlo. Mercurial se comporta muy bien con tareas de
390 scripting y su limpieza interna junto con su implementación en Python
391 permiten añadir características fácilmente en forma de extensiones.
392 Hay un buen número de extensiones útiles y populares en este momento,
393 desde ayudar a identificar fallos hasta el mejoramiento de su
394 desempeño.
396 \section{Comparación de Mercurial con otras herramientas}
398 Antes de leer, por favor tenga en cuenta que esta sección
399 necesariamente refleja mis propias experiencias, intereses y(tengo que
400 decirlo) mis preferencias. He usado cada una de las herramientas de
401 control de versiones listadas a continuación, y en muchos casos por
402 varios años.
405 \subsection{Subversion}
407 Subversion es una herramienta de control de revisiones muy popular,
408 desarrollada para reemplazar a CVS. Su arquitectura es centralizada
409 en cliente/servidor.
411 Subversion y Mercurial tienen órdenes con nombres similares para hacer
412 las mismas operaciones, por lo que si le son familiares en una, será
413 sencillo aprender a usar la otra. Ambas herramientas son portables en
414 todos los sistemas operativos populares.
416 Antes de la versión 1.5, Subversion no tenía soporte para fusiones. En
417 el momento de la escritura, sus capcidades para llevar cuenta de las
418 funciones son nuevas,
419 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicadas
420 y poco estables\ndt{buggy}}.
422 Mercurial tiene una ventaja considerable en el desempeño sobre
423 Subversion en cualquier operación de control de revisiones que yo haya
424 medido. He medido sus ventajas con factores desde dos hasta seis veces
425 comparando con almacenamiento de ficheros \emph{ra\_local}
426 Subversion~1.4.3, el cual es el método de acceso más rápido. En los
427 escenarios más sencillos incluyendo almacenamiento con la red de por
428 medio, Subversion se encuentra en desventaja aún mayor. Dado que casi
429 todas las órdenes de Subversion deben tratar con el servidor y
430 Subversion no tiene utilidades de replicación sencillas, la capacidad
431 del servidor y el ancho de banda se convierten en cuellos de botella
432 para proyectos modestamente grandes.
434 Adicionalmente, Subversion tiene un sobrecosto en almacentamiento
435 considerable para evitar transacciones por red en algunas operaciones,
436 tales como encontrar ficheros modificados(\texttt{status}) y desplegar
437 información frente a la revisión actual(\texttt{diff}). Como
438 resultado, la copia de trabajo de Subversion termina siendo del mismo
439 tamaño o más grande que un repositorio de Mercurial y el directorio de
440 trabajo, a pesar de que el repositorio de Mercurial contiene la
441 historia completa del proyecto.
443 Subversion tiene soporte amplio de otras herramientas. Mercurial por
444 ahora está bastante atrás en este aspecto. Esta diferencia está
445 disminuyendo, y algunas de las herramientas GUI\ndt{Interfaz de
446 Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual
447 que Mercurial, Subversion tiene un excelente manual de usuario.
449 Dado que Subversion no almacena la historia de revisiones en el
450 cliente, es muy bueno para administrar proyectos que tienen muchos
451 ficheros binarios grandes y opacos. Si consigna cincuenta revisiones
452 de un fichero de 10MB que no es comprimible, el esapacio en el cliente
453 de Subversion se mantendrá constante mientras que el espacio usado por
454 cualquier Sistema Distribuido de Control de Revisiones crecerá
455 rápidamente en proporción con el número de revisiones, debido a que
456 las diferencias entre cada revisión es grande.
458 Adicionalmente, generalmente es difícil o más bien, imposible mezclar
459 diferentes versiones de un fichero binario. La habilidad de Subversion
460 para permitirle al usuario poner una cerradura a un fichero, de modo
461 que tenga un permiso exclusivo para consignar cambios, puede ser una
462 ventaja significativa en un proyecto donde los ficheros binarios sean
463 usados ampliamente.
465 Mercurial puede importar la historia de revisiones de un repositorio
466 de Subversion. También puede exportar historia de revisiones a un
467 repositorio de Subversion. De esta forma es sencillo ``dar un
468 vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
469 a dar el paso. La conversión de la historia es incremental, de modo
470 que puede aplicar una conversión inicial, y después conversiones
471 pequeñas y adicionales posteriormente para traer nuevos cambios.
473 \subsection{Git}
475 Git es una herramienta distribuida de control de revisiones
476 desarrollada para administrar el arbol del Kernel de Linux. Al igual
477 que Mercurial los principios de su diseño fueron influenciados por
478 Monotone.
480 Git tiene un conjunto de órdenes muy grande en la versión~1.5.0
481 ofrece~139 órdenes individuales. Tiene cierta reputación de ser
482 difícil de aprender. Comparado con Git, Mercurial tiene un fuerte
483 enfoque hacia la facilidad.
485 En términos de rendimiento, Git es extremadamente rápido. En muchos
486 casos, es más rápido que Mercurial, por lo menos en Linux, mientras
487 que Mercurial se comporta mejor en otras operaciones. De todas
488 maneras en Windows, el desempeño y el nivel general de soporte que
489 ofrece Git, al momento de la escritura, está lejos detrás de
490 Mercurial.
492 Mientras que el repositorio de Mercurial no requiere mantenimiento, el
493 repositorio de Git requiere frecuentes ``repacks'' a sus metadatos.
494 Sin estos, el desempeño se degrada y el espacio crece rápidamente. Un
495 servidor que contenga repositorios de Git que no sean reempacados
496 rigurosa y frecuentemente requerirá trabajo-intenso de disco durante
497 las copias de seguridad, y ha habido situaciones en copias de
498 seguridad diaria que toman más de 24 horas como resultado. Un
499 repositorio recién reempacado de Git es un poco más pequeño que un
500 repositorio de Mercurial, pero un repositorio sin reempacar es varios
501 órdenes de magnitud más grande.
503 El corazón de Git está escrito en C. Muchas órdenes de Git están
504 implementadas como scripts de shell o Perl y la calidad de esos
505 scripts varía ampliamente. He encontrado muchas situaciones en las
506 cuales los scripts no tuvieron en cuenta la presencia de errores que
507 podrían haber sido fatales.
509 Mercurial puede importar el historial de revisiones de un repositorio
510 de Git.
512 \subsection{CVS}
514 CVS es probablemente la herramienta de control de revisiones más
515 ampliamente usada en el planeta. Debido a su edad y su poca pulcritud
516 nterna, ha sido ligeramente mantenido en muchos años.
518 Tiene una arquitectura centralizada cliente/servidor. No agrupa
519 cambios relacionadso en consignaciones atómicas, pemitiendo que con
520 facilidad la gente ``rompa la construcción'': una persona puede
521 consignar exitósamente parte del cambio y estar bloqueada por la
522 necesidad de una mezcla, forzando a otras personas a ver solamente una
523 porción del trabajo que estaban buscando hacer. Esto afecta también
524 la forma como usted trabaja con la historia del proyecto. Si quiere
525 ver todas las modificaciones que alguien hizo como parte de una tarea,
526 necesitará inspeccionar manualmente las descripciones y las marcas de
527 tiempo de cambio de cada fichero involucrado(esto, si usted saber
528 cuáles eran tales ficheros).
530 CVS tiene una noción confusa de etiquetas y ramas que yo no trataría
531 incluso de describir. No soporta renombramiento de ficheros o
532 directorios de buena forma, facilitando el corromper un
533 repositorio. Casi no tiene chequeo de consistencia interna, por lo
534 tanto es casi imposible identificar por que o cómo se corrompió un
535 repositorio. Yo no recomendaría un repositorio de CVS para proyecto
536 alguno, ni existente ni nuevo.
538 Mercurial puede importar la historia de revisiones de CVS. De todas
539 maneras hay ciertos trucos para aplicar; los cuales también son
540 necesarios para cualquier herramienta importadora de historial de
541 CVS. Debido a la falta de atomicidad de cambios y el no versionamiento
542 de la jerarquía del sistema de archivos, es imposible reconstruir la
543 completamente la historia de CVS acertadamente; hay cierto trabajo de
544 conjetura involucrado y los renombramientos tampoco se
545 mostrarán. Debido a que gran parte de la administración avanzada de
546 CVS tiene que hacerse manualmente y por lo tanto es proclive al error,
547 es común que los importadores de CVS encuentren muchos problemas con
548 repositorios corruptos( marcas de tiempo totalmente desubicadas y
549 archivos que han permanecido con candados por más de una década son
550 dos de los problemas más interesantes de los que puedo retomar de mi
551 experiencia personal).
553 Mercurial puede importar la historia de revisiones de un repositorio
554 CVS.
556 \subsection{Herramientas comerciales}
558 Perforce tiene una arquitectura centralizada cliente/servidor sin
559 almacenamiento de dato alguno en el lado del cliente. A diferencia de
560 las herramientas modernas de control de revisiones, Perforce requiere
561 que un usuario ejecute una orden para informar al servidor acerca de
562 todo fichero que se vaya a editar.
564 El rendimiento de Perforce es muy bueno para equipos pequeños, pero se
565 degrada rápidamente cuando el número de usuarios va más allá de pocas
566 docenas. Instalaciones modestamente grandes de Perforce requiere la
567 organización de proxies para soportar la carga que sus usuarios generan.
569 \subsection{Elegir una herramienta de control de revisiones}
571 Con la excepción de CVS, toda las herramientas que se han listado
572 anteriormente tienen fortalezas que los hacen valiosos de acuerdo al
573 tipo de trabajo. No hay una única herramienta de control de revisiones
574 que sea la mejor en todas las situaciones.
576 Por ejemplo, Subversion es una buena elección para trabajar con
577 edición frecuente de ficheros binarios, debido a su naturaleza
578 centralizada y soporte para poner candados a ficheros.
580 Personalmente encuentro las propiedades de simplicidad, desempeño, y
581 buen soporte de fusiones de Mercurial una combinación llamativa que ha
582 dado buenos frutos por varios años.
585 \section{Migrar de otra herramienta hacia Mercurial}
587 Mercurial viene con una extensión llamada \hgext{convert}, que puede
588 importar historiales de revisiones de forma incremental desde varias
589 herramientas de control de revisiones. Por ``incremental'', quiero
590 decir que puede migrar toda la historia de un proyecto en una primera
591 instancia y después volver a ejecutar la migración posteriormente para
592 obtener los nuevos cambios que han sucedido después de la migración
593 inicial.
595 A continuación presentamos las herramientas de revisiones que la
596 orden\hgext{convert} soporta:
597 \begin{itemize}
598 \item Subversion
599 \item CVS
600 \item Git
601 \item Darcs
602 \end{itemize}
604 Adicionalmente, \hgext{convert} puede exportar cambios de Mercurial
605 hacia Subversion. Lo que hace posible probar Subversion y Mercurial
606 en paralelo antes de lanzarse a un migración total, sin arriesgarse a
607 perder trabajo alguno.
609 La orden \hgxcmd{conver}{convert} es sencilla de usar. Basta con
610 apuntarla hacia la ruta o el URL del repositorio fuente, opcionalmente
611 darle el nombre del nombre del repositorio destino y comenzará a hacer
612 su trabajo. Después de la conversión inicial, basta con invocar de
613 nuevo la orden para importar nuevos cambios.
616 %%% Local Variables:
617 %%% mode: latex
618 %%% TeX-master: "00book"
619 %%% End: