hgbook
view es/intro.tex @ 404:1839fd383e50
translated a few subsections of intro
| author | Igor TAmara <igor@tamarapatino.org> |
|---|---|
| date | Sat Nov 08 21:47:35 2008 -0500 (2008-11-08) |
| parents | 4cdeb830118b |
| children | 779944196e2a |
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 archivos 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 validas ---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 cueant, puesto que \emph{sin} él,
60 el fracaso está casi garantizado.
62 Por otra parte, un ``arreglo rápido'' de una sola persona, excluiría
63 la necesidad de usar una herramienta de control de revisiones, porque
64 casi seguramente, el costo de usar una estaría cerca del costo del
65 proyecto. ¿No es así?
67 Mercurial solamente soporta \emph{ambas} escalas de de
68 desarrollo. 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 naturaleza peer-to-peer le permite escalar indoloramente para manejar
75 grandes proyectos.
77 Ninguna herramienta de control de revisiones puede salvar un
78 proyecto mal administrado, pero la elección de herramientas puede
79 hacer una gran diferencia en la fluidez con la cual puede trabajar en
80 el proyecto.
82 \subsection{La cantidad de nombres del control de revisiones}
84 El control de revisiones es un campo amplio, tan ampli que no hay un
85 acrónimo o nombre único. A continuación presentamos un listado de
86 nombres comunes y acrónimos que se podrían encontrar:
87 \begin{itemize}
88 \item Control de revisiones (RCS)
89 \item Manejo de Configuraciones de Programas(SCM), o administracón de
90 configuraciones
91 \item Administración de código fuente
92 \item Control de Código Fuente, o Control de Fuentes
93 \item Control de Versiones(VCS)
94 \end{itemize}
95 Algunas personas aducen que estos términos tienen significados
96 diversos, pero en la práctica se sobrelapan tanto que no hay un
97 acuerdo o una forma adecuada de separarlos.
99 \section{Historia resumida del control de revisiones}
101 La herramienta de control de revisiones más antigua conocida es SCCS
102 (Sistema de Control de Código), escrito por Marc Rochkind en Bell
103 Labs, a comienzos de los setentas(1970s). SCCS operaba sobre archivos
104 individuales, y requería que cada persona que trabajara en el proyecto
105 tuviera acceso a un espacio compartido en un solo sistema. Solamente
106 una persona podía modificar un archivo en un momento dado; el
107 arbitramiento del acceso a los ficheros se hacía con candados. Era
108 común que la gente pusiera los candados a los ficheros, y que
109 posteriormente olvidara quitarlos, impidiendo que otro pudiera
110 modificar los ficheros en cuestión sin la intervención del
111 administrador.
113 Walter Tichy desarrolló una alternativa gratutita a SCCS a comienzos
114 de los ochentas(1980s), llamó a su programa RCS(Sistema de Control de
115 Revisiones). Al igual que SCCS, RCS requería que los desarrolladores
116 trabajaran en un único espacio compartido y colocaran candados a los
117 ficheros para evitar que varias personas los estuvieran modificando
118 simultáneamente.
120 Después en los ochenta, Dick Grune usó RCS como un bloque de
121 construcción para un conjunto de guiones de línea de comando, que
122 inicialmente llamó cmt, pero que renombró a CVS(Sistema Concurrente de
123 Versiones). La gran innovación de CVS era que permitía a los
124 desarrolladores trabajar simultáneamente de una forma más o menos
125 independiente en sus propios espacios de trabajo. Los espacios de
126 trabajo personales impedian que los desarrolladores se pisaran las
127 mangueras todo el tiempo, situación común con SCCS y RCS. Cada
128 desarrollador tenía una copia de todo el fichero del proyecto y podía
129 modificar su copia independientemente, Tenían que fusionar sus
130 ediciones antes de consignar los cambios al repositorio central.
132 Brian Berliner tomó los scripts originales de Grune y los reescribió
133 en~C, haciéndolos públicos en 1989, código sobre el cual se ha
134 desarrollado la versión moderna de CVS. CVS posteriormente adquirió
135 la habilidad de operar sobre una conexión de red, dotándolo de una
136 arquitectura, cliente/servidor. La arquitectura de CVS es
137 centralizada; La historia del proyecto está únicamente en el
138 repositorio central. Los espacios de trabajo de los clientes
139 contienen únicamente copias recientes de las versiones de los
140 ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
141 ha tenido un éxito enorme; Es probablemente el sistema de control de
142 revisiones más extendido del planeta.
144 A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
145 temprano sistema distribuido de revisión de controles llamado TeamWare
146 Un espacio de trabajo TeamWare contiene una copia completa de la
147 historia del proyecto. TeamWare no tiene la noción de repositorio
148 central. (CVS se basaba en RCS para el almacenamiento de su historia;
149 TeamWare usaba SCCS.)
151 A medida que avanzaba la decada de los noventa, se empezño a
152 evidenciar los problemas de CVS. Alacena cambios simultáneos a muchos
153 archivos de forma individual, en lugar de agruparlos como una
154 operación única y atómica lógicamente. No maneja bien su jerarquía de
155 ficheros bien; es fácil desordenar un repositorio renombrando ficheros
156 y directorios. Peor aún, su código fuente es difícil de leer y
157 mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
158 problemas arquitecturales algo prohibitivo.
160 En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
161 trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
162 herramienta con mejor arquitectura y código más limpio. El resultado,
163 Subversion, no se separó del modelo centralizado cliente/servidor de
164 CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
165 manejo de nombres de espacios, y otras características que lo hacen
166 mejor que CVS. Desde su versión inicial, ha ido creciendo en
167 popularidad.
169 Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
170 sistema distribuido de control de versiones ambicioso que llamó
171 Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
172 diseño de CVS con una arquitectura peer-to-peer, fue mucho más
173 allá(junto con otros proyectos subsecuentes) que unas herramientas de
174 control de revisiones en varios aspectos innovadores. Usa hashes
175 criptográficos como identificadores, y tiene una noción integral de
176 ``confianza'' para código de diversas fuentes.
178 Mercurial nació en el 2005. Algunos de sus aspectos de de diseño
179 fueron influenciados por Monotone, pero Mercurial se enfoca en la
180 facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
181 grandes.
183 \section{Tendencias en el control de revisiones}
185 Ha habido varias tendencias en el desarrollo y uso de las herramientas
186 de control de revisiones en las pasadas cuatro décadas, mientras la
187 gente se ha vuelto familiar con las capacidades de sus herramientas
188 así mismo con sus limitaciones.
190 La primera generación comenzó administrando archivos individuales en
191 computadores por persona. A pesar de que tales herramientas
192 representaron un avance importante frente al control de revisiones
193 manual, su modelo de candados y la limitación a un sólo computador,
194 determinó equipos de trabajo pequeños y acoplados.
196 La segunda generación dejó atrás esas limitaciones moviéndose a
197 arquitecturas centradas en redes, y administrando proyectos completos
198 uno a la vez. A medida que los proyectos crecían, nacieron nuevos
199 problemas. Con la necesidad de comunicación frecuente con los
200 servidores, escalar estas máquinas se convirtió en un problema en
201 proyectos realmente grandes. Las redes con poca estabilidad impidieron
202 que usuarios remotos se conectaran al servidor. A medida que los
203 proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
204 de forma anónima a cualquiera, la gente sin permiso para consignar,
205 vio que no podían usar tales herramientas para interactuar en un
206 proyecto de forma natural, puesto que no podían guardar sus cambios.
208 La generación actual de herramientas de control de revisiones es de
209 forma natural peer-to-peer. Todos estos sistemas han eliminado la
210 dependencia de un único servidor central, y han permitido que la
211 gente distribuya sus datos de control de revisiones donde realmente se
212 necesita. La colaboración a través de Internet ha cambiado las
213 limitantes tecnológicas a la cuestión de elección y consenso. Las
214 herramientas modernas pueden operar sin conexión indefinidamenta y
215 autónomamente, necesitando una conexión de red solamente para
216 sincronizar los cambios con otro repositorio.
218 \section{Algunas ventajas del control distribuido de revisiones}
220 A pesar de que las herramientas para el control distribuido de
221 revisiones lleva varios años siendo tan robusto y usable como la
222 generación previa de su contraparte, personas que usan herramientas
223 más antiguas no se han percatado de sus ventajas. Hay gran cantidad
224 de situaciones en las cuales las herramientas distribuidas brillan
225 frente a las centralizadas.
227 Para un desarrollador individual, las herramientas distribuidas casi
228 siempre son más rápidas que las centralizadas. Por una razón sencilla:
229 Una herramienta centralizada necesita comunicarse por red para las
230 operaciones más usuales, debido a que los metadatos se almacenan en
231 una sola copia en el servidor central. Una herramienta distribuida
232 almacena todos sus metadatos localmente. Con todo lo demás de la
233 misma forma, comunicarse por red tiene un sobrecosto en una
234 herramienta centralizada. No subestime el valor de una herramienta de
235 respuesta rápida: Usted empleará mucho tiempo interactuando con su
236 programa de control de revisiones.
238 Las herramientas distribuidas son indiferentes a los caprichos de su
239 infraestructura de servidores, de nuevo, debido a la replicación de
240 metadatos en tantos lugares. Si usa un sistema centralizado y su
241 servidor explota, ojalá los medios físicos de su copia de seguridad
242 sean confiables, y que su última copia sea reciente y además
243 funcione. Con una herramienta distribuida tiene tantas copias de
244 seguridad disponibles como computadores de contribuidores.
246 La confiabilidad de su red afectará las herramientas distribuidas de
247 una forma mucho menor que las herramientas centralizadas No puede
248 siquiera usar una herramienta centralizada sin conexión de red,
249 excepto con algunas órdenes muy limitadas. Con herramientas
250 distribuidas, si sus conexión cae mientras usted está trabajando,
251 podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
252 comunicarse con repositorios en otros computadores, algo que es
253 relativamente raro comparado con las operaciones locales. Si tiene
254 colaboradores remotos en su equipo, puede ser significante.
256 \subsection{Ventajas para proyectos de código abierto}
258 Si descubre un proyecto de código abierto y decide que desea comenzar
259 a trabajar en él, y ese proyecto usa una herramienta de control
260 distribuido de revisiones, usted es un par con la gente que se
261 considera el ``alma'' del proyecto. Si ellos publican los
262 repositorios, se puede copiar inmediatamente la historia del proyecto,
263 hacer cambios y guardar su trabajo, usando las mismas herramientas de
264 la misma forma que ellos. En contraste, con una herramienta
265 centralizada, debe usar el programa en un modo ``sólo lectura'' a
266 menos que alguien le otorgue permisos para consignar cambios en el
267 repositorio central. Hasta entonces, no podrá almacenar sus cambios y
268 sus modificaciones locales correrán el riesgo de dañarse cuando trate
269 de actualizar su vista del repositorio.
271 \subsubsection{Las bifurcaciones(forks) no son un problema}
273 Se ha mencionado que las herramientas de control distribuido de
274 versiones albergan un riesgo a los proyectos de código abierto, puesto
275 que se vuelve muy sencillo hacer una ``bifurcanción''\NdT{fork} del
276 desarrollo del proyecto. Una bifurcación pasa cuando hay diferencias
277 de opinión o actitud entre grupos de desarrolladores que desenvoca en
278 la decisión de la imposibilidad de continuar trabajando juntos. Cada
279 parte toma una copia más o menos completa del código fuente del
280 proyecto y toma su propio rumbo.
282 En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
283 diferencias. Con un sistema centralizado de control de revisiones, el
284 proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
285 forma muy manual. Tiene que decidir qué historia de revisiones va a
286 ``win'', e injertar los cambios del otro equipo en el árbol de alguna
287 manera. Con esto usualmente se pierde algo o todo del historial de la
288 revisión de alguna de las partes.
290 Lo que las herramientas distribuidas hacen con respecto a las
291 bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
292 desarrollar un proyecto. Cada cambio que usted hace es potencialmente
293 un punto de bifurcación. La gran fortaleza de esta aproximación es que
294 las herramientas distribuidas de control de revisiones tiene que ser
295 bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
296 son absolutamente fundamentales: pasan todo el tiempo.
298 Si todas las porciones de trabajo que todos hacen todo el tiempo, se
299 enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
300 lo que se refiere en el mundo del código abierto a una ``bifurcación''
301 se convierte \emph{puramente} en una cuestión social. Lo que hacen las
302 herramientas distribuidas es \emph{disminuir} la posibilidad de una
303 bifurcación porque:
304 \begin{itemize}
305 \item Eliminan la distinción social que las herramientas centralizadas
306 imponen: esto entre los miembros (personas con permiso de consignar)
307 y forasteros(los que no tienen el permiso).
308 \item Facilitan la reconciliación después de una bifurcación social,
309 porque todo lo que concierne al programa de control de revisiones es
310 una fusión.
311 \end{itemize}
313 Algunas personas se resisten a las herramientas distribuidas porque
314 desean mantener control completo sobre sus proyectos, y creen que las
315 herramientas centralizadas les dan tal control. En todo caso, si este
316 es su parecer, y publica sus repositorios de CVS o Subversion, hay
317 muchas herramientas disponibles que pueden obtener la historia
318 completa(A pesar de lo lento) y recrearla en otro sitio que usted no
319 controla. Siendo así un control ilusorio, está impidiendo la fluidez
320 de colaboración frente a quien se sienta impulsado a obtener una copia
321 y hacer una bifurcación con su historia.
323 \subsection{Advantages for commercial projects}
325 Many commercial projects are undertaken by teams that are scattered
326 across the globe. Contributors who are far from a central server will
327 see slower command execution and perhaps less reliability. Commercial
328 revision control systems attempt to ameliorate these problems with
329 remote-site replication add-ons that are typically expensive to buy
330 and cantankerous to administer. A distributed system doesn't suffer
331 from these problems in the first place. Better yet, you can easily
332 set up multiple authoritative servers, say one per site, so that
333 there's no redundant communication between repositories over expensive
334 long-haul network links.
336 Centralised revision control systems tend to have relatively low
337 scalability. It's not unusual for an expensive centralised system to
338 fall over under the combined load of just a few dozen concurrent
339 users. Once again, the typical response tends to be an expensive and
340 clunky replication facility. Since the load on a central server---if
341 you have one at all---is many times lower with a distributed
342 tool (because all of the data is replicated everywhere), a single
343 cheap server can handle the needs of a much larger team, and
344 replication to balance load becomes a simple matter of scripting.
346 If you have an employee in the field, troubleshooting a problem at a
347 customer's site, they'll benefit from distributed revision control.
348 The tool will let them generate custom builds, try different fixes in
349 isolation from each other, and search efficiently through history for
350 the sources of bugs and regressions in the customer's environment, all
351 without needing to connect to your company's network.
353 \section{Why choose Mercurial?}
355 Mercurial has a unique set of properties that make it a particularly
356 good choice as a revision control system.
357 \begin{itemize}
358 \item It is easy to learn and use.
359 \item It is lightweight.
360 \item It scales excellently.
361 \item It is easy to customise.
362 \end{itemize}
364 If you are at all familiar with revision control systems, you should
365 be able to get up and running with Mercurial in less than five
366 minutes. Even if not, it will take no more than a few minutes
367 longer. Mercurial's command and feature sets are generally uniform
368 and consistent, so you can keep track of a few general rules instead
369 of a host of exceptions.
371 On a small project, you can start working with Mercurial in moments.
372 Creating new changes and branches; transferring changes around
373 (whether locally or over a network); and history and status operations
374 are all fast. Mercurial attempts to stay nimble and largely out of
375 your way by combining low cognitive overhead with blazingly fast
376 operations.
378 The usefulness of Mercurial is not limited to small projects: it is
379 used by projects with hundreds to thousands of contributors, each
380 containing tens of thousands of files and hundreds of megabytes of
381 source code.
383 If the core functionality of Mercurial is not enough for you, it's
384 easy to build on. Mercurial is well suited to scripting tasks, and
385 its clean internals and implementation in Python make it easy to add
386 features in the form of extensions. There are a number of popular and
387 useful extensions already available, ranging from helping to identify
388 bugs to improving performance.
390 \section{Mercurial compared with other tools}
392 Before you read on, please understand that this section necessarily
393 reflects my own experiences, interests, and (dare I say it) biases. I
394 have used every one of the revision control tools listed below, in
395 most cases for several years at a time.
398 \subsection{Subversion}
400 Subversion is a popular revision control tool, developed to replace
401 CVS. It has a centralised client/server architecture.
403 Subversion and Mercurial have similarly named commands for performing
404 the same operations, so if you're familiar with one, it is easy to
405 learn to use the other. Both tools are portable to all popular
406 operating systems.
408 Prior to version 1.5, Subversion had no useful support for merges.
409 At the time of writing, its merge tracking capability is new, and known to be
410 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicated
411 and buggy}.
413 Mercurial has a substantial performance advantage over Subversion on
414 every revision control operation I have benchmarked. I have measured
415 its advantage as ranging from a factor of two to a factor of six when
416 compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
417 the fastest access method available. In more realistic deployments
418 involving a network-based store, Subversion will be at a substantially
419 larger disadvantage. Because many Subversion commands must talk to
420 the server and Subversion does not have useful replication facilities,
421 server capacity and network bandwidth become bottlenecks for modestly
422 large projects.
424 Additionally, Subversion incurs substantial storage overhead to avoid
425 network transactions for a few common operations, such as finding
426 modified files (\texttt{status}) and displaying modifications against
427 the current revision (\texttt{diff}). As a result, a Subversion
428 working copy is often the same size as, or larger than, a Mercurial
429 repository and working directory, even though the Mercurial repository
430 contains a complete history of the project.
432 Subversion is widely supported by third party tools. Mercurial
433 currently lags considerably in this area. This gap is closing,
434 however, and indeed some of Mercurial's GUI tools now outshine their
435 Subversion equivalents. Like Mercurial, Subversion has an excellent
436 user manual.
438 Because Subversion doesn't store revision history on the client, it is
439 well suited to managing projects that deal with lots of large, opaque
440 binary files. If you check in fifty revisions to an incompressible
441 10MB file, Subversion's client-side space usage stays constant The
442 space used by any distributed SCM will grow rapidly in proportion to
443 the number of revisions, because the differences between each revision
444 are large.
446 In addition, it's often difficult or, more usually, impossible to
447 merge different versions of a binary file. Subversion's ability to
448 let a user lock a file, so that they temporarily have the exclusive
449 right to commit changes to it, can be a significant advantage to a
450 project where binary files are widely used.
452 Mercurial can import revision history from a Subversion repository.
453 It can also export revision history to a Subversion repository. This
454 makes it easy to ``test the waters'' and use Mercurial and Subversion
455 in parallel before deciding to switch. History conversion is
456 incremental, so you can perform an initial conversion, then small
457 additional conversions afterwards to bring in new changes.
460 \subsection{Git}
462 Git is a distributed revision control tool that was developed for
463 managing the Linux kernel source tree. Like Mercurial, its early
464 design was somewhat influenced by Monotone.
466 Git has a very large command set, with version~1.5.0 providing~139
467 individual commands. It has something of a reputation for being
468 difficult to learn. Compared to Git, Mercurial has a strong focus on
469 simplicity.
471 In terms of performance, Git is extremely fast. In several cases, it
472 is faster than Mercurial, at least on Linux, while Mercurial performs
473 better on other operations. However, on Windows, the performance and
474 general level of support that Git provides is, at the time of writing,
475 far behind that of Mercurial.
477 While a Mercurial repository needs no maintenance, a Git repository
478 requires frequent manual ``repacks'' of its metadata. Without these,
479 performance degrades, while space usage grows rapidly. A server that
480 contains many Git repositories that are not rigorously and frequently
481 repacked will become heavily disk-bound during backups, and there have
482 been instances of daily backups taking far longer than~24 hours as a
483 result. A freshly packed Git repository is slightly smaller than a
484 Mercurial repository, but an unpacked repository is several orders of
485 magnitude larger.
487 The core of Git is written in C. Many Git commands are implemented as
488 shell or Perl scripts, and the quality of these scripts varies widely.
489 I have encountered several instances where scripts charged along
490 blindly in the presence of errors that should have been fatal.
492 Mercurial can import revision history from a Git repository.
495 \subsection{CVS}
497 CVS is probably the most widely used revision control tool in the
498 world. Due to its age and internal untidiness, it has been only
499 lightly maintained for many years.
501 It has a centralised client/server architecture. It does not group
502 related file changes into atomic commits, making it easy for people to
503 ``break the build'': one person can successfully commit part of a
504 change and then be blocked by the need for a merge, causing other
505 people to see only a portion of the work they intended to do. This
506 also affects how you work with project history. If you want to see
507 all of the modifications someone made as part of a task, you will need
508 to manually inspect the descriptions and timestamps of the changes
509 made to each file involved (if you even know what those files were).
511 CVS has a muddled notion of tags and branches that I will not attempt
512 to even describe. It does not support renaming of files or
513 directories well, making it easy to corrupt a repository. It has
514 almost no internal consistency checking capabilities, so it is usually
515 not even possible to tell whether or how a repository is corrupt. I
516 would not recommend CVS for any project, existing or new.
518 Mercurial can import CVS revision history. However, there are a few
519 caveats that apply; these are true of every other revision control
520 tool's CVS importer, too. Due to CVS's lack of atomic changes and
521 unversioned filesystem hierarchy, it is not possible to reconstruct
522 CVS history completely accurately; some guesswork is involved, and
523 renames will usually not show up. Because a lot of advanced CVS
524 administration has to be done by hand and is hence error-prone, it's
525 common for CVS importers to run into multiple problems with corrupted
526 repositories (completely bogus revision timestamps and files that have
527 remained locked for over a decade are just two of the less interesting
528 problems I can recall from personal experience).
530 Mercurial can import revision history from a CVS repository.
533 \subsection{Commercial tools}
535 Perforce has a centralised client/server architecture, with no
536 client-side caching of any data. Unlike modern revision control
537 tools, Perforce requires that a user run a command to inform the
538 server about every file they intend to edit.
540 The performance of Perforce is quite good for small teams, but it
541 falls off rapidly as the number of users grows beyond a few dozen.
542 Modestly large Perforce installations require the deployment of
543 proxies to cope with the load their users generate.
546 \subsection{Choosing a revision control tool}
548 With the exception of CVS, all of the tools listed above have unique
549 strengths that suit them to particular styles of work. There is no
550 single revision control tool that is best in all situations.
552 As an example, Subversion is a good choice for working with frequently
553 edited binary files, due to its centralised nature and support for
554 file locking.
556 I personally find Mercurial's properties of simplicity, performance,
557 and good merge support to be a compelling combination that has served
558 me well for several years.
561 \section{Switching from another tool to Mercurial}
563 Mercurial is bundled with an extension named \hgext{convert}, which
564 can incrementally import revision history from several other revision
565 control tools. By ``incremental'', I mean that you can convert all of
566 a project's history to date in one go, then rerun the conversion later
567 to obtain new changes that happened after the initial conversion.
569 The revision control tools supported by \hgext{convert} are as
570 follows:
571 \begin{itemize}
572 \item Subversion
573 \item CVS
574 \item Git
575 \item Darcs
576 \end{itemize}
578 In addition, \hgext{convert} can export changes from Mercurial to
579 Subversion. This makes it possible to try Subversion and Mercurial in
580 parallel before committing to a switchover, without risking the loss
581 of any work.
583 The \hgxcmd{conver}{convert} command is easy to use. Simply point it
584 at the path or URL of the source repository, optionally give it the
585 name of the destination repository, and it will start working. After
586 the initial conversion, just run the same command again to import new
587 changes.
590 %%% Local Variables:
591 %%% mode: latex
592 %%% TeX-master: "00book"
593 %%% End: