hgbook
view es/intro.tex @ 403:4cdeb830118b
Starting translating intro to spanish
| author | Igor TAmara <igor@tamarapatino.org> |
|---|---|
| date | Sat Nov 08 19:31:13 2008 -0500 (2008-11-08) |
| parents | b05e35d641e4 |
| children | 1839fd383e50 |
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 In the early 1990s, Sun Microsystems developed an early distributed
145 revision control system, called TeamWare. A TeamWare workspace
146 contains a complete copy of the project's history. TeamWare has no
147 notion of a central repository. (CVS relied upon RCS for its history
148 storage; TeamWare used SCCS.)
150 As the 1990s progressed, awareness grew of a number of problems with
151 CVS. It records simultaneous changes to multiple files individually,
152 instead of grouping them together as a single logically atomic
153 operation. It does not manage its file hierarchy well; it is easy to
154 make a mess of a repository by renaming files and directories. Worse,
155 its source code is difficult to read and maintain, which made the
156 ``pain level'' of fixing these architectural problems prohibitive.
158 In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
159 CVS, started a project to replace it with a tool that would have a
160 better architecture and cleaner code. The result, Subversion, does
161 not stray from CVS's centralised client/server model, but it adds
162 multi-file atomic commits, better namespace management, and a number
163 of other features that make it a generally better tool than CVS.
164 Since its initial release, it has rapidly grown in popularity.
166 More or less simultaneously, Graydon Hoare began working on an
167 ambitious distributed revision control system that he named Monotone.
168 While Monotone addresses many of CVS's design flaws and has a
169 peer-to-peer architecture, it goes beyond earlier (and subsequent)
170 revision control tools in a number of innovative ways. It uses
171 cryptographic hashes as identifiers, and has an integral notion of
172 ``trust'' for code from different sources.
174 Mercurial began life in 2005. While a few aspects of its design are
175 influenced by Monotone, Mercurial focuses on ease of use, high
176 performance, and scalability to very large projects.
178 \section{Trends in revision control}
180 There has been an unmistakable trend in the development and use of
181 revision control tools over the past four decades, as people have
182 become familiar with the capabilities of their tools and constrained
183 by their limitations.
185 The first generation began by managing single files on individual
186 computers. Although these tools represented a huge advance over
187 ad-hoc manual revision control, their locking model and reliance on a
188 single computer limited them to small, tightly-knit teams.
190 The second generation loosened these constraints by moving to
191 network-centered architectures, and managing entire projects at a
192 time. As projects grew larger, they ran into new problems. With
193 clients needing to talk to servers very frequently, server scaling
194 became an issue for large projects. An unreliable network connection
195 could prevent remote users from being able to talk to the server at
196 all. As open source projects started making read-only access
197 available anonymously to anyone, people without commit privileges
198 found that they could not use the tools to interact with a project in
199 a natural way, as they could not record their changes.
201 The current generation of revision control tools is peer-to-peer in
202 nature. All of these systems have dropped the dependency on a single
203 central server, and allow people to distribute their revision control
204 data to where it's actually needed. Collaboration over the Internet
205 has moved from constrained by technology to a matter of choice and
206 consensus. Modern tools can operate offline indefinitely and
207 autonomously, with a network connection only needed when syncing
208 changes with another repository.
210 \section{A few of the advantages of distributed revision control}
212 Even though distributed revision control tools have for several years
213 been as robust and usable as their previous-generation counterparts,
214 people using older tools have not yet necessarily woken up to their
215 advantages. There are a number of ways in which distributed tools
216 shine relative to centralised ones.
218 For an individual developer, distributed tools are almost always much
219 faster than centralised tools. This is for a simple reason: a
220 centralised tool needs to talk over the network for many common
221 operations, because most metadata is stored in a single copy on the
222 central server. A distributed tool stores all of its metadata
223 locally. All else being equal, talking over the network adds overhead
224 to a centralised tool. Don't underestimate the value of a snappy,
225 responsive tool: you're going to spend a lot of time interacting with
226 your revision control software.
228 Distributed tools are indifferent to the vagaries of your server
229 infrastructure, again because they replicate metadata to so many
230 locations. If you use a centralised system and your server catches
231 fire, you'd better hope that your backup media are reliable, and that
232 your last backup was recent and actually worked. With a distributed
233 tool, you have many backups available on every contributor's computer.
235 The reliability of your network will affect distributed tools far less
236 than it will centralised tools. You can't even use a centralised tool
237 without a network connection, except for a few highly constrained
238 commands. With a distributed tool, if your network connection goes
239 down while you're working, you may not even notice. The only thing
240 you won't be able to do is talk to repositories on other computers,
241 something that is relatively rare compared with local operations. If
242 you have a far-flung team of collaborators, this may be significant.
244 \subsection{Advantages for open source projects}
246 If you take a shine to an open source project and decide that you
247 would like to start hacking on it, and that project uses a distributed
248 revision control tool, you are at once a peer with the people who
249 consider themselves the ``core'' of that project. If they publish
250 their repositories, you can immediately copy their project history,
251 start making changes, and record your work, using the same tools in
252 the same ways as insiders. By contrast, with a centralised tool, you
253 must use the software in a ``read only'' mode unless someone grants
254 you permission to commit changes to their central server. Until then,
255 you won't be able to record changes, and your local modifications will
256 be at risk of corruption any time you try to update your client's view
257 of the repository.
259 \subsubsection{The forking non-problem}
261 It has been suggested that distributed revision control tools pose
262 some sort of risk to open source projects because they make it easy to
263 ``fork'' the development of a project. A fork happens when there are
264 differences in opinion or attitude between groups of developers that
265 cause them to decide that they can't work together any longer. Each
266 side takes a more or less complete copy of the project's source code,
267 and goes off in its own direction.
269 Sometimes the camps in a fork decide to reconcile their differences.
270 With a centralised revision control system, the \emph{technical}
271 process of reconciliation is painful, and has to be performed largely
272 by hand. You have to decide whose revision history is going to
273 ``win'', and graft the other team's changes into the tree somehow.
274 This usually loses some or all of one side's revision history.
276 What distributed tools do with respect to forking is they make forking
277 the \emph{only} way to develop a project. Every single change that
278 you make is potentially a fork point. The great strength of this
279 approach is that a distributed revision control tool has to be really
280 good at \emph{merging} forks, because forks are absolutely
281 fundamental: they happen all the time.
283 If every piece of work that everybody does, all the time, is framed in
284 terms of forking and merging, then what the open source world refers
285 to as a ``fork'' becomes \emph{purely} a social issue. If anything,
286 distributed tools \emph{lower} the likelihood of a fork:
287 \begin{itemize}
288 \item They eliminate the social distinction that centralised tools
289 impose: that between insiders (people with commit access) and
290 outsiders (people without).
291 \item They make it easier to reconcile after a social fork, because
292 all that's involved from the perspective of the revision control
293 software is just another merge.
294 \end{itemize}
296 Some people resist distributed tools because they want to retain tight
297 control over their projects, and they believe that centralised tools
298 give them this control. However, if you're of this belief, and you
299 publish your CVS or Subversion repositories publically, there are
300 plenty of tools available that can pull out your entire project's
301 history (albeit slowly) and recreate it somewhere that you don't
302 control. So while your control in this case is illusory, you are
303 forgoing the ability to fluidly collaborate with whatever people feel
304 compelled to mirror and fork your history.
306 \subsection{Advantages for commercial projects}
308 Many commercial projects are undertaken by teams that are scattered
309 across the globe. Contributors who are far from a central server will
310 see slower command execution and perhaps less reliability. Commercial
311 revision control systems attempt to ameliorate these problems with
312 remote-site replication add-ons that are typically expensive to buy
313 and cantankerous to administer. A distributed system doesn't suffer
314 from these problems in the first place. Better yet, you can easily
315 set up multiple authoritative servers, say one per site, so that
316 there's no redundant communication between repositories over expensive
317 long-haul network links.
319 Centralised revision control systems tend to have relatively low
320 scalability. It's not unusual for an expensive centralised system to
321 fall over under the combined load of just a few dozen concurrent
322 users. Once again, the typical response tends to be an expensive and
323 clunky replication facility. Since the load on a central server---if
324 you have one at all---is many times lower with a distributed
325 tool (because all of the data is replicated everywhere), a single
326 cheap server can handle the needs of a much larger team, and
327 replication to balance load becomes a simple matter of scripting.
329 If you have an employee in the field, troubleshooting a problem at a
330 customer's site, they'll benefit from distributed revision control.
331 The tool will let them generate custom builds, try different fixes in
332 isolation from each other, and search efficiently through history for
333 the sources of bugs and regressions in the customer's environment, all
334 without needing to connect to your company's network.
336 \section{Why choose Mercurial?}
338 Mercurial has a unique set of properties that make it a particularly
339 good choice as a revision control system.
340 \begin{itemize}
341 \item It is easy to learn and use.
342 \item It is lightweight.
343 \item It scales excellently.
344 \item It is easy to customise.
345 \end{itemize}
347 If you are at all familiar with revision control systems, you should
348 be able to get up and running with Mercurial in less than five
349 minutes. Even if not, it will take no more than a few minutes
350 longer. Mercurial's command and feature sets are generally uniform
351 and consistent, so you can keep track of a few general rules instead
352 of a host of exceptions.
354 On a small project, you can start working with Mercurial in moments.
355 Creating new changes and branches; transferring changes around
356 (whether locally or over a network); and history and status operations
357 are all fast. Mercurial attempts to stay nimble and largely out of
358 your way by combining low cognitive overhead with blazingly fast
359 operations.
361 The usefulness of Mercurial is not limited to small projects: it is
362 used by projects with hundreds to thousands of contributors, each
363 containing tens of thousands of files and hundreds of megabytes of
364 source code.
366 If the core functionality of Mercurial is not enough for you, it's
367 easy to build on. Mercurial is well suited to scripting tasks, and
368 its clean internals and implementation in Python make it easy to add
369 features in the form of extensions. There are a number of popular and
370 useful extensions already available, ranging from helping to identify
371 bugs to improving performance.
373 \section{Mercurial compared with other tools}
375 Before you read on, please understand that this section necessarily
376 reflects my own experiences, interests, and (dare I say it) biases. I
377 have used every one of the revision control tools listed below, in
378 most cases for several years at a time.
381 \subsection{Subversion}
383 Subversion is a popular revision control tool, developed to replace
384 CVS. It has a centralised client/server architecture.
386 Subversion and Mercurial have similarly named commands for performing
387 the same operations, so if you're familiar with one, it is easy to
388 learn to use the other. Both tools are portable to all popular
389 operating systems.
391 Prior to version 1.5, Subversion had no useful support for merges.
392 At the time of writing, its merge tracking capability is new, and known to be
393 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicated
394 and buggy}.
396 Mercurial has a substantial performance advantage over Subversion on
397 every revision control operation I have benchmarked. I have measured
398 its advantage as ranging from a factor of two to a factor of six when
399 compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
400 the fastest access method available. In more realistic deployments
401 involving a network-based store, Subversion will be at a substantially
402 larger disadvantage. Because many Subversion commands must talk to
403 the server and Subversion does not have useful replication facilities,
404 server capacity and network bandwidth become bottlenecks for modestly
405 large projects.
407 Additionally, Subversion incurs substantial storage overhead to avoid
408 network transactions for a few common operations, such as finding
409 modified files (\texttt{status}) and displaying modifications against
410 the current revision (\texttt{diff}). As a result, a Subversion
411 working copy is often the same size as, or larger than, a Mercurial
412 repository and working directory, even though the Mercurial repository
413 contains a complete history of the project.
415 Subversion is widely supported by third party tools. Mercurial
416 currently lags considerably in this area. This gap is closing,
417 however, and indeed some of Mercurial's GUI tools now outshine their
418 Subversion equivalents. Like Mercurial, Subversion has an excellent
419 user manual.
421 Because Subversion doesn't store revision history on the client, it is
422 well suited to managing projects that deal with lots of large, opaque
423 binary files. If you check in fifty revisions to an incompressible
424 10MB file, Subversion's client-side space usage stays constant The
425 space used by any distributed SCM will grow rapidly in proportion to
426 the number of revisions, because the differences between each revision
427 are large.
429 In addition, it's often difficult or, more usually, impossible to
430 merge different versions of a binary file. Subversion's ability to
431 let a user lock a file, so that they temporarily have the exclusive
432 right to commit changes to it, can be a significant advantage to a
433 project where binary files are widely used.
435 Mercurial can import revision history from a Subversion repository.
436 It can also export revision history to a Subversion repository. This
437 makes it easy to ``test the waters'' and use Mercurial and Subversion
438 in parallel before deciding to switch. History conversion is
439 incremental, so you can perform an initial conversion, then small
440 additional conversions afterwards to bring in new changes.
443 \subsection{Git}
445 Git is a distributed revision control tool that was developed for
446 managing the Linux kernel source tree. Like Mercurial, its early
447 design was somewhat influenced by Monotone.
449 Git has a very large command set, with version~1.5.0 providing~139
450 individual commands. It has something of a reputation for being
451 difficult to learn. Compared to Git, Mercurial has a strong focus on
452 simplicity.
454 In terms of performance, Git is extremely fast. In several cases, it
455 is faster than Mercurial, at least on Linux, while Mercurial performs
456 better on other operations. However, on Windows, the performance and
457 general level of support that Git provides is, at the time of writing,
458 far behind that of Mercurial.
460 While a Mercurial repository needs no maintenance, a Git repository
461 requires frequent manual ``repacks'' of its metadata. Without these,
462 performance degrades, while space usage grows rapidly. A server that
463 contains many Git repositories that are not rigorously and frequently
464 repacked will become heavily disk-bound during backups, and there have
465 been instances of daily backups taking far longer than~24 hours as a
466 result. A freshly packed Git repository is slightly smaller than a
467 Mercurial repository, but an unpacked repository is several orders of
468 magnitude larger.
470 The core of Git is written in C. Many Git commands are implemented as
471 shell or Perl scripts, and the quality of these scripts varies widely.
472 I have encountered several instances where scripts charged along
473 blindly in the presence of errors that should have been fatal.
475 Mercurial can import revision history from a Git repository.
478 \subsection{CVS}
480 CVS is probably the most widely used revision control tool in the
481 world. Due to its age and internal untidiness, it has been only
482 lightly maintained for many years.
484 It has a centralised client/server architecture. It does not group
485 related file changes into atomic commits, making it easy for people to
486 ``break the build'': one person can successfully commit part of a
487 change and then be blocked by the need for a merge, causing other
488 people to see only a portion of the work they intended to do. This
489 also affects how you work with project history. If you want to see
490 all of the modifications someone made as part of a task, you will need
491 to manually inspect the descriptions and timestamps of the changes
492 made to each file involved (if you even know what those files were).
494 CVS has a muddled notion of tags and branches that I will not attempt
495 to even describe. It does not support renaming of files or
496 directories well, making it easy to corrupt a repository. It has
497 almost no internal consistency checking capabilities, so it is usually
498 not even possible to tell whether or how a repository is corrupt. I
499 would not recommend CVS for any project, existing or new.
501 Mercurial can import CVS revision history. However, there are a few
502 caveats that apply; these are true of every other revision control
503 tool's CVS importer, too. Due to CVS's lack of atomic changes and
504 unversioned filesystem hierarchy, it is not possible to reconstruct
505 CVS history completely accurately; some guesswork is involved, and
506 renames will usually not show up. Because a lot of advanced CVS
507 administration has to be done by hand and is hence error-prone, it's
508 common for CVS importers to run into multiple problems with corrupted
509 repositories (completely bogus revision timestamps and files that have
510 remained locked for over a decade are just two of the less interesting
511 problems I can recall from personal experience).
513 Mercurial can import revision history from a CVS repository.
516 \subsection{Commercial tools}
518 Perforce has a centralised client/server architecture, with no
519 client-side caching of any data. Unlike modern revision control
520 tools, Perforce requires that a user run a command to inform the
521 server about every file they intend to edit.
523 The performance of Perforce is quite good for small teams, but it
524 falls off rapidly as the number of users grows beyond a few dozen.
525 Modestly large Perforce installations require the deployment of
526 proxies to cope with the load their users generate.
529 \subsection{Choosing a revision control tool}
531 With the exception of CVS, all of the tools listed above have unique
532 strengths that suit them to particular styles of work. There is no
533 single revision control tool that is best in all situations.
535 As an example, Subversion is a good choice for working with frequently
536 edited binary files, due to its centralised nature and support for
537 file locking.
539 I personally find Mercurial's properties of simplicity, performance,
540 and good merge support to be a compelling combination that has served
541 me well for several years.
544 \section{Switching from another tool to Mercurial}
546 Mercurial is bundled with an extension named \hgext{convert}, which
547 can incrementally import revision history from several other revision
548 control tools. By ``incremental'', I mean that you can convert all of
549 a project's history to date in one go, then rerun the conversion later
550 to obtain new changes that happened after the initial conversion.
552 The revision control tools supported by \hgext{convert} are as
553 follows:
554 \begin{itemize}
555 \item Subversion
556 \item CVS
557 \item Git
558 \item Darcs
559 \end{itemize}
561 In addition, \hgext{convert} can export changes from Mercurial to
562 Subversion. This makes it possible to try Subversion and Mercurial in
563 parallel before committing to a switchover, without risking the loss
564 of any work.
566 The \hgxcmd{conver}{convert} command is easy to use. Simply point it
567 at the path or URL of the source repository, optionally give it the
568 name of the destination repository, and it will start working. After
569 the initial conversion, just run the same command again to import new
570 changes.
573 %%% Local Variables:
574 %%% mode: latex
575 %%% TeX-master: "00book"
576 %%% End: