Mercurial > hgbook
comparison es/intro.tex @ 642:51b5d56744c5
Merge Spanish version
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Thu, 29 Jan 2009 22:00:07 -0800 |
parents | 7e8ef188c72f |
children |
comparison
equal
deleted
inserted
replaced
421:73b094b764ec | 642:51b5d56744c5 |
---|---|
1 \chapter{Introducción} | |
2 \label{chap:intro} | |
3 | |
4 \section{Acerca del control de revisiones} | |
5 | |
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. | |
11 | |
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. | |
23 | |
24 \subsection{¿Por qué usar control de revisiones?} | |
25 | |
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. | |
49 | |
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. | |
55 | |
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. | |
61 | |
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í? | |
66 | |
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. | |
77 | |
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. | |
82 | |
83 \subsection{La cantidad de nombres del control de revisiones} | |
84 | |
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. | |
99 | |
100 \section{Historia resumida del control de revisiones} | |
101 | |
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. | |
113 | |
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. | |
120 | |
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. | |
132 | |
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. | |
144 | |
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.) | |
152 | |
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. | |
161 | |
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. | |
170 | |
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. | |
179 | |
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. | |
184 | |
185 \section{Tendencias en el control de revisiones} | |
186 | |
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. | |
191 | |
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. | |
197 | |
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. | |
210 | |
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. | |
220 | |
221 \section{Algunas ventajas del control distribuido de revisiones} | |
222 | |
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. | |
230 | |
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. | |
241 | |
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. | |
249 | |
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. | |
259 | |
260 \subsection{Ventajas para proyectos de código abierto} | |
261 | |
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. | |
274 | |
275 \subsubsection{Las bifurcaciones (forks) no son un problema} | |
276 | |
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. | |
285 | |
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. | |
293 | |
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. | |
301 | |
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} | |
316 | |
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. | |
326 | |
327 \subsection{Ventajas para proyectos comerciales} | |
328 | |
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. | |
339 | |
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. | |
350 | |
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. | |
358 | |
359 \section{¿Por qué elegir Mercurial?} | |
360 | |
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} | |
370 | |
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. | |
377 | |
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. | |
384 | |
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 | |
389 | |
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. | |
396 | |
397 \section{Comparación de Mercurial con otras herramientas} | |
398 | |
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. | |
404 | |
405 | |
406 \subsection{Subversion} | |
407 | |
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. | |
411 | |
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. | |
416 | |
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}}. | |
422 | |
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. | |
434 | |
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. | |
444 | |
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. | |
450 | |
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. | |
459 | |
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. | |
466 | |
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. | |
474 | |
475 \subsection{Git} | |
476 | |
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. | |
481 | |
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. | |
486 | |
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. | |
493 | |
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. | |
504 | |
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. | |
510 | |
511 Mercurial puede importar el historial de revisiones de un repositorio | |
512 de Git. | |
513 | |
514 \subsection{CVS} | |
515 | |
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. | |
519 | |
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). | |
531 | |
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. | |
539 | |
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). | |
554 | |
555 Mercurial puede importar el historial de revisiones de un repositorio | |
556 CVS. | |
557 | |
558 \subsection{Herramientas comerciales} | |
559 | |
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. | |
565 | |
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. | |
570 | |
571 \subsection{Elegir una herramienta de control de revisiones} | |
572 | |
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. | |
577 | |
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. | |
581 | |
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. | |
585 | |
586 | |
587 \section{Migrar de otra herramienta hacia Mercurial} | |
588 | |
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. | |
596 | |
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} | |
605 | |
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. | |
610 | |
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. | |
616 | |
617 | |
618 %%% Local Variables: | |
619 %%% mode: latex | |
620 %%% TeX-master: "00book" | |
621 %%% End: |