hgbook
view en/ch01-intro.xml @ 563:44d1363234d2
Move example output files into examples/results
| author | Bryan O'Sullivan <bos@serpentine.com> |
|---|---|
| date | Mon Mar 09 21:37:47 2009 -0700 (2009-03-09) |
| parents | 8631da51309b |
| children | 13513d2a128d |
line source
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
3 <chapter id="chap:intro">
4 <title>Introduction</title>
6 <sect1>
7 <title>About revision control</title>
9 <para>Revision control is the process of managing multiple
10 versions of a piece of information. In its simplest form, this
11 is something that many people do by hand: every time you modify
12 a file, save it under a new name that contains a number, each
13 one higher than the number of the preceding version.</para>
15 <para>Manually managing multiple versions of even a single file is
16 an error-prone task, though, so software tools to help automate
17 this process have long been available. The earliest automated
18 revision control tools were intended to help a single user to
19 manage revisions of a single file. Over the past few decades,
20 the scope of revision control tools has expanded greatly; they
21 now manage multiple files, and help multiple people to work
22 together. The best modern revision control tools have no
23 problem coping with thousands of people working together on
24 projects that consist of hundreds of thousands of files.</para>
26 <sect2>
27 <title>Why use revision control?</title>
29 <para>There are a number of reasons why you or your team might
30 want to use an automated revision control tool for a
31 project.</para>
32 <itemizedlist>
33 <listitem><para>It will track the history and evolution of
34 your project, so you don't have to. For every change,
35 you'll have a log of <emphasis>who</emphasis> made it;
36 <emphasis>why</emphasis> they made it;
37 <emphasis>when</emphasis> they made it; and
38 <emphasis>what</emphasis> the change
39 was.</para></listitem>
40 <listitem><para>When you're working with other people,
41 revision control software makes it easier for you to
42 collaborate. For example, when people more or less
43 simultaneously make potentially incompatible changes, the
44 software will help you to identify and resolve those
45 conflicts.</para></listitem>
46 <listitem><para>It can help you to recover from mistakes. If
47 you make a change that later turns out to be in error, you
48 can revert to an earlier version of one or more files. In
49 fact, a <emphasis>really</emphasis> good revision control
50 tool will even help you to efficiently figure out exactly
51 when a problem was introduced (see section <xref
52 linkend="sec:undo:bisect"/> for details).</para></listitem>
53 <listitem><para>It will help you to work simultaneously on,
54 and manage the drift between, multiple versions of your
55 project.</para></listitem></itemizedlist>
56 <para>Most of these reasons are equally valid---at least in
57 theory---whether you're working on a project by yourself, or
58 with a hundred other people.</para>
60 <para>A key question about the practicality of revision control
61 at these two different scales (<quote>lone hacker</quote> and
62 <quote>huge team</quote>) is how its
63 <emphasis>benefits</emphasis> compare to its
64 <emphasis>costs</emphasis>. A revision control tool that's
65 difficult to understand or use is going to impose a high
66 cost.</para>
68 <para>A five-hundred-person project is likely to collapse under
69 its own weight almost immediately without a revision control
70 tool and process. In this case, the cost of using revision
71 control might hardly seem worth considering, since
72 <emphasis>without</emphasis> it, failure is almost
73 guaranteed.</para>
75 <para>On the other hand, a one-person <quote>quick hack</quote>
76 might seem like a poor place to use a revision control tool,
77 because surely the cost of using one must be close to the
78 overall cost of the project. Right?</para>
80 <para>Mercurial uniquely supports <emphasis>both</emphasis> of
81 these scales of development. You can learn the basics in just
82 a few minutes, and due to its low overhead, you can apply
83 revision control to the smallest of projects with ease. Its
84 simplicity means you won't have a lot of abstruse concepts or
85 command sequences competing for mental space with whatever
86 you're <emphasis>really</emphasis> trying to do. At the same
87 time, Mercurial's high performance and peer-to-peer nature let
88 you scale painlessly to handle large projects.</para>
90 <para>No revision control tool can rescue a poorly run project,
91 but a good choice of tools can make a huge difference to the
92 fluidity with which you can work on a project.</para>
94 </sect2>
95 <sect2>
96 <title>The many names of revision control</title>
98 <para>Revision control is a diverse field, so much so that it
99 doesn't actually have a single name or acronym. Here are a
100 few of the more common names and acronyms you'll
101 encounter:</para>
102 <itemizedlist>
103 <listitem><para>Revision control (RCS)</para></listitem>
104 <listitem><para>Software configuration management (SCM), or
105 configuration management</para></listitem>
106 <listitem><para>Source code management</para></listitem>
107 <listitem><para>Source code control, or source
108 control</para></listitem>
109 <listitem><para>Version control
110 (VCS)</para></listitem></itemizedlist>
111 <para>Some people claim that these terms actually have different
112 meanings, but in practice they overlap so much that there's no
113 agreed or even useful way to tease them apart.</para>
115 </sect2>
116 </sect1>
117 <sect1>
118 <title>A short history of revision control</title>
120 <para>The best known of the old-time revision control tools is
121 SCCS (Source Code Control System), which Marc Rochkind wrote at
122 Bell Labs, in the early 1970s. SCCS operated on individual
123 files, and required every person working on a project to have
124 access to a shared workspace on a single system. Only one
125 person could modify a file at any time; arbitration for access
126 to files was via locks. It was common for people to lock files,
127 and later forget to unlock them, preventing anyone else from
128 modifying those files without the help of an
129 administrator.</para>
131 <para>Walter Tichy developed a free alternative to SCCS in the
132 early 1980s; he called his program RCS (Revision Control System).
133 Like SCCS, RCS required developers to work in a single shared
134 workspace, and to lock files to prevent multiple people from
135 modifying them simultaneously.</para>
137 <para>Later in the 1980s, Dick Grune used RCS as a building block
138 for a set of shell scripts he initially called cmt, but then
139 renamed to CVS (Concurrent Versions System). The big innovation
140 of CVS was that it let developers work simultaneously and
141 somewhat independently in their own personal workspaces. The
142 personal workspaces prevented developers from stepping on each
143 other's toes all the time, as was common with SCCS and RCS. Each
144 developer had a copy of every project file, and could modify
145 their copies independently. They had to merge their edits prior
146 to committing changes to the central repository.</para>
148 <para>Brian Berliner took Grune's original scripts and rewrote
149 them in C, releasing in 1989 the code that has since developed
150 into the modern version of CVS. CVS subsequently acquired the
151 ability to operate over a network connection, giving it a
152 client/server architecture. CVS's architecture is centralised;
153 only the server has a copy of the history of the project. Client
154 workspaces just contain copies of recent versions of the
155 project's files, and a little metadata to tell them where the
156 server is. CVS has been enormously successful; it is probably
157 the world's most widely used revision control system.</para>
159 <para>In the early 1990s, Sun Microsystems developed an early
160 distributed revision control system, called TeamWare. A
161 TeamWare workspace contains a complete copy of the project's
162 history. TeamWare has no notion of a central repository. (CVS
163 relied upon RCS for its history storage; TeamWare used
164 SCCS.)</para>
166 <para>As the 1990s progressed, awareness grew of a number of
167 problems with CVS. It records simultaneous changes to multiple
168 files individually, instead of grouping them together as a
169 single logically atomic operation. It does not manage its file
170 hierarchy well; it is easy to make a mess of a repository by
171 renaming files and directories. Worse, its source code is
172 difficult to read and maintain, which made the <quote>pain
173 level</quote> of fixing these architectural problems
174 prohibitive.</para>
176 <para>In 2001, Jim Blandy and Karl Fogel, two developers who had
177 worked on CVS, started a project to replace it with a tool that
178 would have a better architecture and cleaner code. The result,
179 Subversion, does not stray from CVS's centralised client/server
180 model, but it adds multi-file atomic commits, better namespace
181 management, and a number of other features that make it a
182 generally better tool than CVS. Since its initial release, it
183 has rapidly grown in popularity.</para>
185 <para>More or less simultaneously, Graydon Hoare began working on
186 an ambitious distributed revision control system that he named
187 Monotone. While Monotone addresses many of CVS's design flaws
188 and has a peer-to-peer architecture, it goes beyond earlier (and
189 subsequent) revision control tools in a number of innovative
190 ways. It uses cryptographic hashes as identifiers, and has an
191 integral notion of <quote>trust</quote> for code from different
192 sources.</para>
194 <para>Mercurial began life in 2005. While a few aspects of its
195 design are influenced by Monotone, Mercurial focuses on ease of
196 use, high performance, and scalability to very large
197 projects.</para>
199 </sect1>
200 <sect1>
201 <title>Trends in revision control</title>
203 <para>There has been an unmistakable trend in the development and
204 use of revision control tools over the past four decades, as
205 people have become familiar with the capabilities of their tools
206 and constrained by their limitations.</para>
208 <para>The first generation began by managing single files on
209 individual computers. Although these tools represented a huge
210 advance over ad-hoc manual revision control, their locking model
211 and reliance on a single computer limited them to small,
212 tightly-knit teams.</para>
214 <para>The second generation loosened these constraints by moving
215 to network-centered architectures, and managing entire projects
216 at a time. As projects grew larger, they ran into new problems.
217 With clients needing to talk to servers very frequently, server
218 scaling became an issue for large projects. An unreliable
219 network connection could prevent remote users from being able to
220 talk to the server at all. As open source projects started
221 making read-only access available anonymously to anyone, people
222 without commit privileges found that they could not use the
223 tools to interact with a project in a natural way, as they could
224 not record their changes.</para>
226 <para>The current generation of revision control tools is
227 peer-to-peer in nature. All of these systems have dropped the
228 dependency on a single central server, and allow people to
229 distribute their revision control data to where it's actually
230 needed. Collaboration over the Internet has moved from
231 constrained by technology to a matter of choice and consensus.
232 Modern tools can operate offline indefinitely and autonomously,
233 with a network connection only needed when syncing changes with
234 another repository.</para>
236 </sect1>
237 <sect1>
238 <title>A few of the advantages of distributed revision
239 control</title>
241 <para>Even though distributed revision control tools have for
242 several years been as robust and usable as their
243 previous-generation counterparts, people using older tools have
244 not yet necessarily woken up to their advantages. There are a
245 number of ways in which distributed tools shine relative to
246 centralised ones.</para>
248 <para>For an individual developer, distributed tools are almost
249 always much faster than centralised tools. This is for a simple
250 reason: a centralised tool needs to talk over the network for
251 many common operations, because most metadata is stored in a
252 single copy on the central server. A distributed tool stores
253 all of its metadata locally. All else being equal, talking over
254 the network adds overhead to a centralised tool. Don't
255 underestimate the value of a snappy, responsive tool: you're
256 going to spend a lot of time interacting with your revision
257 control software.</para>
259 <para>Distributed tools are indifferent to the vagaries of your
260 server infrastructure, again because they replicate metadata to
261 so many locations. If you use a centralised system and your
262 server catches fire, you'd better hope that your backup media
263 are reliable, and that your last backup was recent and actually
264 worked. With a distributed tool, you have many backups
265 available on every contributor's computer.</para>
267 <para>The reliability of your network will affect distributed
268 tools far less than it will centralised tools. You can't even
269 use a centralised tool without a network connection, except for
270 a few highly constrained commands. With a distributed tool, if
271 your network connection goes down while you're working, you may
272 not even notice. The only thing you won't be able to do is talk
273 to repositories on other computers, something that is relatively
274 rare compared with local operations. If you have a far-flung
275 team of collaborators, this may be significant.</para>
277 <sect2>
278 <title>Advantages for open source projects</title>
280 <para>If you take a shine to an open source project and decide
281 that you would like to start hacking on it, and that project
282 uses a distributed revision control tool, you are at once a
283 peer with the people who consider themselves the
284 <quote>core</quote> of that project. If they publish their
285 repositories, you can immediately copy their project history,
286 start making changes, and record your work, using the same
287 tools in the same ways as insiders. By contrast, with a
288 centralised tool, you must use the software in a <quote>read
289 only</quote> mode unless someone grants you permission to
290 commit changes to their central server. Until then, you won't
291 be able to record changes, and your local modifications will
292 be at risk of corruption any time you try to update your
293 client's view of the repository.</para>
295 <sect3>
296 <title>The forking non-problem</title>
298 <para>It has been suggested that distributed revision control
299 tools pose some sort of risk to open source projects because
300 they make it easy to <quote>fork</quote> the development of
301 a project. A fork happens when there are differences in
302 opinion or attitude between groups of developers that cause
303 them to decide that they can't work together any longer.
304 Each side takes a more or less complete copy of the
305 project's source code, and goes off in its own
306 direction.</para>
308 <para>Sometimes the camps in a fork decide to reconcile their
309 differences. With a centralised revision control system, the
310 <emphasis>technical</emphasis> process of reconciliation is
311 painful, and has to be performed largely by hand. You have
312 to decide whose revision history is going to
313 <quote>win</quote>, and graft the other team's changes into
314 the tree somehow. This usually loses some or all of one
315 side's revision history.</para>
317 <para>What distributed tools do with respect to forking is
318 they make forking the <emphasis>only</emphasis> way to
319 develop a project. Every single change that you make is
320 potentially a fork point. The great strength of this
321 approach is that a distributed revision control tool has to
322 be really good at <emphasis>merging</emphasis> forks,
323 because forks are absolutely fundamental: they happen all
324 the time.</para>
326 <para>If every piece of work that everybody does, all the
327 time, is framed in terms of forking and merging, then what
328 the open source world refers to as a <quote>fork</quote>
329 becomes <emphasis>purely</emphasis> a social issue. If
330 anything, distributed tools <emphasis>lower</emphasis> the
331 likelihood of a fork:</para>
332 <itemizedlist>
333 <listitem><para>They eliminate the social distinction that
334 centralised tools impose: that between insiders (people
335 with commit access) and outsiders (people
336 without).</para></listitem>
337 <listitem><para>They make it easier to reconcile after a
338 social fork, because all that's involved from the
339 perspective of the revision control software is just
340 another merge.</para></listitem></itemizedlist>
342 <para>Some people resist distributed tools because they want
343 to retain tight control over their projects, and they
344 believe that centralised tools give them this control.
345 However, if you're of this belief, and you publish your CVS
346 or Subversion repositories publicly, there are plenty of
347 tools available that can pull out your entire project's
348 history (albeit slowly) and recreate it somewhere that you
349 don't control. So while your control in this case is
350 illusory, you are forgoing the ability to fluidly
351 collaborate with whatever people feel compelled to mirror
352 and fork your history.</para>
354 </sect3>
355 </sect2>
356 <sect2>
357 <title>Advantages for commercial projects</title>
359 <para>Many commercial projects are undertaken by teams that are
360 scattered across the globe. Contributors who are far from a
361 central server will see slower command execution and perhaps
362 less reliability. Commercial revision control systems attempt
363 to ameliorate these problems with remote-site replication
364 add-ons that are typically expensive to buy and cantankerous
365 to administer. A distributed system doesn't suffer from these
366 problems in the first place. Better yet, you can easily set
367 up multiple authoritative servers, say one per site, so that
368 there's no redundant communication between repositories over
369 expensive long-haul network links.</para>
371 <para>Centralised revision control systems tend to have
372 relatively low scalability. It's not unusual for an expensive
373 centralised system to fall over under the combined load of
374 just a few dozen concurrent users. Once again, the typical
375 response tends to be an expensive and clunky replication
376 facility. Since the load on a central server---if you have
377 one at all---is many times lower with a distributed tool
378 (because all of the data is replicated everywhere), a single
379 cheap server can handle the needs of a much larger team, and
380 replication to balance load becomes a simple matter of
381 scripting.</para>
383 <para>If you have an employee in the field, troubleshooting a
384 problem at a customer's site, they'll benefit from distributed
385 revision control. The tool will let them generate custom
386 builds, try different fixes in isolation from each other, and
387 search efficiently through history for the sources of bugs and
388 regressions in the customer's environment, all without needing
389 to connect to your company's network.</para>
391 </sect2>
392 </sect1>
393 <sect1>
394 <title>Why choose Mercurial?</title>
396 <para>Mercurial has a unique set of properties that make it a
397 particularly good choice as a revision control system.</para>
398 <itemizedlist>
399 <listitem><para>It is easy to learn and use.</para></listitem>
400 <listitem><para>It is lightweight.</para></listitem>
401 <listitem><para>It scales excellently.</para></listitem>
402 <listitem><para>It is easy to
403 customise.</para></listitem></itemizedlist>
405 <para>If you are at all familiar with revision control systems,
406 you should be able to get up and running with Mercurial in less
407 than five minutes. Even if not, it will take no more than a few
408 minutes longer. Mercurial's command and feature sets are
409 generally uniform and consistent, so you can keep track of a few
410 general rules instead of a host of exceptions.</para>
412 <para>On a small project, you can start working with Mercurial in
413 moments. Creating new changes and branches; transferring changes
414 around (whether locally or over a network); and history and
415 status operations are all fast. Mercurial attempts to stay
416 nimble and largely out of your way by combining low cognitive
417 overhead with blazingly fast operations.</para>
419 <para>The usefulness of Mercurial is not limited to small
420 projects: it is used by projects with hundreds to thousands of
421 contributors, each containing tens of thousands of files and
422 hundreds of megabytes of source code.</para>
424 <para>If the core functionality of Mercurial is not enough for
425 you, it's easy to build on. Mercurial is well suited to
426 scripting tasks, and its clean internals and implementation in
427 Python make it easy to add features in the form of extensions.
428 There are a number of popular and useful extensions already
429 available, ranging from helping to identify bugs to improving
430 performance.</para>
432 </sect1>
433 <sect1>
434 <title>Mercurial compared with other tools</title>
436 <para>Before you read on, please understand that this section
437 necessarily reflects my own experiences, interests, and (dare I
438 say it) biases. I have used every one of the revision control
439 tools listed below, in most cases for several years at a
440 time.</para>
443 <sect2>
444 <title>Subversion</title>
446 <para>Subversion is a popular revision control tool, developed
447 to replace CVS. It has a centralised client/server
448 architecture.</para>
450 <para>Subversion and Mercurial have similarly named commands for
451 performing the same operations, so if you're familiar with
452 one, it is easy to learn to use the other. Both tools are
453 portable to all popular operating systems.</para>
455 <para>Prior to version 1.5, Subversion had no useful support for
456 merges. At the time of writing, its merge tracking capability
457 is new, and known to be <ulink
458 url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">complicated
459 and buggy</ulink>.</para>
461 <para>Mercurial has a substantial performance advantage over
462 Subversion on every revision control operation I have
463 benchmarked. I have measured its advantage as ranging from a
464 factor of two to a factor of six when compared with Subversion
465 1.4.3's <emphasis>ra_local</emphasis> file store, which is the
466 fastest access method available. In more realistic
467 deployments involving a network-based store, Subversion will
468 be at a substantially larger disadvantage. Because many
469 Subversion commands must talk to the server and Subversion
470 does not have useful replication facilities, server capacity
471 and network bandwidth become bottlenecks for modestly large
472 projects.</para>
474 <para>Additionally, Subversion incurs substantial storage
475 overhead to avoid network transactions for a few common
476 operations, such as finding modified files
477 (<literal>status</literal>) and displaying modifications
478 against the current revision (<literal>diff</literal>). As a
479 result, a Subversion working copy is often the same size as,
480 or larger than, a Mercurial repository and working directory,
481 even though the Mercurial repository contains a complete
482 history of the project.</para>
484 <para>Subversion is widely supported by third party tools.
485 Mercurial currently lags considerably in this area. This gap
486 is closing, however, and indeed some of Mercurial's GUI tools
487 now outshine their Subversion equivalents. Like Mercurial,
488 Subversion has an excellent user manual.</para>
490 <para>Because Subversion doesn't store revision history on the
491 client, it is well suited to managing projects that deal with
492 lots of large, opaque binary files. If you check in fifty
493 revisions to an incompressible 10MB file, Subversion's
494 client-side space usage stays constant The space used by any
495 distributed SCM will grow rapidly in proportion to the number
496 of revisions, because the differences between each revision
497 are large.</para>
499 <para>In addition, it's often difficult or, more usually,
500 impossible to merge different versions of a binary file.
501 Subversion's ability to let a user lock a file, so that they
502 temporarily have the exclusive right to commit changes to it,
503 can be a significant advantage to a project where binary files
504 are widely used.</para>
506 <para>Mercurial can import revision history from a Subversion
507 repository. It can also export revision history to a
508 Subversion repository. This makes it easy to <quote>test the
509 waters</quote> and use Mercurial and Subversion in parallel
510 before deciding to switch. History conversion is incremental,
511 so you can perform an initial conversion, then small
512 additional conversions afterwards to bring in new
513 changes.</para>
516 </sect2>
517 <sect2>
518 <title>Git</title>
520 <para>Git is a distributed revision control tool that was
521 developed for managing the Linux kernel source tree. Like
522 Mercurial, its early design was somewhat influenced by
523 Monotone.</para>
525 <para>Git has a very large command set, with version 1.5.0
526 providing 139 individual commands. It has something of a
527 reputation for being difficult to learn. Compared to Git,
528 Mercurial has a strong focus on simplicity.</para>
530 <para>In terms of performance, Git is extremely fast. In
531 several cases, it is faster than Mercurial, at least on Linux,
532 while Mercurial performs better on other operations. However,
533 on Windows, the performance and general level of support that
534 Git provides is, at the time of writing, far behind that of
535 Mercurial.</para>
537 <para>While a Mercurial repository needs no maintenance, a Git
538 repository requires frequent manual <quote>repacks</quote> of
539 its metadata. Without these, performance degrades, while
540 space usage grows rapidly. A server that contains many Git
541 repositories that are not rigorously and frequently repacked
542 will become heavily disk-bound during backups, and there have
543 been instances of daily backups taking far longer than 24
544 hours as a result. A freshly packed Git repository is
545 slightly smaller than a Mercurial repository, but an unpacked
546 repository is several orders of magnitude larger.</para>
548 <para>The core of Git is written in C. Many Git commands are
549 implemented as shell or Perl scripts, and the quality of these
550 scripts varies widely. I have encountered several instances
551 where scripts charged along blindly in the presence of errors
552 that should have been fatal.</para>
554 <para>Mercurial can import revision history from a Git
555 repository.</para>
558 </sect2>
559 <sect2>
560 <title>CVS</title>
562 <para>CVS is probably the most widely used revision control tool
563 in the world. Due to its age and internal untidiness, it has
564 been only lightly maintained for many years.</para>
566 <para>It has a centralised client/server architecture. It does
567 not group related file changes into atomic commits, making it
568 easy for people to <quote>break the build</quote>: one person
569 can successfully commit part of a change and then be blocked
570 by the need for a merge, causing other people to see only a
571 portion of the work they intended to do. This also affects
572 how you work with project history. If you want to see all of
573 the modifications someone made as part of a task, you will
574 need to manually inspect the descriptions and timestamps of
575 the changes made to each file involved (if you even know what
576 those files were).</para>
578 <para>CVS has a muddled notion of tags and branches that I will
579 not attempt to even describe. It does not support renaming of
580 files or directories well, making it easy to corrupt a
581 repository. It has almost no internal consistency checking
582 capabilities, so it is usually not even possible to tell
583 whether or how a repository is corrupt. I would not recommend
584 CVS for any project, existing or new.</para>
586 <para>Mercurial can import CVS revision history. However, there
587 are a few caveats that apply; these are true of every other
588 revision control tool's CVS importer, too. Due to CVS's lack
589 of atomic changes and unversioned filesystem hierarchy, it is
590 not possible to reconstruct CVS history completely accurately;
591 some guesswork is involved, and renames will usually not show
592 up. Because a lot of advanced CVS administration has to be
593 done by hand and is hence error-prone, it's common for CVS
594 importers to run into multiple problems with corrupted
595 repositories (completely bogus revision timestamps and files
596 that have remained locked for over a decade are just two of
597 the less interesting problems I can recall from personal
598 experience).</para>
600 <para>Mercurial can import revision history from a CVS
601 repository.</para>
604 </sect2>
605 <sect2>
606 <title>Commercial tools</title>
608 <para>Perforce has a centralised client/server architecture,
609 with no client-side caching of any data. Unlike modern
610 revision control tools, Perforce requires that a user run a
611 command to inform the server about every file they intend to
612 edit.</para>
614 <para>The performance of Perforce is quite good for small teams,
615 but it falls off rapidly as the number of users grows beyond a
616 few dozen. Modestly large Perforce installations require the
617 deployment of proxies to cope with the load their users
618 generate.</para>
621 </sect2>
622 <sect2>
623 <title>Choosing a revision control tool</title>
625 <para>With the exception of CVS, all of the tools listed above
626 have unique strengths that suit them to particular styles of
627 work. There is no single revision control tool that is best
628 in all situations.</para>
630 <para>As an example, Subversion is a good choice for working
631 with frequently edited binary files, due to its centralised
632 nature and support for file locking.</para>
634 <para>I personally find Mercurial's properties of simplicity,
635 performance, and good merge support to be a compelling
636 combination that has served me well for several years.</para>
639 </sect2>
640 </sect1>
641 <sect1>
642 <title>Switching from another tool to Mercurial</title>
644 <para>Mercurial is bundled with an extension named <literal
645 role="hg-ext">convert</literal>, which can incrementally
646 import revision history from several other revision control
647 tools. By <quote>incremental</quote>, I mean that you can
648 convert all of a project's history to date in one go, then rerun
649 the conversion later to obtain new changes that happened after
650 the initial conversion.</para>
652 <para>The revision control tools supported by <literal
653 role="hg-ext">convert</literal> are as follows:</para>
654 <itemizedlist>
655 <listitem><para>Subversion</para></listitem>
656 <listitem><para>CVS</para></listitem>
657 <listitem><para>Git</para></listitem>
658 <listitem><para>Darcs</para></listitem></itemizedlist>
660 <para>In addition, <literal role="hg-ext">convert</literal> can
661 export changes from Mercurial to Subversion. This makes it
662 possible to try Subversion and Mercurial in parallel before
663 committing to a switchover, without risking the loss of any
664 work.</para>
666 <para>The <command role="hg-ext-conver">convert</command> command
667 is easy to use. Simply point it at the path or URL of the
668 source repository, optionally give it the name of the
669 destination repository, and it will start working. After the
670 initial conversion, just run the same command again to import
671 new changes.</para>
672 </sect1>
673 </chapter>
675 <!--
676 local variables:
677 sgml-parent-document: ("00book.xml" "book" "chapter")
678 end:
679 -->