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