Mercurial > hgbook
changeset 724:cfdb601a3c8b
Fix imagedata fileref in xml files, and replace ':' with '.' in id attribute
| author | Dongsheng Song <dongsheng.song@gmail.com> |
|---|---|
| date | Thu, 12 Mar 2009 15:51:39 +0800 |
| parents | 3c5e1c03cc3e |
| children | 83a687a996b2 |
| files | en/00book.xml en/appA-cmdref.xml en/appB-mq-ref.xml en/appC-srcinstall.xml en/appD-license.xml en/ch00-preface.xml en/ch01-intro.xml en/ch02-tour-basic.xml en/ch03-tour-merge.xml en/ch04-concepts.xml en/ch05-daily.xml en/ch06-collab.xml en/ch07-filenames.xml en/ch08-branch.xml en/ch09-undo.xml en/ch10-hook.xml en/ch11-template.xml en/ch12-mq.xml en/ch13-mq-collab.xml en/ch14-hgext.xml |
| diffstat | 20 files changed, 247 insertions(+), 242 deletions(-) [+] |
line wrap: on
line diff
--- a/en/00book.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/00book.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" - "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ <!-- Below are references to files in this directory. --> @@ -39,6 +39,11 @@ <book id="hg"> <title>Mercurial: The Definitive Guide</title> + + <!-- hg parents --template '{node|short} ({date|shortdate})' + <subtitle>Compiled from 8a1d3f1aff17 (2009-03-10)</subtitle> + --> + <subtitle>Compiled from $rev_id$</subtitle> <bookinfo> <authorgroup> <author>
--- a/en/appA-cmdref.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/appA-cmdref.xml Thu Mar 12 15:51:39 2009 +0800 @@ -12,7 +12,7 @@ <para>Show differences between revisions for the specified files or directories, using the unified diff format. For a description of the -unified diff format, see section <xref linkend="sec:mq:patch"/>.</para> +unified diff format, see section <xref linkend="sec.mq.patch"/>.</para> <para>By default, this command does not print diffs for files that Mercurial considers to contain binary data. To control this behaviour, see the @@ -158,7 +158,7 @@ <sect2> <title>Tips and tricks</title> -<sect3 id="cmdref:diff-vs-status"> +<sect3 id="cmdref.diff-vs-status"> <title>Why do the results of <command role="hg-cmd">hg diff</command> and <command role="hg-cmd">hg status</command> differ?</title> <para>When you run the <command role="hg-cmd">hg status</command> command, you'll see a list of files
--- a/en/appB-mq-ref.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/appB-mq-ref.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,10 +1,10 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<appendix id="chap:mqref"> +<appendix id="chap.mqref"> <?dbhtml filename="mercurial-queues-reference.html"?> <title>Mercurial Queues reference</title> - <sect1 id="sec:mqref:cmdref"> + <sect1 id="sec.mqref.cmdref"> <title>MQ command reference</title> <para>For an overview of the commands provided by MQ, use the @@ -295,7 +295,7 @@ role="hg-ext-mq">qpop</command>.</para> </sect2> - <sect2 id="sec:mqref:cmd:qpush"> + <sect2 id="sec.mqref.cmd.qpush"> <title><command role="hg-ext-mq">qpush</command>&emdash;push patches onto the stack</title>
--- a/en/appC-srcinstall.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/appC-srcinstall.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,10 +1,10 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<appendix id="chap:srcinstall"> +<appendix id="chap.srcinstall"> <?dbhtml filename="installing-mercurial-from-source.html"?> <title>Installing Mercurial from source</title> - <sect1 id="sec:srcinstall:unixlike"> + <sect1 id="sec.srcinstall.unixlike"> <title>On a Unix-like system</title> <para>If you are using a Unix-like system that has a sufficiently
--- a/en/appD-license.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/appD-license.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<appendix id="cha:opl"> +<appendix id="cha.opl"> <?dbhtml filename="open-publication-license.html"?> <title>Open Publication License</title> @@ -32,7 +32,7 @@ <para>The reference must be immediately followed with any options elected by the author(s) and/or publisher of the document (see - section <xref linkend="sec:opl:options"/>).</para> + section <xref linkend="sec.opl.options"/>).</para> <para>Commercial redistribution of Open Publication-licensed material is permitted.</para> @@ -133,7 +133,7 @@ </listitem></orderedlist> </sect1> - <sect1 id="sec:opl:options"> + <sect1 id="sec.opl.options"> <title>License options</title> <para>The author(s) and/or publisher of an Open
--- a/en/ch00-preface.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch00-preface.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<preface id="chap:preface"> +<preface id="chap.preface"> <title>Preface</title> <para>Distributed revision control is a relatively new territory, @@ -51,7 +51,7 @@ example can show up as having occurred during the same second. You can see this occur in the <literal role="hg-ext">bisect</literal> example in section <xref - id="sec:undo:bisect"/>, for instance.</para> + id="sec.undo.bisect"/>, for instance.</para> <para>So when you're reading examples, don't place too much weight on the dates or times you see in the output of commands. But
--- a/en/ch01-intro.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch01-intro.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:intro"> +<chapter id="chap.intro"> <?dbhtml filename="introduction.html"?> <title>Introduction</title> @@ -50,7 +50,7 @@ fact, a <emphasis>really</emphasis> good revision control tool will even help you to efficiently figure out exactly when a problem was introduced (see section <xref - linkend="sec:undo:bisect"/> for details).</para></listitem> + linkend="sec.undo.bisect"/> for details).</para></listitem> <listitem><para>It will help you to work simultaneously on, and manage the drift between, multiple versions of your project.</para></listitem></itemizedlist>
--- a/en/ch02-tour-basic.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch02-tour-basic.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,10 +1,10 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:tour-basic"> +<chapter id="chap.tour-basic"> <?dbhtml filename="a-tour-of-mercurial-the-basics.html"?> <title>A tour of Mercurial: the basics</title> - <sect1 id="sec:tour:install"> + <sect1 id="sec.tour.install"> <title>Installing Mercurial on your system</title> <para>Prebuilt binary packages of Mercurial are available for @@ -250,7 +250,7 @@ log</command> is purely a summary; it is missing a lot of detail.</para> - <para>Figure <xref linkend="fig:tour-basic:history"/> provides a + <para>Figure <xref linkend="fig.tour-basic.history"/> provides a graphical representation of the history of the <filename class="directory">hello</filename> repository, to make it a little easier to see which direction history is @@ -258,9 +258,9 @@ several times in this chapter and the chapter that follows.</para> - <informalfigure id="fig:tour-basic:history"> + <informalfigure id="fig.tour-basic.history"> <mediaobject> - <imageobject><imagedata fileref="tour-history"/></imageobject> + <imageobject><imagedata fileref="images/tour-history.png"/></imageobject> <textobject><phrase>XXX add text</phrase></textobject> <caption><para>Graphical history of the <filename class="directory">hello</filename> @@ -361,7 +361,7 @@ <option role="hg-opt-log">--patch</option>) option. This displays the content of a change as a <emphasis>unified diff</emphasis> (if you've never seen a unified diff before, - see section <xref linkend="sec:mq:patch"/> for an + see section <xref linkend="sec.mq.patch"/> for an overview).</para> &interaction.tour.log-vp; @@ -519,7 +519,7 @@ <envar role="rc-item-ui">username</envar> entry, that will be used next. To see what the contents of this file should look like, refer to section <xref - linkend="sec:tour-basic:username"/> + linkend="sec.tour-basic.username"/> below.</para></listitem> <listitem><para>If you have set the <envar>EMAIL</envar> environment variable, this will be used @@ -543,7 +543,7 @@ and most robust way to set a username for yourself is by creating a <filename role="special">.hgrc</filename> file; see below for details.</para> - <sect3 id="sec:tour-basic:username"> + <sect3 id="sec.tour-basic.username"> <title>Creating a Mercurial configuration file</title> <para>To set a user name, use your favourite editor @@ -684,7 +684,7 @@ look at a few ways that we can propagate this change into other repositories.</para> - <sect2 id="sec:tour:pull"> + <sect2 id="sec.tour.pull"> <title>Pulling changes from another repository</title> <para>To get started, let's clone our original <filename class="directory">hello</filename> repository, @@ -734,7 +734,7 @@ <para>We have so far glossed over the relationship between a repository and its working directory. The <command role="hg-cmd">hg pull</command> command that we ran in - section <xref linkend="sec:tour:pull"/> brought changes + section <xref linkend="sec.tour.pull"/> brought changes into the repository, but if we check, there's no sign of those changes in the working directory. This is because <command role="hg-cmd">hg pull</command> does not (by default) touch @@ -761,7 +761,7 @@ <para>If you look back at the output of <command role="hg-cmd">hg pull</command> in section <xref - linkend="sec:tour:pull"/> when we ran it without <option + linkend="sec.tour.pull"/> when we ran it without <option role="hg-opt-pull">-u</option>, you can see that it printed a helpful reminder that we'd have to take an explicit step to update the working directory:</para> @@ -775,7 +775,7 @@ &interaction.tour.parents; <para>If you look back at figure <xref - linkend="fig:tour-basic:history"/>, + linkend="fig.tour-basic.history"/>, you'll see arrows connecting each changeset. The node that the arrow leads <emphasis>from</emphasis> in each case is a parent, and the node that the arrow leads
--- a/en/ch03-tour-merge.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch03-tour-merge.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:tour-merge"> +<chapter id="chap.tour-merge"> <?dbhtml filename="a-tour-of-mercurial-merging-work.html"?> <title>A tour of Mercurial: merging work</title> @@ -38,13 +38,13 @@ <filename>hello.c</filename> with different contents. The histories of the two repositories have also diverged, as illustrated in figure <xref - linkend="fig:tour-merge:sep-repos"/>.</para> + linkend="fig.tour-merge.sep-repos"/>.</para> &interaction.tour.merge.cat; - <informalfigure id="fig:tour-merge:sep-repos"> + <informalfigure id="fig.tour-merge.sep-repos"> <mediaobject> - <imageobject><imagedata fileref="tour-merge-sep-repos"/></imageobject> + <imageobject><imagedata fileref="images/tour-merge-sep-repos.png"/></imageobject> <textobject><phrase>XXX add text</phrase></textobject> <caption><para>Divergent recent histories of the <filename class="directory">my-hello</filename> and <filename @@ -71,9 +71,9 @@ children, but a repository can contain more than one head.</para> - <informalfigure id="fig:tour-merge:pull"> + <informalfigure id="fig.tour-merge.pull"> <mediaobject><imageobject><imagedata - fileref="tour-merge-pull"/></imageobject><textobject><phrase>XXX + fileref="images/tour-merge-pull.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject> <caption><para>Repository contents after pulling from <filename class="directory">my-hello</filename> into @@ -82,14 +82,14 @@ </mediaobject> </informalfigure> - <para>In figure <xref linkend="fig:tour-merge:pull"/>, you can + <para>In figure <xref linkend="fig.tour-merge.pull"/>, you can see the effect of the pull from <filename class="directory">my-hello</filename> into <filename class="directory">my-new-hello</filename>. The history that was already present in <filename class="directory">my-new-hello</filename> is untouched, but a new revision has been added. By referring to figure <xref - linkend="fig:tour-merge:sep-repos"/>, we can see that the + linkend="fig.tour-merge.sep-repos"/>, we can see that the <emphasis>changeset ID</emphasis> remains the same in the new repository, but the <emphasis>revision number</emphasis> has changed. (This, incidentally, is a fine example of why it's @@ -118,10 +118,10 @@ &interaction.tour.merge.merge; - <informalfigure id="fig:tour-merge:merge"> + <informalfigure id="fig.tour-merge.merge"> <mediaobject><imageobject><imagedata - fileref="tour-merge-merge"/></imageobject><textobject><phrase>XXX + fileref="images/tour-merge-merge.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject> <caption><para>Working directory and repository during merge, and following commit</para></caption> @@ -155,7 +155,7 @@ &interaction.tour.merge.tip; <para>In figure <xref - linkend="fig:tour-merge:merge"/>, you can see a + linkend="fig.tour-merge.merge"/>, you can see a representation of what happens to the working directory during the merge, and how this affects the repository when the commit happens. During the merge, the working directory has two @@ -176,14 +176,14 @@ <informalfigure> - <mediaobject id="fig:tour-merge:conflict"> - <imageobject><imagedata fileref="tour-merge-conflict"/></imageobject> + <mediaobject id="fig.tour-merge.conflict"> + <imageobject><imagedata fileref="images/tour-merge-conflict.png"/></imageobject> <textobject><phrase>XXX add text</phrase></textobject> <caption><para>Conflicting changes to a document</para></caption> </mediaobject> </informalfigure> - <para>Figure <xref linkend="fig:tour-merge:conflict"/> illustrates + <para>Figure <xref linkend="fig.tour-merge.conflict"/> illustrates an instance of two conflicting changes to a document. We started with a single version of the file; then we made some changes; while someone else made different changes to the same @@ -213,7 +213,7 @@ <command>kdiff3</command>, which I'll use to describe the features that are common to graphical file merging tools. You can see a screenshot of <command>kdiff3</command> in action in - figure <xref linkend="fig:tour-merge:kdiff3"/>. The kind of + figure <xref linkend="fig.tour-merge.kdiff3"/>. The kind of merge it is performing is called a <emphasis>three-way merge</emphasis>, because there are three different versions of the file of interest to us. The tool thus splits the upper @@ -243,9 +243,9 @@ in any of them, the others are updated to display the corresponding sections of their respective files.</para> - <informalfigure id="fig:tour-merge:kdiff3"> - <mediaobject><imageobject><imagedata - fileref="kdiff3"/></imageobject><textobject><phrase>XXX + <informalfigure id="fig.tour-merge.kdiff3"> + <mediaobject><imageobject><imagedata width="100%" + fileref="images/kdiff3.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject> <caption><para>Using <command>kdiff3</command> to merge versions of a file</para></caption> @@ -270,7 +270,7 @@ <title>A worked example</title> <para>In this example, we will reproduce the file modification - history of figure <xref linkend="fig:tour-merge:conflict"/> + history of figure <xref linkend="fig.tour-merge.conflict"/> above. Let's begin by creating a repository with a base version of our document.</para> @@ -331,7 +331,7 @@ </sect2> </sect1> - <sect1 id="sec:tour-merge:fetch"> + <sect1 id="sec.tour-merge.fetch"> <title>Simplifying the pull-merge-commit sequence</title> <para>The process of merging changes as outlined above is
--- a/en/ch04-concepts.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch04-concepts.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:concepts"> +<chapter id="chap.concepts"> <?dbhtml filename="behind-the-scenes.html"?> <title>Behind the scenes</title> @@ -47,11 +47,11 @@ file. The correspondence between a file in the working directory and the filelog that tracks its history in the repository is illustrated in figure <xref - linkend="fig:concepts:filelog"/>.</para> + linkend="fig.concepts.filelog"/>.</para> - <informalfigure id="fig:concepts:filelog"> + <informalfigure id="fig.concepts.filelog"> <mediaobject><imageobject><imagedata - fileref="filelog"/></imageobject><textobject><phrase>XXX + fileref="images/filelog.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject> <caption><para>Relationships between files in working directory and filelogs in @@ -97,11 +97,11 @@ manifest. A revision of the manifest stores a pointer to a single revision of each filelog tracked when that changeset was created. These relationships are illustrated in figure - <xref linkend="fig:concepts:metadata"/>.</para> + <xref linkend="fig.concepts.metadata"/>.</para> - <informalfigure id="fig:concepts:metadata"> + <informalfigure id="fig.concepts.metadata"> <mediaobject><imageobject><imagedata - fileref="metadata"/></imageobject><textobject><phrase>XXX + fileref="images/metadata.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Metadata relationships</para></caption> </mediaobject> @@ -145,7 +145,7 @@ doesn't need to treat text as special.</para> </sect2> - <sect2 id="sec:concepts:txn"> + <sect2 id="sec.concepts.txn"> <title>Safe operation</title> <para>Mercurial only ever <emphasis>appends</emphasis> data to @@ -184,9 +184,9 @@ file accumulates, the more revisions you must read, hence the longer it takes to reconstruct a particular revision.</para> - <informalfigure id="fig:concepts:snapshot"> + <informalfigure id="fig.concepts.snapshot"> <mediaobject><imageobject><imagedata - fileref="snapshot"/></imageobject><textobject><phrase>XXX + fileref="images/snapshot.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Snapshot of a revlog, with incremental deltas</para></caption></mediaobject> @@ -201,7 +201,7 @@ quickly. This approach works so well that it has since been copied by several other revision control systems.</para> - <para>Figure <xref linkend="fig:concepts:snapshot"/> illustrates + <para>Figure <xref linkend="fig.concepts.snapshot"/> illustrates the idea. In an entry in a revlog's index file, Mercurial stores the range of entries from the data file that it must read to reconstruct a particular revision.</para> @@ -273,7 +273,7 @@ <quote>there is no parent here</quote>. This hash is simply a string of zeroes.</para> - <para>In figure <xref linkend="fig:concepts:revlog"/>, you can see + <para>In figure <xref linkend="fig.concepts.revlog"/>, you can see an example of the conceptual structure of a revlog. Filelogs, manifests, and changelogs all have this same structure; they differ only in the kind of data stored in each delta or @@ -288,9 +288,9 @@ revision that represents a merge between branches has two normal revision IDs in its parent slots.</para> - <informalfigure id="fig:concepts:revlog"> + <informalfigure id="fig.concepts.revlog"> <mediaobject><imageobject><imagedata - fileref="revlog"/></imageobject><textobject><phrase>XXX + fileref="images/revlog.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject> </informalfigure> @@ -337,23 +337,23 @@ dirstate as <emphasis>the parents of a new changeset</emphasis> when you perform a commit.</para> - <informalfigure id="fig:concepts:wdir"> + <informalfigure id="fig.concepts.wdir"> <mediaobject><imageobject><imagedata - fileref="wdir"/></imageobject><textobject><phrase>XXX + fileref="images/wdir.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>The working directory can have two parents</para></caption></mediaobject> </informalfigure> - <para>Figure <xref linkend="fig:concepts:wdir"/> shows the + <para>Figure <xref linkend="fig.concepts.wdir"/> shows the normal state of the working directory, where it has a single changeset as parent. That changeset is the <emphasis>tip</emphasis>, the newest changeset in the repository that has no children.</para> - <informalfigure id="fig:concepts:wdir-after-commit"> + <informalfigure id="fig.concepts.wdir-after-commit"> <mediaobject><imageobject><imagedata - fileref="wdir-after-commit"/></imageobject><textobject><phrase>XXX + fileref="images/wdir-after-commit.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>The working directory gains new parents after a commit</para></caption></mediaobject> @@ -370,7 +370,7 @@ <para>After a commit, Mercurial will update the parents of the working directory, so that the first parent is the ID of the new changeset, and the second is the null ID. This is shown - in figure <xref linkend="fig:concepts:wdir-after-commit"/>. + in figure <xref linkend="fig.concepts.wdir-after-commit"/>. Mercurial doesn't touch any of the files in the working directory when you commit; it just modifies the dirstate to note its new @@ -389,11 +389,11 @@ interested in, and then examine the files in the working directory directly to see their contents as they were when you committed that changeset. The effect of this is shown in - figure <xref linkend="fig:concepts:wdir-pre-branch"/>.</para> + figure <xref linkend="fig.concepts.wdir-pre-branch"/>.</para> - <informalfigure id="fig:concepts:wdir-pre-branch"> + <informalfigure id="fig.concepts.wdir-pre-branch"> <mediaobject><imageobject><imagedata - fileref="wdir-pre-branch"/></imageobject><textobject><phrase>XXX + fileref="images/wdir-pre-branch.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>The working directory, updated to an older changeset</para></caption></mediaobject> @@ -408,11 +408,11 @@ contains two changesets that have no children; we call these <emphasis>heads</emphasis>. You can see the structure that this creates in figure <xref - linkend="fig:concepts:wdir-branch"/>.</para> + linkend="fig.concepts.wdir-branch"/>.</para> - <informalfigure id="fig:concepts:wdir-branch"> + <informalfigure id="fig.concepts.wdir-branch"> <mediaobject><imageobject><imagedata - fileref="wdir-branch"/></imageobject><textobject><phrase>XXX + fileref="images/wdir-branch.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>After a commit made while synced to an older changeset</para></caption></mediaobject> @@ -449,11 +449,11 @@ command, Mercurial leaves the first parent of the working directory unchanged, and sets the second parent to the changeset you're merging with, as shown in figure <xref - linkend="fig:concepts:wdir-merge"/>.</para> + linkend="fig.concepts.wdir-merge"/>.</para> - <informalfigure id="fig:concepts:wdir-merge"> + <informalfigure id="fig.concepts.wdir-merge"> <mediaobject><imageobject><imagedata - fileref="wdir-merge"/></imageobject><textobject><phrase>XXX + fileref="images/wdir-merge.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Merging two heads</para></caption></mediaobject> </informalfigure> @@ -582,7 +582,7 @@ <para>Appending to files isn't the whole story when it comes to guaranteeing that a reader won't see a partial write. If you - recall figure <xref linkend="fig:concepts:metadata"/>, + recall figure <xref linkend="fig.concepts.metadata"/>, revisions in the changelog point to revisions in the manifest, and revisions in the manifest point to revisions in filelogs. This hierarchy
--- a/en/ch05-daily.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch05-daily.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:daily"> +<chapter id="chap.daily"> <?dbhtml filename="mercurial-in-daily-use.html"?> <title>Mercurial in daily use</title> @@ -274,7 +274,7 @@ &interaction.daily.copy.merge; </sect2> - <sect2 id="sec:daily:why-copy"> + <sect2 id="sec.daily.why-copy"> <title>Why should changes follow copies?</title> <para>This behaviour, of changes to a file propagating out to @@ -328,7 +328,7 @@ Unix-like systems, that's <command>cp</command>) to make a copy of a file, then <command role="hg-cmd">hg add</command> the new copy by hand. Before you do so, though, please do - reread section <xref linkend="sec:daily:why-copy"/>, and make + reread section <xref linkend="sec.daily.why-copy"/>, and make an informed decision that this behaviour is not appropriate to your specific case.</para> @@ -532,7 +532,7 @@ <para>For more information about the <command role="hg-cmd">hg revert</command> command, and details about how to deal with changes you have already committed, see chapter <xref - linkend="chap:undo"/>.</para> + linkend="chap.undo"/>.</para> </sect1> </chapter>
--- a/en/ch06-collab.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch06-collab.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="cha:collab"> +<chapter id="cha.collab"> <?dbhtml filename="collaborating-with-other-people.html"?> <title>Collaborating with other people</title> @@ -47,12 +47,12 @@ first is using the <command role="hg-cmd">hg serve</command> command, which is best suited to short-term <quote>lightweight</quote> serving. See section <xref - linkend="sec:collab:serve"/> below for details of how to use + linkend="sec.collab.serve"/> below for details of how to use this command. If you have a long-lived repository that you'd like to make permanently available, Mercurial has built-in support for the CGI (Common Gateway Interface) standard, which all common web servers support. See section <xref - linkend="sec:collab:cgi"/> for details of CGI + linkend="sec.collab.cgi"/> for details of CGI configuration.</para> </sect1> @@ -120,7 +120,7 @@ role="hg-cmd">hg serve</command> does not require any fancy server infrastructure. You can get started with <command role="hg-cmd">hg serve</command> in moments, by reading - section <xref linkend="sec:collab:serve"/> below. Then simply + section <xref linkend="sec.collab.serve"/> below. Then simply tell the person next to you that you're running a server, send the URL to them in an instant message, and you immediately have a @@ -165,9 +165,9 @@ <para>In this kind of scenario, people usually use the <command>ssh</command> protocol to securely push changes to the central repository, as documented in section <xref - linkend="sec:collab:ssh"/>. It's also + linkend="sec.collab.ssh"/>. It's also usual to publish a read-only copy of the repository over HTTP - using CGI, as in section <xref linkend="sec:collab:cgi"/>. + using CGI, as in section <xref linkend="sec.collab.cgi"/>. Publishing over HTTP satisfies the needs of people who don't have push access, and those who want to use web browsers to browse the repository's @@ -270,9 +270,9 @@ People working on an individual branch are typically quite isolated from developments on other branches.</para> - <informalfigure id="fig:collab:feature-branches"> + <informalfigure id="fig.collab.feature-branches"> <mediaobject><imageobject><imagedata - fileref="feature-branches"/></imageobject><textobject><phrase>XXX + fileref="images/feature-branches.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Feature branches</para></caption></mediaobject> </informalfigure> @@ -408,7 +408,7 @@ in which your team may be moving at once. Even though this subject is intimately related to how your team collaborates, it's dense enough to merit treatment of its own, in chapter - <xref linkend="chap:branch"/>.</para> + <xref linkend="chap.branch"/>.</para> </sect2> </sect1> @@ -419,7 +419,7 @@ serving data to your collaborators.</para> </sect1> - <sect1 id="sec:collab:serve"> + <sect1 id="sec.collab.serve"> <title>Informal sharing with <command role="hg-cmd">hg serve</command></title> @@ -498,7 +498,7 @@ </sect2> </sect1> - <sect1 id="sec:collab:ssh"> + <sect1 id="sec.collab.ssh"> <title>Using the Secure Shell (ssh) protocol</title> <para>You can pull and push changes securely over a network @@ -859,7 +859,7 @@ </sect2> </sect1> - <sect1 id="sec:collab:cgi"> + <sect1 id="sec.collab.cgi"> <title>Serving over HTTP using CGI</title> <para>Depending on how ambitious you are, configuring Mercurial's @@ -951,7 +951,7 @@ must not be writable by others.</para> <programlisting>chmod 755 ~/public_html</programlisting> - <sect3 id="sec:collab:wtf"> + <sect3 id="sec.collab.wtf"> <title>What could <emphasis>possibly</emphasis> go wrong?</title> @@ -1118,7 +1118,7 @@ display an empty list of repositories. If you get a blank window or error message, try walking through the list of potential problems in section <xref - linkend="sec:collab:wtf"/>.</para> + linkend="sec.collab.wtf"/>.</para> <para>The <filename role="special">hgwebdir.cgi</filename> script relies on an external configuration file. By default, @@ -1317,7 +1317,7 @@ <literal>default</literal> and <literal>gitweb</literal> (the latter is much more visually attractive). You can also specify a custom template of your own; see chapter - <xref linkend="chap:template"/> for details. + <xref linkend="chap.template"/> for details. Here, you can see how to enable the <literal>gitweb</literal> style.</para> <programlisting>[web] style = gitweb</programlisting>
--- a/en/ch07-filenames.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch07-filenames.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:names"> +<chapter id="chap.names"> <?dbhtml filename="file-names-and-pattern-matching.html"?> <title>File names and pattern matching</title> @@ -274,7 +274,7 @@ <para>XXX.</para> </sect1> - <sect1 id="sec:names:case"> + <sect1 id="sec.names.case"> <title>Case sensitivity</title> <para>If you're working in a mixed development environment that
--- a/en/ch08-branch.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch08-branch.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:branch"> +<chapter id="chap.branch"> <?dbhtml filename="managing-releases-and-branchy-development.html"?> <title>Managing releases and branchy development</title>
--- a/en/ch09-undo.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch09-undo.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:undo"> +<chapter id="chap.undo"> <?dbhtml filename="finding-and-fixing-mistakes.html"?> <title>Finding and fixing mistakes</title> @@ -27,17 +27,17 @@ less annoying.</para> </sect2> - <sect2 id="sec:undo:rollback"> + <sect2 id="sec.undo.rollback"> <title>Rolling back a transaction</title> - <para>In section <xref linkend="sec:concepts:txn"/>, I mentioned + <para>In section <xref linkend="sec.concepts.txn"/>, I mentioned that Mercurial treats each modification of a repository as a <emphasis>transaction</emphasis>. Every time you commit a changeset or pull changes from another repository, Mercurial remembers what you did. You can undo, or <emphasis>roll back</emphasis>, exactly one of these actions using the <command role="hg-cmd">hg rollback</command> command. (See - section <xref linkend="sec:undo:rollback-after-push"/> for an + section <xref linkend="sec.undo.rollback-after-push"/> for an important caveat about the use of this command.)</para> <para>Here's a mistake that I often find myself making: @@ -111,7 +111,7 @@ need to undo this mistake.</para> </sect2> - <sect2 id="sec:undo:rollback-after-push"> + <sect2 id="sec.undo.rollback-after-push"> <title>Rolling back is useless once you've pushed</title> <para>The value of the <command role="hg-cmd">hg @@ -214,7 +214,7 @@ the file to its unmodified contents.</para> </listitem></itemizedlist> - <sect2 id="sec:undo:mgmt"> + <sect2 id="sec.undo.mgmt"> <title>File management errors</title> <para>The <command role="hg-cmd">hg revert</command> command is @@ -306,7 +306,7 @@ modifying or erasing it. It's the right tool to use if you're fixing bugs, but not if you're trying to undo some change that has catastrophic consequences. To deal with those, see section - <xref linkend="sec:undo:aaaiiieee"/>.</para> + <xref linkend="sec.undo.aaaiiieee"/>.</para> <sect2> <title>Backing out a changeset</title> @@ -354,13 +354,13 @@ that <command role="hg-cmd">hg backout</command> has created is a child of the changeset we backed out. It's easier to see this in figure <xref - linkend="fig:undo:backout"/>, which presents a graphical + linkend="fig.undo.backout"/>, which presents a graphical view of the change history. As you can see, the history is nice and linear.</para> - <informalfigure id="fig:undo:backout"> + <informalfigure id="fig.undo.backout"> <mediaobject><imageobject><imagedata - fileref="undo-simple"/></imageobject><textobject><phrase>XXX + fileref="images/undo-simple.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Backing out a change using the <command role="hg-cmd">hg backout</command> @@ -393,7 +393,7 @@ &interaction.backout.non-tip.cat; <para>As the graphical history in figure <xref - linkend="fig:undo:backout-non-tip"/> illustrates, Mercurial + linkend="fig.undo.backout-non-tip"/> illustrates, Mercurial actually commits <emphasis>two</emphasis> changes in this kind of situation (the box-shaped nodes are the ones that Mercurial commits automatically). Before Mercurial begins the backout @@ -406,9 +406,9 @@ <para>% TODO: to me it looks like mercurial doesn't commit the second merge automatically!</para> - <informalfigure id="fig:undo:backout-non-tip"> + <informalfigure id="fig.undo.backout-non-tip"> <mediaobject><imageobject><imagedata - fileref="undo-non-tip"/></imageobject><textobject><phrase>XXX + fileref="images/undo-non-tip.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Automated backout of a non-tip change using the <command role="hg-cmd">hg backout</command> @@ -465,15 +465,15 @@ <para>Again, it's easier to see what has happened by looking at a graph of the revision history, in figure <xref - linkend="fig:undo:backout-manual"/>. This makes it clear + linkend="fig.undo.backout-manual"/>. This makes it clear that when we use <command role="hg-cmd">hg backout</command> to back out a change other than the tip, Mercurial adds a new head to the repository (the change it committed is box-shaped).</para> - <informalfigure id="fig:undo:backout-manual"> + <informalfigure id="fig.undo.backout-manual"> <mediaobject><imageobject><imagedata - fileref="undo-manual"/></imageobject><textobject><phrase>XXX + fileref="images/undo-manual.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Backing out a change using the <command role="hg-cmd">hg backout</command> @@ -509,11 +509,11 @@ <para>Afterwards, the graphical history of our repository looks like figure - <xref linkend="fig:undo:backout-manual-merge"/>.</para> + <xref linkend="fig.undo.backout-manual-merge"/>.</para> - <informalfigure id="fig:undo:backout-manual-merge"> + <informalfigure id="fig.undo.backout-manual-merge"> <mediaobject><imageobject><imagedata - fileref="undo-manual-merge"/></imageobject><textobject><phrase>XXX + fileref="images/undo-manual-merge.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Manually merging a backout change</para></caption></mediaobject> @@ -584,7 +584,7 @@ are likely to have <quote>broken the context</quote> that <command>patch</command> uses to determine whether it can apply a patch (if this sounds like gibberish, see <xref - linkend="sec:mq:patch"/> for a + linkend="sec.mq.patch"/> for a discussion of the <command>patch</command> command). Also, Mercurial's merge machinery will handle files and directories being renamed, permission changes, and modifications to binary @@ -593,7 +593,7 @@ </sect2> </sect1> - <sect1 id="sec:undo:aaaiiieee"> + <sect1 id="sec.undo.aaaiiieee"> <title>Changes that should never have been</title> <para>Most of the time, the <command role="hg-cmd">hg @@ -623,7 +623,7 @@ been pushed or pulled into another repository. That's when you can safely use the <command role="hg-cmd">hg rollback</command> command, as I detailed in section <xref - linkend="sec:undo:rollback"/>.</para> + linkend="sec.undo.rollback"/>.</para> <para>After you've pushed a bad change to another repository, you <emphasis>could</emphasis> still use <command role="hg-cmd">hg @@ -664,7 +664,7 @@ central repository.</para> <para>By configuring some hooks on that repository to validate - incoming changesets (see chapter <xref linkend="chap:hook"/>), + incoming changesets (see chapter <xref linkend="chap.hook"/>), you can automatically prevent some kinds of bad changeset from being pushed to the central repository at all. With such a @@ -679,7 +679,7 @@ </sect2> </sect1> - <sect1 id="sec:undo:bisect"> + <sect1 id="sec.undo.bisect"> <title>Finding the source of a bug</title> <para>While it's all very well to be able to back out a changeset
--- a/en/ch10-hook.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch10-hook.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:hook"> +<chapter id="chap.hook"> <?dbhtml filename="handling-repository-events-with-hooks.html"?> <title>Handling repository events with hooks</title> @@ -19,7 +19,7 @@ <para>Here is a brief list of the hooks that Mercurial supports. We will revisit each of these hooks in more detail later, in - section <xref linkend="sec:hook:ref"/>.</para> + section <xref linkend="sec.hook.ref"/>.</para> <itemizedlist> <listitem><para><literal role="hook">changegroup</literal>: This @@ -343,7 +343,7 @@ </sect2> </sect1> - <sect1 id="sec:hook:simple"> + <sect1 id="sec.hook.simple"> <title>A short tutorial on using hooks</title> <para>It is easy to write a Mercurial hook. Let's start with a @@ -400,11 +400,11 @@ message that contains the hook name and extension, so using a descriptive extension could give you an immediate hint as to why the hook failed (see section <xref - linkend="sec:hook:perm"/> for an example). + linkend="sec.hook.perm"/> for an example). </para> </sect2> - <sect2 id="sec:hook:perm"> + <sect2 id="sec.hook.perm"> <title>Controlling whether an activity can proceed</title> <para>In our earlier examples, we used the <literal @@ -459,7 +459,7 @@ message before it calls each hook. </para> - <sect2 id="sec:hook:lang"> + <sect2 id="sec.hook.lang"> <title>Choosing how your hook should run</title> <para>You can write a hook either as a normal @@ -490,7 +490,7 @@ </para> </sect2> - <sect2 id="sec:hook:param"> + <sect2 id="sec.hook.param"> <title>Hook parameters</title> <para>Mercurial calls each hook with a set of well-defined @@ -888,7 +888,7 @@ </para> </listitem></itemizedlist> - <sect3 id="sec:hook:bugzilla:config"> + <sect3 id="sec.hook.bugzilla.config"> <title>Configuring the <literal role="hook">bugzilla</literal> hook</title> @@ -1101,7 +1101,7 @@ </para> <para>Recall from section <xref - linkend="sec:hook:bugzilla:config"/> above that the user + linkend="sec.hook.bugzilla.config"/> above that the user that runs the Mercurial process on the server is also the one that will run the <filename>processmail</filename> script. The <filename>processmail</filename> script @@ -1259,7 +1259,7 @@ out email about changes that remote users pushed into this repository via a server, for example. See section <xref - linkend="sec:hook:sources"/> for the sources you can + linkend="sec.hook.sources"/> for the sources you can specify here. </para> </listitem></itemizedlist> @@ -1318,7 +1318,7 @@ </sect3> </sect2> </sect1> - <sect1 id="sec:hook:ref"> + <sect1 id="sec.hook.ref"> <title>Information for writers of hooks</title> <sect2> @@ -1426,7 +1426,7 @@ transferred to or from. </para> - <sect3 id="sec:hook:sources"> + <sect3 id="sec.hook.sources"> <title>Sources of changesets</title> <para>Mercurial will tell a hook what means are, or were, used @@ -1458,7 +1458,7 @@ </listitem></itemizedlist> </sect3> - <sect3 id="sec:hook:url"> + <sect3 id="sec.hook.url"> <title>Where changes are going&emdash;remote repository URLs</title> @@ -1500,7 +1500,7 @@ <sect1> <title>Hook reference</title> - <sect2 id="sec:hook:changegroup"> + <sect2 id="sec.hook.changegroup"> <title><literal role="hook">changegroup</literal>&emdash;after remote changesets added</title> @@ -1535,26 +1535,26 @@ </listitem> <listitem><para><literal>source</literal>: A string. The source of these changes. See section <xref - linkend="sec:hook:sources"/> for details. + linkend="sec.hook.sources"/> for details. </para> </listitem> <listitem><para><literal>url</literal>: A URL. The location of the remote repository, if known. See section <xref - linkend="sec:hook:url"/> for more + linkend="sec.hook.url"/> for more information. </para> </listitem></itemizedlist> <para>See also: <literal role="hook">incoming</literal> (section - <xref linkend="sec:hook:incoming"/>), <literal + <xref linkend="sec.hook.incoming"/>), <literal role="hook">prechangegroup</literal> (section <xref - linkend="sec:hook:prechangegroup"/>), <literal + linkend="sec.hook.prechangegroup"/>), <literal role="hook">pretxnchangegroup</literal> (section <xref - linkend="sec:hook:pretxnchangegroup"/>) + linkend="sec.hook.pretxnchangegroup"/>) </para> </sect2> - <sect2 id="sec:hook:commit"> + <sect2 id="sec.hook.commit"> <title><literal role="hook">commit</literal>&emdash;after a new changeset is created</title> @@ -1580,13 +1580,13 @@ </listitem></itemizedlist> <para>See also: <literal role="hook">precommit</literal> - (section <xref linkend="sec:hook:precommit"/>), <literal + (section <xref linkend="sec.hook.precommit"/>), <literal role="hook">pretxncommit</literal> (section <xref - linkend="sec:hook:pretxncommit"/>) + linkend="sec.hook.pretxncommit"/>) </para> </sect2> - <sect2 id="sec:hook:incoming"> + <sect2 id="sec.hook.incoming"> <title><literal role="hook">incoming</literal>&emdash;after one remote changeset is added</title> @@ -1599,7 +1599,7 @@ <para>You can use this hook for the same purposes as the <literal role="hook">changegroup</literal> hook (section <xref - linkend="sec:hook:changegroup"/>); it's simply + linkend="sec.hook.changegroup"/>); it's simply more convenient sometimes to run a hook once per group of changesets, while other times it's handier once per changeset. </para> @@ -1613,26 +1613,26 @@ </listitem> <listitem><para><literal>source</literal>: A string. The source of these changes. See section <xref - linkend="sec:hook:sources"/> for details. + linkend="sec.hook.sources"/> for details. </para> </listitem> <listitem><para><literal>url</literal>: A URL. The location of the remote repository, if known. See section <xref - linkend="sec:hook:url"/> for more + linkend="sec.hook.url"/> for more information. </para> </listitem></itemizedlist> <para>See also: <literal role="hook">changegroup</literal> - (section <xref linkend="sec:hook:changegroup"/>) <literal + (section <xref linkend="sec.hook.changegroup"/>) <literal role="hook">prechangegroup</literal> (section <xref - linkend="sec:hook:prechangegroup"/>), <literal + linkend="sec.hook.prechangegroup"/>), <literal role="hook">pretxnchangegroup</literal> (section <xref - linkend="sec:hook:pretxnchangegroup"/>) + linkend="sec.hook.pretxnchangegroup"/>) </para> </sect2> - <sect2 id="sec:hook:outgoing"> + <sect2 id="sec.hook.outgoing"> <title><literal role="hook">outgoing</literal>&emdash;after changesets are propagated</title> @@ -1656,7 +1656,7 @@ </listitem> <listitem><para><literal>source</literal>: A string. The source of the of the operation (see section <xref - linkend="sec:hook:sources"/>). If a remote + linkend="sec.hook.sources"/>). If a remote client pulled changes from this repository, <literal>source</literal> will be <literal>serve</literal>. If the client that obtained @@ -1669,17 +1669,17 @@ </listitem> <listitem><para><literal>url</literal>: A URL. The location of the remote repository, if known. See section <xref - linkend="sec:hook:url"/> for more + linkend="sec.hook.url"/> for more information. </para> </listitem></itemizedlist> <para>See also: <literal role="hook">preoutgoing</literal> - (section <xref linkend="sec:hook:preoutgoing"/>) + (section <xref linkend="sec.hook.preoutgoing"/>) </para> </sect2> - <sect2 id="sec:hook:prechangegroup"> + <sect2 id="sec.hook.prechangegroup"> <title><literal role="hook">prechangegroup</literal>&emdash;before starting to add remote changesets</title> @@ -1706,26 +1706,26 @@ <itemizedlist> <listitem><para><literal>source</literal>: A string. The source of these changes. See section <xref - linkend="sec:hook:sources"/> for details. + linkend="sec.hook.sources"/> for details. </para> </listitem> <listitem><para><literal>url</literal>: A URL. The location of the remote repository, if known. See section <xref - linkend="sec:hook:url"/> for more + linkend="sec.hook.url"/> for more information. </para> </listitem></itemizedlist> <para>See also: <literal role="hook">changegroup</literal> - (section <xref linkend="sec:hook:changegroup"/>), <literal + (section <xref linkend="sec.hook.changegroup"/>), <literal role="hook">incoming</literal> (section <xref - linkend="sec:hook:incoming"/>), , <literal + linkend="sec.hook.incoming"/>), , <literal role="hook">pretxnchangegroup</literal> (section <xref - linkend="sec:hook:pretxnchangegroup"/>) + linkend="sec.hook.pretxnchangegroup"/>) </para> </sect2> - <sect2 id="sec:hook:precommit"> + <sect2 id="sec.hook.precommit"> <title><literal role="hook">precommit</literal>&emdash;before starting to commit a changeset</title> @@ -1759,13 +1759,13 @@ </para> <para>See also: <literal role="hook">commit</literal> (section - <xref linkend="sec:hook:commit"/>), <literal + <xref linkend="sec.hook.commit"/>), <literal role="hook">pretxncommit</literal> (section <xref - linkend="sec:hook:pretxncommit"/>) + linkend="sec.hook.pretxncommit"/>) </para> </sect2> - <sect2 id="sec:hook:preoutgoing"> + <sect2 id="sec.hook.preoutgoing"> <title><literal role="hook">preoutgoing</literal>&emdash;before starting to propagate changesets</title> @@ -1783,27 +1783,27 @@ <listitem><para><literal>source</literal>: A string. The source of the operation that is attempting to obtain changes from this repository (see section <xref - linkend="sec:hook:sources"/>). See the documentation + linkend="sec.hook.sources"/>). See the documentation for the <literal>source</literal> parameter to the <literal role="hook">outgoing</literal> hook, in section - <xref linkend="sec:hook:outgoing"/>, for possible values + <xref linkend="sec.hook.outgoing"/>, for possible values of this parameter. </para> </listitem> <listitem><para><literal>url</literal>: A URL. The location of the remote repository, if known. See section <xref - linkend="sec:hook:url"/> for more + linkend="sec.hook.url"/> for more information. </para> </listitem></itemizedlist> <para>See also: <literal role="hook">outgoing</literal> (section - <xref linkend="sec:hook:outgoing"/>) + <xref linkend="sec.hook.outgoing"/>) </para> </sect2> - <sect2 id="sec:hook:pretag"> + <sect2 id="sec.hook.pretag"> <title><literal role="hook">pretag</literal>&emdash;before tagging a changeset</title> @@ -1834,15 +1834,15 @@ <para>If the tag to be created is revision-controlled, the <literal role="hook">precommit</literal> and <literal role="hook">pretxncommit</literal> hooks (sections <xref - linkend="sec:hook:commit"/> and <xref - linkend="sec:hook:pretxncommit"/>) will also be run. + linkend="sec.hook.commit"/> and <xref + linkend="sec.hook.pretxncommit"/>) will also be run. </para> <para>See also: <literal role="hook">tag</literal> (section - <xref linkend="sec:hook:tag"/>) + <xref linkend="sec.hook.tag"/>) </para> </sect2> - <sect2 id="sec:hook:pretxnchangegroup"> + <sect2 id="sec.hook.pretxnchangegroup"> <title><literal role="hook">pretxnchangegroup</literal>&emdash;before completing addition of remote changesets</title> @@ -1889,26 +1889,26 @@ </listitem> <listitem><para><literal>source</literal>: A string. The source of these changes. See section <xref - linkend="sec:hook:sources"/> for details. + linkend="sec.hook.sources"/> for details. </para> </listitem> <listitem><para><literal>url</literal>: A URL. The location of the remote repository, if known. See section <xref - linkend="sec:hook:url"/> for more + linkend="sec.hook.url"/> for more information. </para> </listitem></itemizedlist> <para>See also: <literal role="hook">changegroup</literal> - (section <xref linkend="sec:hook:changegroup"/>), <literal + (section <xref linkend="sec.hook.changegroup"/>), <literal role="hook">incoming</literal> (section <xref - linkend="sec:hook:incoming"/>), <literal + linkend="sec.hook.incoming"/>), <literal role="hook">prechangegroup</literal> (section <xref - linkend="sec:hook:prechangegroup"/>) + linkend="sec.hook.prechangegroup"/>) </para> </sect2> - <sect2 id="sec:hook:pretxncommit"> + <sect2 id="sec.hook.pretxncommit"> <title><literal role="hook">pretxncommit</literal>&emdash;before completing commit of new changeset</title> @@ -1951,11 +1951,11 @@ </listitem></itemizedlist> <para>See also: <literal role="hook">precommit</literal> - (section <xref linkend="sec:hook:precommit"/>) + (section <xref linkend="sec.hook.precommit"/>) </para> </sect2> - <sect2 id="sec:hook:preupdate"> + <sect2 id="sec.hook.preupdate"> <title><literal role="hook">preupdate</literal>&emdash;before updating or merging working directory</title> @@ -1983,11 +1983,11 @@ </listitem></itemizedlist> <para>See also: <literal role="hook">update</literal> (section - <xref linkend="sec:hook:update"/>) + <xref linkend="sec.hook.update"/>) </para> </sect2> - <sect2 id="sec:hook:tag"> + <sect2 id="sec.hook.tag"> <title><literal role="hook">tag</literal>&emdash;after tagging a changeset</title> @@ -2016,15 +2016,15 @@ <para>If the created tag is revision-controlled, the <literal role="hook">commit</literal> hook (section <xref - linkend="sec:hook:commit"/>) is run before this hook. + linkend="sec.hook.commit"/>) is run before this hook. </para> <para>See also: <literal role="hook">pretag</literal> (section - <xref linkend="sec:hook:pretag"/>) + <xref linkend="sec.hook.pretag"/>) </para> </sect2> - <sect2 id="sec:hook:update"> + <sect2 id="sec.hook.update"> <title><literal role="hook">update</literal>&emdash;after updating or merging working directory</title> @@ -2054,7 +2054,7 @@ </listitem></itemizedlist> <para>See also: <literal role="hook">preupdate</literal> - (section <xref linkend="sec:hook:preupdate"/>) + (section <xref linkend="sec.hook.preupdate"/>) </para> </sect2>
--- a/en/ch11-template.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch11-template.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:template"> +<chapter id="chap.template"> <?dbhtml filename="customizing-the-output-of-mercurial.html"?> <title>Customising the output of Mercurial</title> @@ -10,7 +10,7 @@ command, or to customise the entire appearance of the built-in web interface.</para> - <sect1 id="sec:style"> + <sect1 id="sec.style"> <title>Using precanned output styles</title> <para>Packaged with Mercurial are some output styles that you can @@ -106,7 +106,7 @@ <emphasis>escape sequence</emphasis>, telling Mercurial to print a newline at the end of each template item. If you omit this newline, Mercurial will run each piece of output together. See - section <xref linkend="sec:template:escape"/> for more details + section <xref linkend="sec.template.escape"/> for more details of escape sequences.</para> <para>A template that prints a fixed string of text all the time @@ -124,10 +124,10 @@ and text with the expansion of whatever is inside. To print a literal curly brace, you must escape it, as described in section <xref - linkend="sec:template:escape"/>.</para> + linkend="sec.template.escape"/>.</para> </sect1> - <sect1 id="sec:template:keyword"> + <sect1 id="sec.template.keyword"> <title>Common template keywords</title> <para>You can start writing simple templates immediately using the @@ -149,7 +149,7 @@ committed. This is <emphasis>not</emphasis> human-readable; you must pass it through a filter that will render it appropriately. See section <xref - linkend="sec:template:filter"/> for more information + linkend="sec.template.filter"/> for more information on filters. The date is expressed as a pair of numbers. The first number is a Unix UTC timestamp (seconds since January 1, 1970); the second is the offset of the committer's @@ -197,12 +197,12 @@ human-readable output, so we must treat it specially. This involves using a <emphasis>filter</emphasis>, about which more in section <xref - linkend="sec:template:filter"/>.</para> + linkend="sec.template.filter"/>.</para> &interaction.template.simple.datekeyword; </sect1> - <sect1 id="sec:template:escape"> + <sect1 id="sec.template.escape"> <title>Escape sequences</title> <para>Mercurial's templating engine recognises the most commonly @@ -244,7 +244,7 @@ it.</para> </sect1> - <sect1 id="sec:template:filter"> + <sect1 id="sec.template.filter"> <title>Filtering keywords to change their results</title> <para>Some of the results of template expansion are not
--- a/en/ch12-mq.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch12-mq.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,10 +1,10 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:mq"> +<chapter id="chap.mq"> <?dbhtml filename="managing-change-with-mercurial-queues.html"?> <title>Managing change with Mercurial Queues</title> - <sect1 id="sec:mq:patch-mgmt"> + <sect1 id="sec.mq.patch-mgmt"> <title>The patch management problem</title> <para>Here is a common scenario: you need to install a software @@ -37,7 +37,7 @@ <para>When you have few changes to maintain, it is easy to manage a single patch using the standard <command>diff</command> and <command>patch</command> programs (see section <xref - linkend="sec:mq:patch"/> for a discussion of these + linkend="sec.mq.patch"/> for a discussion of these tools). Once the number of changes grows, it starts to make sense to maintain patches as discrete <quote>chunks of work,</quote> so that for example a single patch will contain @@ -61,7 +61,7 @@ simplifies the patch management problem.</para> </sect1> - <sect1 id="sec:mq:history"> + <sect1 id="sec.mq.history"> <title>The prehistory of Mercurial Queues</title> <para>During the late 1990s, several Linux kernel developers @@ -76,7 +76,7 @@ successfully using these scripts to manage hundreds (sometimes thousands) of patches on top of the Linux kernel.</para> - <sect2 id="sec:mq:quilt"> + <sect2 id="sec.mq.quilt"> <title>A patchwork quilt</title> <para>In early 2003, Andreas Gruenbacher and Martin Quinson @@ -120,7 +120,7 @@ Subversion working copy.</para> </sect2> - <sect2 id="sec:mq:quilt-mq"> + <sect2 id="sec.mq.quilt-mq"> <title>From patchwork quilt to Mercurial Queues</title> <para>In mid-2005, Chris Mason took the features of quilt and @@ -183,7 +183,7 @@ And so on.</para> </sect1> - <sect1 id="sec:mq:patch"> + <sect1 id="sec.mq.patch"> <title>Understanding patches</title> <para>Because MQ doesn't hide its patch-oriented nature, it is @@ -241,12 +241,12 @@ represented by one deletion and one insertion.</para> <para>We will return to some of the more subtle aspects of patches - later (in section <xref linkend="sec:mq:adv-patch"/>), but you + later (in section <xref linkend="sec.mq.adv-patch"/>), but you should have enough information now to use MQ.</para> </sect1> - <sect1 id="sec:mq:start"> + <sect1 id="sec.mq.start"> <title>Getting started with Mercurial Queues</title> <para>Because MQ is implemented as an extension, you must @@ -400,12 +400,12 @@ but the patch no longer has a corresponding changeset in the repository, and the working directory does not contain the changes made by the patch. Figure <xref - linkend="fig:mq:stack"/> illustrates + linkend="fig.mq.stack"/> illustrates the difference between applied and tracked patches.</para> - <informalfigure id="fig:mq:stack"> + <informalfigure id="fig.mq.stack"> <mediaobject><imageobject><imagedata - fileref="mq-stack"/></imageobject><textobject><phrase>XXX + fileref="images/mq-stack.png"/></imageobject><textobject><phrase>XXX add text</phrase></textobject><caption><para>Applied and unapplied patches in the MQ patch stack</para></caption></mediaobject> @@ -440,7 +440,7 @@ role="hg-ext-mq-cmd-qpop-opt">-a</option> option to <command role="hg-ext-mq">qpop</command> causes it to pop all applied patches. (For some more ways to push and pop many patches, - see section <xref linkend="sec:mq:perf"/> + see section <xref linkend="sec.mq.perf"/> below.)</para> &interaction.mq.tutorial.qpush-a; @@ -501,7 +501,7 @@ </sect2> </sect1> - <sect1 id="sec:mq:adv-patch"> + <sect1 id="sec.mq.adv-patch"> <title>More about patches</title> <para>MQ uses the GNU <command>patch</command> command to apply @@ -700,7 +700,7 @@ and no longer does because you've changed the underlying code that your patches are based on, Mercurial Queues can help; see section <xref - linkend="sec:mq:merge"/> for details.</para> + linkend="sec.mq.merge"/> for details.</para> <para>Unfortunately, there aren't any great techniques for dealing with rejected hunks. Most often, you'll need to view @@ -747,7 +747,7 @@ </sect2> </sect1> - <sect1 id="sec:mq:perf"> + <sect1 id="sec.mq.perf"> <title>Getting the best performance out of MQ</title> <para>MQ is very efficient at handling a large number of patches. @@ -801,7 +801,7 @@ is zero, the second is one, and so on.</para> </sect1> - <sect1 id="sec:mq:merge"> + <sect1 id="sec.mq.merge"> <title>Updating your patches when the underlying code changes</title> @@ -945,7 +945,7 @@ <programlisting>hg email qbase:qtip </programlisting> <para> (Don't know what <quote>patchbombing</quote> is? See - section <xref linkend="sec:hgext:patchbomb"/>.)</para> + section <xref linkend="sec.hgext.patchbomb"/>.)</para> </listitem> <listitem><para>Need to see all of the patches since <literal>foo.patch</literal> that have touched files in a @@ -987,7 +987,7 @@ that represents the patch after the pop/push will have a <emphasis>different identity</emphasis> than the changeset that represented the hash beforehand. See section <xref - linkend="sec:mqref:cmd:qpush"/> for + linkend="sec.mqref.cmd.qpush"/> for information as to why this is.</para> </listitem> <listitem><para>It's not a good idea to <command @@ -1000,7 +1000,7 @@ </listitem></itemizedlist> </sect1> - <sect1 id="sec:mq:repo"> + <sect1 id="sec.mq.repo"> <title>Managing patches in a repository</title> <para>Because MQ's <filename role="special" @@ -1108,7 +1108,7 @@ </sect2> </sect1> - <sect1 id="sec:mq:tools"> + <sect1 id="sec.mq.tools"> <title>Third party tools for working with patches</title> <para>Once you've been working with patches for a while, you'll @@ -1140,7 +1140,7 @@ invocation of <command>filterdiff</command> can generate a smaller patch that only touches files whose names match a particular glob pattern. See section <xref - linkend="mq-collab:tips:interdiff"/> for another + linkend="mq-collab.tips.interdiff"/> for another example.</para> </sect1> @@ -1177,7 +1177,7 @@ <para>For this reason, it is very much worth investing a little time to learn how to use some of the third-party tools I - described in section <xref linkend="sec:mq:tools"/>, + described in section <xref linkend="sec.mq.tools"/>, particularly <command>diffstat</command> and <command>filterdiff</command>. The former will give you a quick idea of what changes your patch @@ -1226,7 +1226,7 @@ &interaction.mq.tarball.repush; </sect2> - <sect2 id="sec:mq:combine"> + <sect2 id="sec.mq.combine"> <title>Combining entire patches</title> <para>MQ provides a command, <command @@ -1299,7 +1299,7 @@ <para>Once you have this hunk, you can concatenate it onto the end of your destination patch and continue with the remainder - of section <xref linkend="sec:mq:combine"/>.</para> + of section <xref linkend="sec.mq.combine"/>.</para> </sect2> </sect1>
--- a/en/ch13-mq-collab.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch13-mq-collab.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:mq-collab"> +<chapter id="chap.mq-collab"> <?dbhtml filename="advanced-uses-of-mercurial-queues.html"?> <title>Advanced uses of Mercurial Queues</title> @@ -430,12 +430,12 @@ path separators.</para> </sect2> - <sect2 id="mq-collab:tips:interdiff"> + <sect2 id="mq-collab.tips.interdiff"> <title>Viewing the history of a patch</title> <para>If you're developing a set of patches over a long time, it's a good idea to maintain them in a repository, as - discussed in section <xref linkend="sec:mq:repo"/>. If you do + discussed in section <xref linkend="sec.mq.repo"/>. If you do so, you'll quickly discover that using the <command role="hg-cmd">hg diff</command> command to look at the history of changes to @@ -506,7 +506,7 @@ <para>The <literal role="hg-ext">extdiff</literal> extension is useful for more than merely improving the presentation of MQ patches. To read more about it, go to section <xref - linkend="sec:hgext:extdiff"/>.</para> + linkend="sec.hgext.extdiff"/>.</para> </sect2> </sect1>
--- a/en/ch14-hgext.xml Thu Mar 12 15:47:15 2009 +0800 +++ b/en/ch14-hgext.xml Thu Mar 12 15:51:39 2009 +0800 @@ -1,6 +1,6 @@ <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> -<chapter id="chap:hgext"> +<chapter id="chap.hgext"> <?dbhtml filename="adding-functionality-with-extensions.html"?> <title>Adding functionality with extensions</title> @@ -15,13 +15,13 @@ <emphasis>plugins</emphasis>). We've already discussed a few of these extensions in earlier chapters.</para> <itemizedlist> - <listitem><para>Section <xref linkend="sec:tour-merge:fetch"/> + <listitem><para>Section <xref linkend="sec.tour-merge.fetch"/> covers the <literal role="hg-ext">fetch</literal> extension; this combines pulling new changes and merging them with local changes into a single command, <command role="hg-ext-fetch">fetch</command>.</para> </listitem> - <listitem><para>In chapter <xref linkend="chap:hook"/>, we covered + <listitem><para>In chapter <xref linkend="chap.hook"/>, we covered several extensions that are useful for hook-related functionality: <literal role="hg-ext">acl</literal> adds access control lists; <literal @@ -32,10 +32,10 @@ </listitem> <listitem><para>The Mercurial Queues patch management extension is so invaluable that it merits two chapters and an appendix all - to itself. Chapter <xref linkend="chap:mq"/> covers the + to itself. Chapter <xref linkend="chap.mq"/> covers the basics; chapter <xref - linkend="chap:mq-collab"/> discusses advanced topics; - and appendix <xref linkend="chap:mqref"/> goes into detail on + linkend="chap.mq-collab"/> discusses advanced topics; + and appendix <xref linkend="chap.mqref"/> goes into detail on each command.</para> </listitem></itemizedlist> @@ -45,13 +45,13 @@ machinery you'll need to know about if you want to write an extension of your own.</para> <itemizedlist> - <listitem><para>In section <xref linkend="sec:hgext:inotify"/>, + <listitem><para>In section <xref linkend="sec.hgext.inotify"/>, we'll discuss the possibility of <emphasis>huge</emphasis> performance improvements using the <literal role="hg-ext">inotify</literal> extension.</para> </listitem></itemizedlist> - <sect1 id="sec:hgext:inotify"> + <sect1 id="sec.hgext.inotify"> <title>Improve performance with the <literal role="hg-ext">inotify</literal> extension</title> @@ -188,7 +188,7 @@ <listitem><para>Make sure that you have the Mercurial Queues extension, <literal role="hg-ext">mq</literal>, enabled. If you've never used MQ, read section <xref - linkend="sec:mq:start"/> to get started + linkend="sec.mq.start"/> to get started quickly.</para> </listitem> <listitem><para>Go into the <filename @@ -263,7 +263,7 @@ these situations occurs, please report a bug.</para> </sect1> - <sect1 id="sec:hgext:extdiff"> + <sect1 id="sec.hgext.extdiff"> <title>Flexible diff support with the <literal role="hg-ext">extdiff</literal> extension</title> @@ -360,7 +360,7 @@ example of such scripting in action with the <literal role="hg-ext">mq</literal> extension and the <command>interdiff</command> command, see section <xref - linkend="mq-collab:tips:interdiff"/>.</para> + linkend="mq-collab.tips.interdiff"/>.</para> <sect2> <title>Defining command aliases</title> @@ -402,14 +402,14 @@ </sect2> </sect1> - <sect1 id="sec:hgext:transplant"> + <sect1 id="sec.hgext.transplant"> <title>Cherrypicking changes with the <literal role="hg-ext">transplant</literal> extension</title> <para>Need to have a long chat with Brendan about this.</para> </sect1> - <sect1 id="sec:hgext:patchbomb"> + <sect1 id="sec.hgext.patchbomb"> <title>Send changes via email with the <literal role="hg-ext">patchbomb</literal> extension</title> @@ -504,7 +504,7 @@ use.</para> </listitem> <listitem><para>The default behaviour is to send unified diffs - (see section <xref linkend="sec:mq:patch"/> for a + (see section <xref linkend="sec.mq.patch"/> for a description of the format), one per message. You can send a binary bundle instead with the <option