Updating the working directory

# HG changeset patch # User Bryan O'Sullivan # Date 1238127723 25200 # Node ID 4ce9d0754af34e9f2502d207b6568d5ab588d6cc # Parent b788b405e14197421376d424284467ed6b0219d9 Remove the words "section", "chapter", etc from in front of xref tags. diff -r b788b405e141 -r 4ce9d0754af3 en/appA-cmdref.xml --- a/en/appA-cmdref.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/appA-cmdref.xml Thu Mar 26 21:22:03 2009 -0700 @@ -12,7 +12,7 @@ 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 . +unified diff format, see . By default, this command does not print diffs for files that Mercurial considers to contain binary data. To control this behaviour, see the diff -r b788b405e141 -r 4ce9d0754af3 en/appD-license.xml --- a/en/appD-license.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/appD-license.xml Thu Mar 26 21:22:03 2009 -0700 @@ -32,7 +32,7 @@ The reference must be immediately followed with any options elected by the author(s) and/or publisher of the document (see - section ). + ). Commercial redistribution of Open Publication-licensed material is permitted. diff -r b788b405e141 -r 4ce9d0754af3 en/ch00-preface.xml --- a/en/ch00-preface.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch00-preface.xml Thu Mar 26 21:22:03 2009 -0700 @@ -61,7 +61,7 @@ can revert to an earlier version of one or more files. In fact, a really good revision control tool will even help you to efficiently figure out exactly - when a problem was introduced (see section for details). It will help you to work simultaneously on, and manage the drift between, multiple versions of your @@ -167,7 +167,7 @@ As an instance of this, several consecutive commits in an example can show up as having occurred during the same second. You can see this occur in the bisect example in section bisect example in , for instance. So when you're reading examples, don't place too much weight diff -r b788b405e141 -r 4ce9d0754af3 en/ch01-tour-basic.xml --- a/en/ch01-tour-basic.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch01-tour-basic.xml Thu Mar 26 21:22:03 2009 -0700 @@ -246,8 +246,8 @@ log is purely a summary; it is missing a lot of detail. - Figure provides a - graphical representation of the history of the provides + a graphical representation of the history of the hello repository, to make it a little easier to see which direction history is flowing in. We'll be returning to this figure @@ -351,13 +351,13 @@ &interaction.tour.log-v; - If you want to see both the description and content of a - change, add the (or - ) option. This - displays the content of a change as a unified - diff (if you've never seen a unified diff before, - see section for an - overview). + If you want to see both the description and + content of a change, add the (or ) option. This displays + the content of a change as a unified diff + (if you've never seen a unified diff before, see for an overview). &interaction.tour.log-vp; @@ -509,11 +509,12 @@ If you have set the HGUSER environment variable, this is checked next. - If you create a file in your home directory - called .hgrc, with a - username entry, that will - be used next. To see what the contents of this file - should look like, refer to section If you create a file in your home + directory called .hgrc, with a username entry, that will be + used next. To see what the contents of this file should + look like, refer to below. If you have set the EMAIL @@ -727,12 +728,12 @@ Updating the working directory - We have so far glossed over the relationship between a - repository and its working directory. The We have so far glossed over the relationship + between a repository and its working directory. The hg pull command that we ran in - section brought changes - into the repository, but if we check, there's no sign of those - changes in the working directory. This is because brought changes into the + repository, but if we check, there's no sign of those changes + in the working directory. This is because hg pull does not (by default) touch the working directory. Instead, we use the hg update command to do this. @@ -756,7 +757,7 @@ role="hg-cmd">hg pull. If you look back at the output of hg pull in section hg pull in when we ran it without , you can see that it printed a helpful reminder that we'd have to take an explicit step to @@ -770,7 +771,7 @@ &interaction.tour.parents; - If you look back at figure If you look back at , you'll see arrows connecting each changeset. The node that the arrow leads from in each case is a diff -r b788b405e141 -r 4ce9d0754af3 en/ch02-tour-merge.xml --- a/en/ch02-tour-merge.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch02-tour-merge.xml Thu Mar 26 21:22:03 2009 -0700 @@ -37,7 +37,7 @@ We should now have two copies of hello.c with different contents. The histories of the two repositories have also diverged, as - illustrated in figure . &interaction.tour.merge.cat; @@ -83,13 +83,13 @@ - In figure , you can + In , you can see the effect of the pull from my-hello into my-new-hello. The history that was already present in my-new-hello is untouched, but - a new revision has been added. By referring to figure , we can see that the changeset ID remains the same in the new repository, but the revision number has @@ -156,7 +156,7 @@ &interaction.tour.merge.tip; - In figure In , you can see a representation of what happens to the working directory during the merge, and how this affects the repository when the commit @@ -184,7 +184,7 @@ - Figure illustrates + 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 @@ -214,7 +214,7 @@ kdiff3, which I'll use to describe the features that are common to graphical file merging tools. You can see a screenshot of kdiff3 in action in - figure . The kind of + . The kind of merge it is performing is called a three-way merge, because there are three different versions of the file of interest to us. The tool thus splits the upper @@ -274,7 +274,7 @@ A worked example In this example, we will reproduce the file modification - history of figure + history of above. Let's begin by creating a repository with a base version of our document. diff -r b788b405e141 -r 4ce9d0754af3 en/ch03-concepts.xml --- a/en/ch03-concepts.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch03-concepts.xml Thu Mar 26 21:22:03 2009 -0700 @@ -46,7 +46,7 @@ are combined in a single .i file. The correspondence between a file in the working directory and the filelog that tracks its history in the - repository is illustrated in figure .

@@ -96,7 +96,7 @@ changelog contains a pointer to a single revision of the 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 + was created. These relationships are illustrated in .

@@ -201,7 +201,7 @@ quickly. This approach works so well that it has since been copied by several other revision control systems. - Figure illustrates + 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. @@ -273,7 +273,7 @@ there is no parent here. This hash is simply a string of zeroes. - In figure , you can see + In , 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 @@ -347,7 +347,7 @@ - Figure shows the + shows the normal state of the working directory, where it has a single changeset as parent. That changeset is the tip, the newest changeset in the @@ -370,11 +370,11 @@ the new changeset will have the parents of the working directory as its parents. - 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 . - Mercurial + 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 . Mercurial doesn't touch any of the files in the working directory when you commit; it just modifies the dirstate to note its new parents. @@ -392,7 +392,7 @@ 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 . + .

The working directory, updated to an older @@ -403,15 +403,15 @@ </mediaobject> </figure> - <para id="x_313">Having updated the working directory to an older - changeset, what happens if you make some changes, and then - commit? Mercurial behaves in the same way as I outlined + <para id="x_313">Having updated the working directory to an + older changeset, what happens if you make some changes, and + then commit? Mercurial behaves in the same way as I outlined above. The parents of the working directory become the parents of the new changeset. This new changeset has no children, so it becomes the new tip. And the repository now contains two changesets that have no children; we call these <emphasis>heads</emphasis>. You can see the structure that - this creates in figure <xref + this creates in <xref linkend="fig:concepts:wdir-branch"/>.</para> <figure id="fig:concepts:wdir-branch"> @@ -450,10 +450,10 @@ <sect2> <title>Merging heads - When you run the hg merge - 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 When you run the hg + merge 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 .

@@ -588,13 +588,13 @@ Read/write ordering and atomicity - 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 , - revisions in the - changelog point to revisions in the manifest, and revisions in - the manifest point to revisions in filelogs. This hierarchy - is deliberate. + 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 , + revisions in + the changelog point to revisions in the manifest, and + revisions in the manifest point to revisions in filelogs. + This hierarchy is deliberate. A writer starts a transaction by writing filelog and manifest data, and doesn't write any changelog data until diff -r b788b405e141 -r 4ce9d0754af3 en/ch04-daily.xml --- a/en/ch04-daily.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch04-daily.xml Thu Mar 26 21:22:03 2009 -0700 @@ -328,7 +328,7 @@ Unix-like systems, that's cp) to make a copy of a file, then hg add the new copy by hand. Before you do so, though, please do - reread section , and make + reread , and make an informed decision that this behaviour is not appropriate to your specific case. @@ -529,9 +529,9 @@ decide it was a mistake, you can still do something about it, though your options may be more limited. - For more information about the hg - revert command, and details about how to deal with - changes you have already committed, see chapter For more information about the hg revert command, and details about + how to deal with changes you have already committed, see . diff -r b788b405e141 -r 4ce9d0754af3 en/ch05-collab.xml --- a/en/ch05-collab.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch05-collab.xml Thu Mar 26 21:22:03 2009 -0700 @@ -42,16 +42,16 @@ the master Mercurial repository at http://www.selenic.com/repo/hg?style=gitweb. - If you're interested in providing a web interface to your - own repositories, Mercurial provides two ways to do this. The - first is using the hg serve - command, which is best suited to short-term - lightweight serving. See section If you're interested in providing a web interface + to your own repositories, Mercurial provides two ways to do + this. The first is using the hg + serve command, which is best suited to short-term + lightweight serving. See 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 for details of CGI configuration. @@ -115,19 +115,19 @@ place) and spend several days more or less locked in there, hacking intensely on a handful of projects. - A sprint is the perfect place to use the hg serve command, since hg serve does not require any fancy - server infrastructure. You can get started with hg serve in moments, by reading - section 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 - quick-turnaround way to work together. They can type your URL - into their web browser and quickly review your changes; or - they can pull a bugfix from you and verify it; or they can - clone a branch containing a new feature and try it out. + A sprint is the perfect place to use the + hg serve command, since + hg serve does not require any + fancy server infrastructure. You can get started with + hg serve in moments, by + reading 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 quick-turnaround way to work together. They can type + your URL into their web browser and quickly review your + changes; or they can pull a bugfix from you and verify it; or + they can clone a branch containing a new feature and try it + out. The charm, and the problem, with doing things in an ad hoc fashion like this is that only people who know about your @@ -162,16 +162,15 @@ lets us put off publishing the potentially unsafe change until it has had a little testing. - In this kind of scenario, people usually use the - ssh protocol to securely push changes to - the central repository, as documented in section . It's also - usual to publish a read-only copy of the repository over HTTP - using CGI, as in section . - 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 - history. + In this kind of scenario, people usually use + the ssh protocol to securely push changes + to the central repository, as documented in . It's also usual to publish a + read-only copy of the repository over HTTP using CGI, as in + . 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 history. @@ -402,14 +401,14 @@ Where collaboration meets branch management - Once you and your team set up some shared repositories and - start propagating changes back and forth between local and - shared repos, you begin to face a related, but slightly - different challenge: that of managing the multiple directions - 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 - . + Once you and your team set up some shared + repositories and start propagating changes back and forth + between local and shared repos, you begin to face a related, + but slightly different challenge: that of managing the + multiple directions 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 . @@ -1110,15 +1109,17 @@ You'll need to copy this script into your public_html directory, and ensure that it's executable. + cp .../hgwebdir.cgi ~/public_html chmod 755 ~/public_html ~/public_html/hgwebdir.cgi - With basic configuration out of the way, try to visit - With basic configuration out of the way, try to + visit http://myhostname/ myuser/hgwebdir.cgi in your browser. It should 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 . The hgwebdir.cgi @@ -1313,15 +1314,16 @@ rows when you are looking at a table, this number controls the number of rows in each stripe. - style: - Controls the template Mercurial uses to display the web - interface. Mercurial ships with two web templates, named + style: Controls the template + Mercurial uses to display the web interface. Mercurial + ships with two web templates, named default and gitweb (the latter is much more visually attractive). You can - also specify a custom template of your own; see chapter - for details. - Here, you can see how to enable the - gitweb style. + also specify a custom template of your own; see + for details. Here, you can + see how to enable the gitweb + style. [web] style = gitweb diff -r b788b405e141 -r 4ce9d0754af3 en/ch08-undo.xml --- a/en/ch08-undo.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch08-undo.xml Thu Mar 26 21:22:03 2009 -0700 @@ -30,15 +30,15 @@ Rolling back a transaction - In section , I mentioned - that Mercurial treats each modification of a repository as a - transaction. Every time you commit a - changeset or pull changes from another repository, Mercurial - remembers what you did. You can undo, or roll - back, exactly one of these actions using the - hg rollback command. (See - section for an - important caveat about the use of this command.) + In , I + mentioned that Mercurial treats each modification of a + repository as a transaction. Every time + you commit a changeset or pull changes from another + repository, Mercurial remembers what you did. You can undo, + or roll back, exactly one of these + actions using the hg rollback + command. (See + for an important caveat about the use of this command.) Here's a mistake that I often find myself making: committing a change in which I've created a new file, but @@ -300,12 +300,12 @@ an entire changeset automatically, and building blocks that let you reverse part of a changeset by hand. - Before you read this section, here's something to keep in - mind: the hg backout command - undoes changes by adding history, not by - 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 + Before you read this section, here's something to + keep in mind: the hg backout + command undoes changes by adding history, + not by 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 . @@ -353,10 +353,9 @@ &interaction.backout.simple.log; Notice that the new changeset that hg backout has created is a child of the changeset we backed out. It's easier to see - this in figure , which presents a graphical - view of the change history. As you can see, the history is - nice and linear. + this in , which presents a + graphical view of the change history. As you can see, the + history is nice and linear.

Backing out a change using the <command @@ -391,7 +390,7 @@ &interaction.backout.non-tip.cat; - <para id="x_100">As the graphical history in figure <xref + <para id="x_100">As the graphical history in <xref 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 @@ -463,7 +462,7 @@ &interaction.backout.manual.log; <para id="x_108">Again, it's easier to see what has happened by looking at - a graph of the revision history, in figure <xref + a graph of the revision history, in <xref 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 @@ -505,8 +504,8 @@ &interaction.backout.manual.merge; - <para id="x_10e">Afterwards, the graphical history of our repository looks - like figure + <para id="x_10e">Afterwards, the graphical history of our + repository looks like <xref linkend="fig:undo:backout-manual-merge"/>.</para> <figure id="fig:undo:backout-manual-merge"> @@ -614,14 +613,14 @@ that you want to pull a brown paper bag over your head), let me first discuss some approaches that probably won't work.</para> - <para id="x_11e">Since Mercurial treats history as accumulative&emdash;every - change builds on top of all changes that preceded it&emdash;you - generally can't just make disastrous changes disappear. The one - exception is when you've just committed a change, and it hasn't - 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> + <para id="x_11e">Since Mercurial treats history as + accumulative&emdash;every change builds on top of all changes + that preceded it&emdash;you generally can't just make disastrous + changes disappear. The one exception is when you've just + committed a change, and it hasn't 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 + <xref linkend="sec:undo:rollback"/>.</para> <para id="x_11f">After you've pushed a bad change to another repository, you <emphasis>could</emphasis> still use <command role="hg-cmd">hg diff -r b788b405e141 -r 4ce9d0754af3 en/ch09-hook.xml --- a/en/ch09-hook.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch09-hook.xml Thu Mar 26 21:22:03 2009 -0700 @@ -17,9 +17,9 @@ <sect1> <title>An overview of hooks in Mercurial - Here is a brief list of the hooks that Mercurial supports. - We will revisit each of these hooks in more detail later, in - section . + Here is a brief list of the hooks that Mercurial + supports. We will revisit each of these hooks in more detail + later, in . changegroup: This @@ -393,12 +393,12 @@ before both. - It is a good idea to use a somewhat descriptive extension - when you define a new hook. This will help you to remember - what the hook was for. If the hook fails, you'll get an error - 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 It is a good idea to use a somewhat descriptive + extension when you define a new hook. This will help you to + remember what the hook was for. If the hook fails, you'll get + an error 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 for an example). @@ -1094,7 +1094,7 @@ mapping committer names to user names. - Recall from section Recall from above that the user that runs the Mercurial process on the server is also the one that will run the processmail @@ -1250,10 +1250,9 @@ sources of changesets to consider. This lets you limit notify to only sending out email about changes that remote users pushed into - this repository via a server, for example. See section - for the sources you can - specify here. + this repository via a server, for example. See + for the sources you + can specify here. @@ -1502,23 +1501,23 @@ role="hg-cmd">hg unbundle. - source: A string. The - source of these changes. See section source: A + string. The source of these changes. See for details. - url: A URL. The location - of the remote repository, if known. See section for more - information. + url: A URL. The + location of the remote repository, if known. See for more information. - See also: incoming (section - ), prechangegroup (section See also: incoming (), prechangegroup (), pretxnchangegroup (section pretxnchangegroup () @@ -1548,9 +1547,10 @@ - See also: precommit - (section ), pretxncommit (section See also: precommit (), pretxncommit () @@ -1566,10 +1566,10 @@ each added changeset. - You can use this hook for the same purposes as the - changegroup hook (section ); it's simply - more convenient sometimes to run a hook once per group of + You can use this hook for the same purposes as + the changegroup hook (); it's simply more + convenient sometimes to run a hook once per group of changesets, while other times it's handier once per changeset. @@ -1580,23 +1580,23 @@ ID of the newly added changeset. - source: A string. The - source of these changes. See section source: A + string. The source of these changes. See for details. - url: A URL. The location - of the remote repository, if known. See section for more - information. + url: A URL. The + location of the remote repository, if known. See for more information. - See also: changegroup - (section ) prechangegroup (section See also: changegroup () prechangegroup (), pretxnchangegroup (section pretxnchangegroup () @@ -1624,7 +1624,7 @@ source: A string. The - source of the of the operation (see section ). If a remote client pulled changes from this repository, source will be @@ -1636,15 +1636,15 @@ client performed. - url: A URL. The location - of the remote repository, if known. See section for more - information. + url: A URL. The + location of the remote repository, if known. See for more information. - See also: preoutgoing - (section ) + See also: preoutgoing () @@ -1674,22 +1674,22 @@ source: A string. The - source of these changes. See section for details. - url: A URL. The location - of the remote repository, if known. See section for more - information. + url: A URL. The + location of the remote repository, if known. See for more information. - See also: changegroup - (section ), incoming (section ), , pretxnchangegroup (section See also: changegroup (), incoming (), pretxnchangegroup () @@ -1727,9 +1727,9 @@ directory will become the parents of the new changeset. - See also: commit (section - ), pretxncommit (section See also: commit + (), pretxncommit () @@ -1749,26 +1749,25 @@ Parameters to this hook: - source: A string. The - source of the operation that is attempting to obtain - changes from this repository (see section source: A + string. The source of the operation that is attempting to + obtain changes from this repository (see ). See the documentation for the source parameter to the - outgoing hook, in section + outgoing hook, in , for possible values - of - this parameter. + of this parameter. - url: A URL. The location - of the remote repository, if known. See section for more - information. + url: A URL. The + location of the remote repository, if known. See for more information. - See also: outgoing (section - ) + See also: outgoing () @@ -1800,15 +1799,16 @@ - If the tag to be created is revision-controlled, the - precommit and pretxncommit hooks (sections If the tag to be created is + revision-controlled, the precommit and pretxncommit hooks ( and ) will also be run. - See also: tag (section - ) + See also: tag + () @@ -1856,23 +1856,23 @@ role="hg-cmd">hg unbundle. - source: A string. The - source of these changes. See section source: A + string. The source of these changes. See for details. - url: A URL. The location - of the remote repository, if known. See section for more - information. + url: A URL. The + location of the remote repository, if known. See for more information. - See also: changegroup - (section ), incoming (section See also: changegroup (), incoming (), prechangegroup (section prechangegroup () @@ -1919,8 +1919,9 @@ - See also: precommit - (section ) + See also: precommit () @@ -1928,32 +1929,32 @@ <literal role="hook">preupdate</literal>&emdash;before updating or merging working directory - This controlling hook is run before an update or merge of - the working directory begins. It is run only if Mercurial's - normal pre-update checks determine that the update or merge - can proceed. If the hook succeeds, the update or merge may - proceed; if it fails, the update or merge does not start. + This controlling hook is run before an update + or merge of the working directory begins. It is run only if + Mercurial's normal pre-update checks determine that the update + or merge can proceed. If the hook succeeds, the update or + merge may proceed; if it fails, the update or merge does not + start. Parameters to this hook: - parent1: A changeset ID. - The ID of the parent that the working directory is to be - updated to. If the working directory is being merged, it - will not change this parent. + parent1: A + changeset ID. The ID of the parent that the working + directory is to be updated to. If the working directory + is being merged, it will not change this parent. - parent2: A changeset ID. - Only set if the working directory is being merged. The ID - of the revision that the working directory is being merged - with. + parent2: A + changeset ID. Only set if the working directory is being + merged. The ID of the revision that the working directory + is being merged with. - See also: update (section - ) - + See also: update + () @@ -1988,8 +1989,8 @@ linkend="sec:hook:commit"/>) is run before this hook. - See also: pretag (section - ) + See also: pretag + () @@ -2023,7 +2024,7 @@ See also: preupdate - (section ) + () diff -r b788b405e141 -r 4ce9d0754af3 en/ch10-template.xml --- a/en/ch10-template.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch10-template.xml Thu Mar 26 21:22:03 2009 -0700 @@ -107,7 +107,7 @@ escape sequence, 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 for more details + for more details of escape sequences. A template that prints a fixed string of text all the time @@ -121,11 +121,10 @@ been replaced in the output with the description of each changeset. Every time Mercurial finds text enclosed in curly braces ({ and - }), it will try to replace the braces - and text with the expansion of whatever is inside. To print a - literal curly brace, you must escape it, as described in section - . + }), it will try to replace the + braces and text with the expansion of whatever is inside. To + print a literal curly brace, you must escape it, as described in + . @@ -149,7 +148,7 @@ Date information. The date when the changeset was committed. This is not human-readable; you must pass it through a filter that will render it - appropriately. See section 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 @@ -197,8 +196,7 @@ As we noted above, the date keyword does not produce human-readable output, so we must treat it specially. This involves using a filter, about which more - in section . + in . &interaction.template.simple.datekeyword; diff -r b788b405e141 -r 4ce9d0754af3 en/ch11-mq.xml --- a/en/ch11-mq.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch11-mq.xml Thu Mar 26 21:22:03 2009 -0700 @@ -36,7 +36,7 @@ When you have few changes to maintain, it is easy to manage a single patch using the standard diff and - patch programs (see section patch programs (see for a discussion of these tools). Once the number of changes grows, it starts to make sense to maintain patches as discrete chunks of @@ -241,7 +241,7 @@ represented by one deletion and one insertion. We will return to some of the more subtle aspects of patches - later (in section ), but you + later (in ), but you should have enough information now to use MQ. @@ -400,17 +400,18 @@ knows about, or manages, a popped patch, 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 illustrates the difference between applied and tracked patches. - - XXX - add textApplied and - unapplied patches in the MQ patch - stack - +

+ Applied and unapplied patches in the MQ patch + stack + + + XXX add text + + You can reapply an unapplied, or popped, patch using the qpush command. This @@ -441,8 +442,7 @@ role="hg-ext-mq-cmd-qpop-opt">-a option to qpop causes it to pop all applied patches. (For some more ways to push and pop many patches, - see section - below.) + see below.) &interaction.mq.tutorial.qpush-a; @@ -700,8 +700,7 @@ If your patch used to apply cleanly, and no longer does because you've changed the underlying code that your patches are based on, Mercurial Queues can help; see - section for details. + for details. Unfortunately, there aren't any great techniques for dealing with rejected hunks. Most often, you'll need to view @@ -941,7 +940,7 @@ latest series of changes? hg email qbase:qtip (Don't know what patchbombing is? See - section .) + .) Need to see all of the patches since foo.patch that have touched files in a @@ -980,7 +979,7 @@ role="hg-ext-mq">qpush it again, the changeset that represents the patch after the pop/push will have a different identity than the changeset - that represented the hash beforehand. See section for information as to why this is. @@ -1132,7 +1131,7 @@ hundreds of files across dozens of directories, a single invocation of filterdiff can generate a smaller patch that only touches files whose names match a - particular glob pattern. See section for another example. @@ -1170,7 +1169,7 @@ 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 , + described in , particularly diffstat and filterdiff. The former will give you a quick idea of what changes your patch @@ -1292,7 +1291,7 @@ Once you have this hunk, you can concatenate it onto the end of your destination patch and continue with the remainder - of section . + of . diff -r b788b405e141 -r 4ce9d0754af3 en/ch12-mq-collab.xml --- a/en/ch12-mq-collab.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch12-mq-collab.xml Thu Mar 26 21:22:03 2009 -0700 @@ -435,7 +435,7 @@ 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 . If you do + discussed in . If you do so, you'll quickly discover that using the hg diff command to look at the history of changes to @@ -504,7 +504,7 @@ The extdiff extension is useful for more than merely improving the presentation of MQ - patches. To read more about it, go to section . diff -r b788b405e141 -r 4ce9d0754af3 en/ch13-hgext.xml --- a/en/ch13-hgext.xml Thu Mar 26 21:07:39 2009 -0700 +++ b/en/ch13-hgext.xml Thu Mar 26 21:22:03 2009 -0700 @@ -15,13 +15,13 @@ plugins). We've already discussed a few of these extensions in earlier chapters. - Section + covers the fetch extension; this combines pulling new changes and merging them with local changes into a single command, fetch. - In chapter , we covered + In , we covered several extensions that are useful for hook-related functionality: acl adds access control lists; The Mercurial Queues patch management extension is so invaluable that it merits two chapters and an appendix all - to itself. Chapter covers the - basics; chapter covers the + basics; discusses advanced topics; - and appendix goes into detail on + and goes into detail on each command. @@ -45,7 +45,7 @@ machinery you'll need to know about if you want to write an extension of your own. - In section , + In , we'll discuss the possibility of huge performance improvements using the inotify extension. @@ -183,7 +183,7 @@ Make sure that you have the Mercurial Queues extension, mq, enabled. If - you've never used MQ, read section to get started quickly. @@ -353,7 +353,7 @@ you can easily work around this with a little scripting. For an example of such scripting in action with the mq extension and the - interdiff command, see section interdiff command, see . @@ -502,7 +502,7 @@ use. The default behaviour is to send unified diffs - (see section for a + (see for a description of the format), one per message. You can send a binary bundle instead with the