comparison en/ch09-undo.xml @ 739:a13813534ccd

Fix all xref to figs

738:1a3d882149fd

	  backout</command> command has done.
	&interaction.backout.simple.log; Notice that the new changeset
	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
	view of the change history.  As you can see, the history is
	nice and linear.</para>

      <informalfigure id="fig.undo.backout">
	<mediaobject><imageobject><imagedata
				    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>
	      command</para></caption></mediaobject>
	
      </informalfigure>

    </sect2>
    <sect2>
      <title>Backing out a non-tip change</title>

	second.</para>

      &interaction.backout.non-tip.cat;

      <para>As the graphical history in figure <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
	commits automatically).  Before Mercurial begins the backout
	process, it first remembers what the current parent of the

      <para>% TODO: to me it looks like mercurial doesn't commit the
	second merge automatically!</para>

      <informalfigure id="fig.undo.backout-non-tip">
	<mediaobject><imageobject><imagedata
				    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>
	      command</para></caption></mediaobject>
      </informalfigure>

      <para>The result is that you end up <quote>back where you
	  were</quote>, only with some extra history that undoes the
	effect of the changeset you wanted to back out.</para>

      &interaction.backout.manual.log;

      <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
	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">
	<mediaobject><imageobject><imagedata
				    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>
	      command</para></caption></mediaobject>
	
      </informalfigure>

      <para>After the <command role="hg-cmd">hg backout</command>
	command has completed, it leaves the new
	<quote>backout</quote> changeset as the parent of the working

      &interaction.backout.manual.merge;

      <para>Afterwards, the graphical history of our repository looks
	like figure
	<xref linkend="fig.undo.backout-manual-merge"/>.</para>

      <informalfigure id="fig.undo.backout-manual-merge">
	<mediaobject><imageobject><imagedata
				    fileref="images/undo-manual-merge.png"/></imageobject><textobject><phrase>XXX 
	      add text</phrase></textobject><caption><para>Manually
	      merging a backout change</para></caption></mediaobject>
	
      </informalfigure>

    </sect2>
    <sect2>
      <title>Why <command role="hg-cmd">hg backout</command> works as

739:a13813534ccd

	  backout</command> command has done.
	&interaction.backout.simple.log; Notice that the new changeset
	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
	  endterm="fig.undo.backout.caption" 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">
        <mediaobject>
          <imageobject><imagedata fileref="images/undo-simple.png"/>
          </imageobject>
          <textobject><phrase>XXX add text</phrase></textobject>
          <caption><para id="fig.undo.backout.caption">Backing out
            a change using the 
            <command role="hg-cmd">hg backout</command>
            command</para></caption>
      </mediaobject>
      </informalfigure>

    </sect2>
    <sect2>
      <title>Backing out a non-tip change</title>

	second.</para>

      &interaction.backout.non-tip.cat;

      <para>As the graphical history in figure <xref
	  endterm="fig.undo.backout-non-tip.caption"
	  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
	process, it first remembers what the current parent of the

      <para>% TODO: to me it looks like mercurial doesn't commit the
	second merge automatically!</para>

      <informalfigure id="fig.undo.backout-non-tip">
        <mediaobject>
          <imageobject><imagedata fileref="images/undo-non-tip.png"/>
          </imageobject>
          <textobject><phrase>XXX add text</phrase></textobject>
          <caption><para id="fig.undo.backout-non-tip.caption">Automated
            backout of a non-tip change using the
            <command role="hg-cmd">hg backout</command> command</para></caption>
        </mediaobject>
      </informalfigure>

      <para>The result is that you end up <quote>back where you
	  were</quote>, only with some extra history that undoes the
	effect of the changeset you wanted to back out.</para>

      &interaction.backout.manual.log;

      <para>Again, it's easier to see what has happened by looking at
	a graph of the revision history, in figure <xref
	  endterm="fig.undo.backout-manual.caption"
	  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">
        <mediaobject>
          <imageobject><imagedata fileref="images/undo-manual.png"/>
          </imageobject>
          <textobject><phrase>XXX add text</phrase></textobject>
          <caption><para id="fig.undo.backout-manual.caption">Backing out a
            change using the <command role="hg-cmd">hg backout</command>
            command</para></caption>
        </mediaobject>
      </informalfigure>

      <para>After the <command role="hg-cmd">hg backout</command>
	command has completed, it leaves the new
	<quote>backout</quote> changeset as the parent of the working

      &interaction.backout.manual.merge;

      <para>Afterwards, the graphical history of our repository looks
	like figure
	<xref endterm="fig.undo.backout-manual-merge.caption"
	  linkend="fig.undo.backout-manual-merge"/>.</para>

      <informalfigure id="fig.undo.backout-manual-merge">
        <mediaobject>
          <imageobject><imagedata fileref="images/undo-manual-merge.png"/>
          </imageobject>
          <textobject><phrase>XXX add text</phrase></textobject>
          <caption><para id="fig.undo.backout-manual-merge.caption">Manually
            merging a backout change</para></caption>
        </mediaobject>
      </informalfigure>

    </sect2>
    <sect2>
      <title>Why <command role="hg-cmd">hg backout</command> works as