CINXE.COM

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"> <head> <title> Quick Guide To Using Mercurial [CSS Working Group Wiki] </title> <meta name="generator" content="DokuWiki"/> <meta name="robots" content="index,follow"/> <meta name="keywords" content="tools,hg"/> <link rel="search" type="application/opensearchdescription+xml" href="/lib/exe/opensearch.php" title="CSS Working Group Wiki"/> <link rel="start" href="/"/> <link rel="contents" href="/tools/hg?do=index" title="Sitemap"/> <link rel="manifest" href="/lib/exe/manifest.php"/> <link rel="alternate" type="application/rss+xml" title="Recent Changes" href="/feed.php"/> <link rel="alternate" type="application/rss+xml" title="Current namespace" href="/feed.php?mode=list&ns=tools"/> <link rel="alternate" type="text/html" title="Plain HTML" href="/_export/xhtml/tools/hg"/> <link rel="alternate" type="text/plain" title="Wiki Markup" href="/_export/raw/tools/hg"/> <link rel="canonical" href="https://wiki.csswg.org/tools/hg"/> <link rel="stylesheet" href="/lib/exe/css.php?t=csswg&tseed=5b65c073d422eaa3ad2a9971d5b57f38"/>  <script >/*<![CDATA[*/var NS='tools';var JSINFO = {"id":"tools:hg","namespace":"tools","ACT":"show","useHeadingNavigation":1,"useHeadingContent":1}; /*!]]>*/</script> <script src="/lib/exe/jquery.php?tseed=f0349b609f9b91a485af8fd8ecd4aea4" defer="defer">/*<![CDATA[*/ /*!]]>*/</script> <script src="/lib/exe/js.php?t=csswg&tseed=5b65c073d422eaa3ad2a9971d5b57f38" defer="defer">/*<![CDATA[*/ /*!]]>*/</script>  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport"> <link rel="shortcut icon" href="/lib/tpl/csswg/images/favicon.ico" /> </head> <body class=" ns_tools id_hg"><div class="dokuwiki"> <div class="stylehead"> <div class="header"> <div class="logo"> <a href="/main" name="dokuwiki__top" id="dokuwiki__top" accesskey="h" title="[ALT+H]">CSS Working Group Wiki</a> </div> <div class="clearer"></div> </div> <div class="bar" id="bar__top"> <div class="bar-left site-sections" id="bar__topleft"> <a href="/">Home</a> <a href="/spec">Specs</a> <a href="/ideas">Ideas</a> <a href="/test">Testing</a> <a href="/wiki">About</a> </div> <div class="bar-right" id="bar__topright"> <form action="/main" method="get" role="search" class="search doku_form" id="dw__search" accept-charset="utf-8"><input type="hidden" name="do" value="search" /><input type="hidden" name="id" value="tools:hg" /><div class="no"><input name="q" type="text" class="edit" title="[F]" accesskey="f" placeholder="Search" autocomplete="on" id="qsearch__in" value="" /><button value="1" type="submit" title="Search">Search</button><div id="qsearch__out" class="ajax_qsearch JSpopup"></div></div></form> </div> <div class="clearer"></div> </div> <div class="breadcrumbs"> <span class="bchead">You are here: </span><span class="home"><bdi><a href="/main" class="wikilink1" title="main" data-wiki-id="main">CSS Working Group Wiki</a></bdi></span> » <bdi><a href="/tools" class="wikilink1" title="tools" data-wiki-id="tools">CSSWG Tools</a></bdi> » <bdi><a href="/tools/hg" class="wikilink1" title="tools:hg" data-wiki-id="tools:hg">Quick Guide To Using Mercurial</a></bdi> </div> </div> <div class="page">   <div id="dw__toc" class="dw__toc"> <h3 class="toggle">Table of Contents</h3> <div> <ul class="toc"> <li class="level1"><div class="li"><a href="#quick-guide-to-using-mercurial">Quick Guide To Using Mercurial</a></div> <ul class="toc"> <li class="level2"><div class="li"><a href="#what-is-a-distributed-version-control-system">What Is A "Distributed" Version Control System?</a></div></li> <li class="level2"><div class="li"><a href="#getting-started">Getting Started</a></div> <ul class="toc"> <li class="level3"><div class="li"><a href="#installing-mercurial">Installing Mercurial</a></div></li> <li class="level3"><div class="li"><a href="#setting-up-mercurial-preferences">Setting Up Mercurial Preferences</a></div></li> <li class="level3"><div class="li"><a href="#initial-download-of-the-central-repository">Initial Download Of The Central Repository</a></div></li> <li class="level3"><div class="li"><a href="#obtaining-write-access">Obtaining Write Access</a></div></li> </ul> </li> <li class="level2"><div class="li"><a href="#working-with-mercurial">Working With Mercurial</a></div> <ul class="toc"> <li class="level3"><div class="li"><a href="#quick-start">Quick Start</a></div></li> <li class="level3"><div class="li"><a href="#table-of-contents">Table of Contents</a></div></li> <li class="level3"><div class="li"><a href="#examining-your-changes">Examining Your Changes</a></div></li> <li class="level3"><div class="li"><a href="#synchronizing-changes">Synchronizing Changes</a></div></li> <li class="level3"><div class="li"><a href="#managing-files">Managing Files</a></div></li> <li class="level3"><div class="li"><a href="#working-offline">Working Offline</a></div></li> <li class="level3"><div class="li"><a href="#archaeology">Archaeology</a></div></li> </ul> </li> <li class="level2"><div class="li"><a href="#cvssubversion-cheat-sheet">CVS / Subversion Cheat Sheet</a></div></li> <li class="level2"><div class="li"><a href="#wait-i-had-work-that-i-didn-t-commit-in-the-old-cvssubversion-repository">Wait, I Had Work That I Didn't Commit In The Old CVS/Subversion Repository</a></div></li> <li class="level2"><div class="li"><a href="#more-information">More Information</a></div></li> <li class="level2"><div class="li"><a href="#still-need-help">Still Need Help?</a></div></li> </ul></li> </ul> </div> </div>  <h1 class="sectionedit1" id="quick-guide-to-using-mercurial">Quick Guide To Using Mercurial</h1> <div class="level1"> <p> The <abbr title="Cascading Style Sheets">CSS</abbr> Working Group has adopted Mercurial as the repository technology for storing our test suites and editor's drafts of specifications. Mercurial is a modern, distributed version control system. This guide is intended to serve as a quick start for those setting up access to the repository for the first time, not to serve as an in-depth tutorial. It is expected that the reader have some familiarity with centrally managed version control systems like CVS or Subversion. </p> <p> This guide will focus on the command-line Mercurial client <code>hg</code>, but there are <abbr title="Graphical User Interface">GUI</abbr>-based Mercurial clients available for many platforms. While users of a <abbr title="Graphical User Interface">GUI</abbr> client obviously won't be using the command line, the same basic operations apply. </p> </div> <h2 class="sectionedit2" id="what-is-a-distributed-version-control-system">What Is A "Distributed" Version Control System?</h2> <div class="level2"> <p> A standard version control system has a single central repository, usually hosted on a server. Users “checkout” files from the central server, make changes, and “commit” them back to the server. Users keep a working copy of the files on their own system, but all the revision history lives in the central repository. </p> <p> With a distributed version control system, every user has their own repository, complete with the entire revision history. In fact, they can have as many copies of the repository as they want. Users can add or change files and commit them to their own repository at will, even without access to a central server at the time. When users are ready to share their work with others, they “push” their changes from their own repository to a central server. When they want to see others' work, they “pull” changes from the central server to their own repository. </p> </div> <h2 class="sectionedit3" id="getting-started">Getting Started</h2> <div class="level2"> </div> <h3 class="sectionedit4" id="installing-mercurial">Installing Mercurial</h3> <div class="level3"> <p> You need to first <a href="/tools/hg/install" class="wikilink1" title="tools:hg:install" data-wiki-id="tools:hg:install">install Mercurial on your system</a>, if you haven't already. Our server is running version 3.2.1. Earlier versions should work, but we recommend using the latest client. </p> <p> You can see if you already have Mercurial installed by opening up a command shell and typing: </p> <pre class="code">hg --version</pre> <p> You should see something like: </p> <pre class="code">Mercurial Distributed SCM (version 3.2) (see http://mercurial.selenic.com for more information)</pre> <p> As long as the version number you see is 1.8 or higher, you have a new enough version of Mercurial. </p> </div> <h3 class="sectionedit5" id="setting-up-mercurial-preferences">Setting Up Mercurial Preferences</h3> <div class="level3"> <p> Note: <a href="http://www.selenic.com/mercurial/hgrc.5.html" class="urlextern" title="http://www.selenic.com/mercurial/hgrc.5.html" rel="ugc nofollow">Detailed instructions for the config file</a> are available, but for now, this guide will focus only on setting up the basics. </p> <p> N.B.: The instructions in the rest of this wiki page assume you've configured Mercurial as described here. For instance, the rest of this page assumes that you have the <code>rebase</code> extension enabled. </p> <p> Create a file in your home directory called <code>.hgrc</code>, or <code>%USERPROFILE%\mercurial.ini</code> on Windows. Give it the following contents, but with your name, email, username, password, and editor replaced appropriately: </p> <pre class="code">[ui] username = Your Full Name <your@email.address.example> merge = internal:merge editor = your_favorite_text_editor # optional -- defaults to $EDITOR or vi [diff] git = 1 showfunc = 1 unified = 8 [defaults] commit = -v [extensions] rebase = mq = graphlog = progress = bookmarks = color = [auth] # CSSWG Test & Draft Repositories csswg.prefix = https://hg.csswg.org/ csswg.username = your_csswg.org_username csswg.password = your_csswg.org_password #optional # FXTF Draft Repository fxtf.prefix = https://hg.fxtf.org/ fxtf.username = your_csswg.org_username fxtf.password = your_csswg.org_password #optional # CSS-Houdini TF Draft Repository houdini.prefix = https://hg.css-houdini.org/ houdini.username = your_csswg.org_username houdini.password = your_csswg.org_password #optional # Other W3C Spec Repositories w3c.prefix = https://dvcs.w3.org/hg/ w3c.username = your_w3.org_username w3c.password = your_w3.org_password #optional</pre> <p> <strong>IMPORTANT</strong>: If you will be pushing changes to the CSSWG Test Repository, and you use the Full Name <email> format for the username in the [ui] section, be sure the email address you enter is the same as that associated with your wiki account. Alternatively, replace “<code>Your Full Name <a href="mailto:your@email.address.example" class="mail" title="your@email.address.example">your@email.address.example</a></code>” with “<code>your_csswg.org_username</code>”. </p> <div class="plugin_note noteclassic">TortoiseHg will create the ini file automatically on Windows, and will later import any settings manually added there to the Global Settings dialog. </div><div class="plugin_note noteclassic"><strong>Avoiding Password Requests</strong> <p> Putting your password into <code>.hgrc</code> will prevent the server from asking your username and password every time you push. If you don't want to store your password in the config file, you can <a href="http://mercurial.selenic.com/wiki/KeyringExtension" class="urlextern" title="http://mercurial.selenic.com/wiki/KeyringExtension" rel="ugc nofollow">install the Keyring extension</a> and omit the password line. The Keyring extension will prompt you for your password the first time it is needed and store it securely in your system keyring. </p> </div> <p> If you access the web through a proxy, you'll also need to set that up now. <a href="http://www.selenic.com/mercurial/hgrc.5.html#http-proxy" class="urlextern" title="http://www.selenic.com/mercurial/hgrc.5.html#http-proxy" rel="ugc nofollow">Details of proxy settings can be found here</a>. </p> <p> You can optionally <a href="http://mercurial.selenic.com/wiki/MergeProgram" class="urlextern" title="http://mercurial.selenic.com/wiki/MergeProgram" rel="ugc nofollow">select an interactive merge program</a> in place of <code>internal:merge</code>. The merge program will help you resolve conflicts between your work and others' after pulling from the central repository. With <code>internal:merge</code>, Mercurial simply leaves conflict markers in your source, similar to Subversion or other systems. </p> <div class="plugin_note noteclassic"><strong> Avoiding Fingerprint Warnings (and improving security)</strong> <p> Depending on your <abbr title="Operating System">OS</abbr> and Mercurial root certificate configuration you may get a warning message about the host certificate when communicating with the central repository. If that happens, please see <a href="https://www.mercurial-scm.org/wiki/CACertificates#Configuration_of_HTTPS_certificate_authorities" class="urlextern" title="https://www.mercurial-scm.org/wiki/CACertificates#Configuration_of_HTTPS_certificate_authorities" rel="ugc nofollow">the instructions on the Mercurial wiki</a>. </p> </div> </div> <h3 class="sectionedit6" id="initial-download-of-the-central-repository">Initial Download Of The Central Repository</h3> <div class="level3"> <p> The first step is to download the central repository to your own machine. </p> <p> In a shell/terminal window, set your current directory to wherever you want hg to create the folders for each repository, and then issue <code>hg clone</code> commands for each repository. e.g. </p> <p> <strong> CSSWG Test Suite Repository </strong> </p> <pre class="code">cd /mirror/hg/hg.csswg.org/ #just an example, pick your own local directory hg clone https://hg.csswg.org/test/</pre> <p> You should see some text like: </p> <pre class="code">destination directory: test requesting all changes adding changesets adding manifests adding file changes added 3289 changesets with 85693 changes to 50963 files updating to branch default cloning subrepo tools/w3ctestlib from http://hg.csswg.org/dev/w3ctestlib requesting all changes adding changesets adding manifests adding file changes added 95 changesets with 245 changes to 31 files 21921 files updated, 0 files merged, 0 files removed, 0 files unresolved</pre> <p> <strong> Resources directory (for script tests) </strong> </p> <p> This directory contains testharness.js which is needed if you'll be running script tests locally. This is maintained in a separate repository in GitHub. See the <a href="https://help.github.com/articles/set-up-git/" class="urlextern" title="https://help.github.com/articles/set-up-git/" rel="ugc nofollow">instructions on GitHub</a> for setting up git, then: </p> <pre class="code">cd / #not required, but resources directory is located at root level in repository git clone https://github.com/w3c/testharness.js.git resources</pre> <p> <strong> CSSWG Draft Repository </strong> </p> <pre class="code">cd /mirror/hg.csswg.org/ #just an example, pick your own local directory hg clone https://hg.csswg.org/drafts/</pre> <p> <strong> FXTF Draft Repository </strong> </p> <pre class="code">hg clone https://hg.fxtf.org/drafts/ </pre> <p> <strong> Fullscreen Spec </strong> </p> <pre class="code">hg clone https://dvcs.w3.org/hg/fullscreen/</pre> <p> Once this command is complete, you now have a working directory that also contains your very own local repository (in a hidden directory named <code>.hg</code>). Your local repository is, at this point, an identical clone of the central repository. You can begin making changes in your working directory at will. In general, do not modify the contents of the <code>.hg</code> directory directly. </p> <p> Note: By default, the working directory name will match the name of the central repository on the server (the last path component of the <abbr title="Uniform Resource Locator">URL</abbr>). If you want to use a different name for your working directory, enter it at the end of the clone command, e.g.: </p> <pre class="code">hg clone https://hg.csswg.org/drafts/ csswg</pre> </div> <h3 class="sectionedit7" id="obtaining-write-access">Obtaining Write Access</h3> <div class="level3"> <p> All of our repositories are readable by anyone. Permission to write (i.e. push) into the repositories is restricted to certain users. </p> <p> Access to the repositories on hg.csswg.org, hg.fxtf.org, and hg.css-houdini.org is based on your account for <a href="http://test.csswg.org/shepherd/" class="urlextern" title="http://test.csswg.org/shepherd/" rel="ugc nofollow">Shepherd</a> and this wiki (user accounts are shared between systems). By default, all CSSWG members should have write access to the Test Suite Repository. Other contributors to the Test Suite Repository need to ask for access. If you already have an account on this wiki, log in to Shepherd and submit a request to modify assets on the <a href="https://test.csswg.org/shepherd/login/account/access/" class="urlextern" title="https://test.csswg.org/shepherd/login/account/access/" rel="ugc nofollow">Repository Access</a> page. You will receive an email once repository access has been granted. If you don't already have an account, you can <a href="https://test.csswg.org/shepherd/register/" class="urlextern" title="https://test.csswg.org/shepherd/register/" rel="ugc nofollow">register for an account on Shepherd</a>. </p> <p> In addition to the Test Suite Repository, all CSSWG members should have write access to the CSSWG Draft Repository, all CSSWG and SVGWG members should have write access to the FXTF and <abbr title="Cascading Style Sheets">CSS</abbr>-Houdini TF Draft Repositories. If you need write access and don't already have it, you can submit a request on the <a href="https://drafts.csswg.org/login/account/access/" class="urlextern" title="https://drafts.csswg.org/login/account/access/" rel="ugc nofollow">CSSWG Repository Access</a>, <a href="https://drafts.fxtf.org/login/account/access/" class="urlextern" title="https://drafts.fxtf.org/login/account/access/" rel="ugc nofollow">FXTF Repository Access</a>, or <a href="https://drafts.css-houdini.org/login/account/access/" class="urlextern" title="https://drafts.css-houdini.org/login/account/access/" rel="ugc nofollow">CSS-Houdini TF Repository Access</a> pages. </p> <p> Access to the repositories on dvcs.w3.org is controlled by your <abbr title="World Wide Web Consortium">W3C</abbr> user account. If you're not a member of the appropriate group and need write access, please email <a href="mailto:mailto:peter.linss@hp.com" class="mail" title="mailto:peter.linss@hp.com">Peter</a> or <a href="mailto:mailto::sysreq@w3.org" class="mail" title="mailto::sysreq@w3.org">sysreq</a>. </p> </div> <h2 class="sectionedit8" id="working-with-mercurial">Working With Mercurial</h2> <div class="level2"> <p> Once you have a created a working directory by cloning the central repository onto your machine, you are free to edit the files in the working directory with your favorite tools. Mercurial will automatically detect edits made to any files within your working directory. However, when moving, renaming, copying, or deleting files, these operations need to be done <a href="#manging-files" title="tools:hg ↵" class="wikilink1">via Mercurial</a> rather than your standard operating system operations. This enables Mercurial to track those changes in addition to edits within the files. </p> <p> In general, working with Mercurial is very similar to working with CVS or Subversion. The overall operations when dealing with merging and conflicts are conceptually the same, only with Mercurial the operations are broken out into discrete steps that can be done independently instead of all at once during updates. You can keep your overall workflow as similar as possible to CVS or Subversion by working in small increments and synchronizing with the central repository frequently. The more frequently you synchronize, the less likely you are to encounter merge issues. </p> </div> <h3 class="sectionedit9" id="quick-start">Quick Start</h3> <div class="level3"> <p> In a nutshell, your workflow will be: </p> <ol> <li class="level1"><div class="li"> Synchronize my local repository and its working directory with the central repository</div> </li> <li class="level1"><div class="li"> Make edits in my working directory</div> </li> <li class="level1"><div class="li"> Commit my work into my local repository</div> </li> <li class="level1"><div class="li"> Send my changes back to the central repository</div> </li> </ol> <p> You can do that with the following commands: </p> <pre class="code">hg pull --rebase <make edits> hg commit -m "[css-foo] commit message describing your work" hg push</pre> <p> (Always include the shortname of the <abbr title="specification">spec</abbr> you're committing work for, just you would when sending email.) </p> <p> <img src="/lib/images/smileys/exclaim.svg" class="icon smiley" alt=":!:" /> Note that (unlike CVS or Subversion) these Mercurial commands operate on the entire repository, not just the directory you're in. You can commit only changes in your current working directory by appending “.”: </p> <pre class="code">hg pull --rebase <make edits> hg commit -m "[css-foo] commit message describing your work" . hg push</pre> <p> Congratulations, you're now a Mercurial user. </p> <p> See the rest of this document if you ran into any issues, for more operations, and to have a better understanding of what's going on here. </p> </div> <h3 class="sectionedit10" id="table-of-contents">Table of Contents</h3> <div class="level3"> <ul> <li class="level1 node"><div class="li"> <a href="#examining-your-changes" title="tools:hg ↵" class="wikilink1">Examining Your Changes</a></div> <ul> <li class="level2"><div class="li"> <a href="#listing-changed-fileshg-status" title="tools:hg ↵" class="wikilink1">Listing Changed Files: hg status</a></div> </li> <li class="level2"><div class="li"> <a href="#diffs-and-patcheshg-diff" title="tools:hg ↵" class="wikilink1">Diffs and Patches: hg diff</a></div> </li> <li class="level2"><div class="li"> <a href="#reverting-changeshg-revert" title="tools:hg ↵" class="wikilink1">Reverting Changes: hg revert</a></div> </li> </ul> </li> <li class="level1 node"><div class="li"> <a href="#synchronizing-changes" title="tools:hg ↵" class="wikilink1">Synchronizing Changes</a></div> <ul> <li class="level2"><div class="li"> <a href="#updating-your-repositoryhg-pull" title="tools:hg ↵" class="wikilink1">Updating Your Repository: hg pull</a></div> </li> <li class="level2"><div class="li"> <a href="#submitting-your-changeshg-commit-and-hg-push" title="tools:hg ↵" class="wikilink1">Submitting Your Changes: hg commit and hg push</a></div> </li> <li class="level2"><div class="li"> <a href="#merging-branches-of-workhg-merge" title="tools:hg ↵" class="wikilink1">Merging Branches of Work: hg merge</a></div> </li> <li class="level2"><div class="li"> <a href="#resolving-conflictshg-resolve" title="tools:hg ↵" class="wikilink1">Resolving Conflicts: hg resolve</a></div> </li> </ul> </li> <li class="level1 node"><div class="li"> <a href="#managing-files" title="tools:hg ↵" class="wikilink1">Managing Files</a></div> <ul> <li class="level2"><div class="li"> <a href="#adding-new-fileshg-add" title="tools:hg ↵" class="wikilink1">Adding New Files: hg add</a></div> </li> <li class="level2"><div class="li"> <a href="#removing-fileshg-remove" title="tools:hg ↵" class="wikilink1">Removing Files: hg remove</a></div> </li> <li class="level2"><div class="li"> <a href="#moving-and-renaming-fileshg-move" title="tools:hg ↵" class="wikilink1">Moving and Renaming Files: hg move</a></div> </li> <li class="level2"><div class="li"> <a href="#copies-and-forkshg-copy" title="tools:hg ↵" class="wikilink1">Copies and Forks: hg copy</a></div> </li> </ul> </li> <li class="level1 node"><div class="li"> <a href="#working-offline" title="tools:hg ↵" class="wikilink1">Working Offline</a></div> <ul> <li class="level2"><div class="li"> <a href="#pull-vs-update" title="tools:hg ↵" class="wikilink1">Pull vs. Update</a></div> </li> <li class="level2"><div class="li"> <a href="#commit-vs-push" title="tools:hg ↵" class="wikilink1">Commit vs. Push</a></div> </li> <li class="level2"><div class="li"> <a href="#patch-queues" title="tools:hg ↵" class="wikilink1">Patch Queues</a></div> </li> <li class="level2"><div class="li"> <a href="#rebasing-changesets" title="tools:hg ↵" class="wikilink1">Rebasing Changesets</a></div> </li> <li class="level2"><div class="li"> <a href="#comparing-repositories" title="tools:hg ↵" class="wikilink1">Comparing Repositories</a></div> </li> </ul> </li> <li class="level1"><div class="li"> <a href="#archaeology-and-travelling-through-time" title="tools:hg ↵" class="wikilink1">Archaeology</a></div> </li> </ul> </div> <h3 class="sectionedit11" id="examining-your-changes">Examining Your Changes</h3> <div class="level3"> <p> This section covers: </p> <ul> <li class="level1"><div class="li"> <a href="#listing-changed-fileshg-status" title="tools:hg ↵" class="wikilink1">Listing Changed Files</a></div> </li> <li class="level1"><div class="li"> <a href="#diffs-and-patcheshg-diff" title="tools:hg ↵" class="wikilink1">Diffs and Patches</a></div> </li> <li class="level1"><div class="li"> <a href="#reverting-changeshg-revert" title="tools:hg ↵" class="wikilink1">Reverting Changes</a></div> </li> </ul> </div> <h4 id="listing-changed-fileshg-status">Listing Changed Files: hg status</h4> <div class="level4"> <p> While you are working, you can see an overview of your changes by entering: </p> <pre class="code">hg status # all files in the repository hg status . # only files in this directory</pre> <p> This command will give a list of files in your working directory that differ from the current state of your local repository, marking each with a status code before it's name: </p> <div class="table sectionedit12"><table class="inline"> <tr class="row0"> <td class="col0">M</td><td class="col1">Modified file</td> </tr> <tr class="row1"> <td class="col0">?</td><td class="col1">File not tracked by Mercurial (probably a newly created file)</td> </tr> <tr class="row2"> <td class="col0">!</td><td class="col1">Missing file (deleted, but not removed)</td> </tr> <tr class="row3"> <td class="col0">A</td><td class="col1">Added file</td> </tr> <tr class="row4"> <td class="col0">R</td><td class="col1">Removed file</td> </tr> </table></div> <p> See <a href="#managing-files" title="tools:hg ↵" class="wikilink1">Managing Files</a> for adding, removing, and moving files with Mercurial. </p> <p> This command can be abbreviated as <code>hg stat</code>. </p> </div> <h4 id="diffs-and-patcheshg-diff">Diffs and Patches: hg diff</h4> <div class="level4"> <p> You can also see the actual changes you've made by asking for a diff: </p> <pre class="code">hg diff # all files in the repository hg diff . # only files in this directory</pre> <p> You can create a patch file by redirecting to a file: Append <code> > filename.patch</code> to the diff command, e.g. </p> <pre class="code">hg diff > filename.patch</pre> </div> <h4 id="reverting-changeshg-revert">Reverting Changes: hg revert</h4> <div class="level4"> <p> If you decide you don't want to keep changes you made to a file, or removed a file by mistake, you can restore that file to the last committed version by typing: </p> <pre class="code">hg revert filename</pre> </div> <h3 class="sectionedit13" id="synchronizing-changes">Synchronizing Changes</h3> <div class="level3"> <p> This section covers: </p> <ul> <li class="level1"><div class="li"> <a href="#updating-your-repositoryhg-pull" title="tools:hg ↵" class="wikilink1">Updating Your Repository</a></div> </li> <li class="level1"><div class="li"> <a href="#submitting-your-changeshg-commit-and-hg-push" title="tools:hg ↵" class="wikilink1">Submitting Your Changes</a></div> </li> <li class="level1"><div class="li"> <a href="#merging-branches-of-workhg-merge" title="tools:hg ↵" class="wikilink1">Merging Branches of Work</a></div> </li> <li class="level1"><div class="li"> <a href="#resolving-conflictshg-resolve" title="tools:hg ↵" class="wikilink1">Resolving Conflicts</a></div> </li> </ul> </div> <h4 id="updating-your-repositoryhg-pull">Updating Your Repository: hg pull</h4> <div class="level4"> <p> You can resync your copy of the repository with the central copy by pulling: </p> <pre class="code">hg pull -u</pre> <p> This will pull any new changesets in the central repository and merge them with your local (uncommitted) changes. In most cases, this should Just Work. If both you and someone else have changed the same area in the same file, however, you'll need to resolve the conflict manually. See <a href="#resolving-conflictshg-resolve" title="tools:hg ↵" class="wikilink1">Resolving Conflicts</a>, below. </p> <p> <img src="/lib/images/smileys/question.svg" class="icon smiley" alt=":?:" /> If you have locally-committed changes that you haven't yet pushed to the server, you might see a message about multiple “heads”. In this case you need to <code>hg merge</code>. See <a href="#merging-branches-of-workhg-merge" title="tools:hg ↵" class="wikilink1">Merging</a>, below. </p> <p> <img src="/lib/images/smileys/question.svg" class="icon smiley" alt=":?:" /> If the update fails with the message: “abort: outstanding uncommitted changes”, Mercurial wants you to first commit your uncommitted changes to your local repository. Either commit those changes using <code>hg commit</code>, stash them in your Mercurial Queue (if you're using one), or revert them. Then try again. Note: this shouldn't happen if you're using an up-to-date version of Mercurial. </p> </div> <h4 id="submitting-your-changeshg-commit-and-hg-push">Submitting Your Changes: hg commit and hg push</h4> <div class="level4"> <div class="plugin_note noteclassic">Before you commit your changes, it's a good idea to review the changes with <code>hg status</code>, making sure new files have been <code>hg add</code>ed, deleted files have been <code>hg remove</code>d; and double check an <code>hg diff</code> of your edits. It is also good practice to commit your work often and in small increments, grouping only related changes together. </div> <p> When you're sure you want to submit to the server, <strong>pull first</strong> to synchronize with the central repository (<code>hg pull -u</code>), and resolve any resulting conflicts. Then commit your changes into a local changeset (<code>hg commit</code>) and push your changeset to the central repository (<code>hg push</code>). Like this: </p> <pre class="code">hg pull -u hg commit -m "[css-foo] Commit message explaining your changes" hg push</pre> <p> Always include the shortname of the <abbr title="specification">spec</abbr> you're committing work for, just you would when sending email. If you're working on a bash command line, put the following command into your <code>.bash_functions</code> file: </p> <pre class="code">function commit { hg commit -m "[${PWD##*/}] ${1}" . && hg pull --rebase && hg push }</pre> <p> Now you can do a full commit with a properly formatted commit message just by running <code>commit “message here”</code> in the <abbr title="specification">spec</abbr>'s folder. The function will take care of adding the <abbr title="specification">spec</abbr>'s shortname for you automatically. (If you're using the regeneration script from above, feel free to put that first on the line like <code>regen && …</code>.) </p> <div class="plugin_note noteimportant">By default, <em>all</em> modified, added or removed files will be committed, not just those in the current directory. You can commit individual files by specifying their names at the end of the <code>hg commit</code> command. <p> Use <code>.</code> to commit only changes in the current directory, e.g. </p> <pre class="code">hg commit -m "[css-foo] Fix all typos in this directory" .</pre> </div> <p> <img src="/lib/images/smileys/question.svg" class="icon smiley" alt=":?:" /> If you see a message similar to: “abort: push creates new remote head”, then you either forgot to pull and synchronize your local repository with the central repository, or someone else has pushed changesets since you last did. The error message describes re-trying the push with the “-f” option to force it working. <strong>DON'T DO THIS</strong>. Doing this would create a branch in the central repository. Pull, merge, commit, then try the push again. See the section below about merging. </p> <p> If you have a long commit message, you can leave out the <code>-m “Commit message”</code> part and Mercurial will fire up the editor you specified in your config file. Please make sure your commit message is a reasonable summary of your changes: it need not be an essay, but should describe the gist of your changes to a casual observer. (Breaking your work into multiple, smaller commits can also help keep the commit messages clear and relevant.) </p> <p> At this point your changes will be available on the server to other users. </p> <p> <img src="/lib/images/smileys/question.svg" class="icon smiley" alt=":?:" /> If you see a message similar to: “abort: authorization failed”, then email Peter. See Footer at bottom. </p> </div> <h4 id="merging-branches-of-workhg-merge">Merging Branches of Work: hg merge</h4> <div class="level4"> <p> When you pull, if you have committed changes to your repository (but haven't pushed them yet), and others have pushed changes to the central repository, Mercurial automatically creates two branches to track the different lines of work. You'll know this happened if you see a message about “heads”, like this: </p> <pre class="code">added 2 changesets with 1 changes to 1 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge)</pre> <p> What this means is that you have to merge the two lines of work before you can push back to the central repository. To merge, simply type: </p> <pre class="code">hg merge</pre> <p> In most cases Mercurial will be able to handle the merge completely by itself. But if both you and others have changed the same area in the same files, there may be a conflict, which you will need to resolve manually. </p> <p> <img src="/lib/images/smileys/question.svg" class="icon smiley" alt=":?:" /> If the merge fails with the message: “abort: outstanding uncommitted changes”, you have changes in your working directory that have not been committed to your local repository. Either commit those changes or revert them first, then try again. </p> <p> Once the merge is complete (and you've resolved any conflicts), you'll need to commit it as a changeset (which represents the merge operation): </p> <pre class="code">hg commit -m "merge"</pre> </div> <h4 id="resolving-conflictshg-resolve">Resolving Conflicts: hg resolve</h4> <div class="level4"> <pre class="code">merging foo.txt warning: conflicts during merge. merging foo.txt failed! 0 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges</pre> <p> If your merge or update operation resulted in conflicts, you need to correct those conflicts before proceeding. Unlike CVS and Subversion, Mercurial helps you track which conflicts have been resolved or are unresolved. Consequently, you need to tell it when you're done resolving conflicts in a file. </p> </div> <h5 id="listing-conflicts">Listing Conflicts</h5> <div class="level5"> <p> You can list all the files that had merge conflicts with: </p> <pre class="code">hg resolve --list</pre> <div class="table sectionedit14"><table class="inline"> <tr class="row0"> <td class="col0">U</td><td class="col1">File with unresolved conflicts</td> </tr> <tr class="row1"> <td class="col0">R</td><td class="col1">File with resolved conflicts</td> </tr> </table></div> </div> <h5 id="resolving-conflicts">Resolving Conflicts</h5> <div class="level5"> <p> Open any files with conflicts in your favorite editor and search for conflict markers, which Mercurial has inserted to show you where and how the two versions of the file (yours and theirs) diverge. Conflict markers look like this: </p> <pre class="code">... <<<<<<< local a line that I changed locally ====== the changed line as it exists in the central repository >>>>>>> other ...</pre> <p> Remove everything between (and including) the <code><<<<<<<</code> and the <code>>>>>>>></code> lines, replacing with the correctly-merged contents. Repeat as needed for remaining conflicts until all conflicts have been resolved. </p> <p> <img src="/lib/images/smileys/question.svg" class="icon smiley" alt=":?:" /> If you mess up, you can retry by asking Mercurial to restore the conflict markers: </p> <pre class="code">hg resolve filename</pre> <div class="plugin_note noteclassic">For every file that has a merge conflict, Mercurial will create an untracked copy with the same name and the additional extension <code>.orig</code>. (You can find these by running <code>hg status</code>.) This new file will be the original contents of your version of the file before the merge and is available for your reference. Once all the conflicts have been resolved and committed, you should delete the files with the <code>.orig</code> extensions to avoid any confusion. Note that it is not necessary to <code>hg remove</code> those files as they were never tracked by Mercurial. </div> </div> <h5 id="marking-conflicts-resolved">Marking Conflicts Resolved</h5> <div class="level5"> <p> Once you've merged all the conflicts, tell Mercurial to mark them resolved with: </p> <pre class="code">hg resolve -m</pre> <p> Now that Mercurial knows the conflicts are resolved, it will allow you to commit your changes. </p> <p> You can also mark conflicted files one-by-one by specifying the filename: use “<code>hg resolve -m filename</code>” to mark resolved, or “<code>hg resolve -u filename</code>” to mark unresolved. </p> </div> <h3 class="sectionedit15" id="managing-files">Managing Files</h3> <div class="level3"> <p> Mercurial can track edits to a file automatically, but if you want to add, remove, rename, move, or copy files, you'll have to us its own file management commands so that it can track those operations. </p> <p> This section covers: </p> <ul> <li class="level1"><div class="li"> <a href="#adding-new-fileshg-add" title="tools:hg ↵" class="wikilink1">Adding New Files</a></div> </li> <li class="level1"><div class="li"> <a href="#removing-fileshg-remove" title="tools:hg ↵" class="wikilink1">Removing Files</a></div> </li> <li class="level1"><div class="li"> <a href="#moving-and-renaming-fileshg-move" title="tools:hg ↵" class="wikilink1">Moving and Renaming Files</a></div> </li> <li class="level1"><div class="li"> <a href="#copies-and-forkshg-copy" title="tools:hg ↵" class="wikilink1">Copies and Forks</a></div> </li> </ul> </div> <h4 id="adding-new-fileshg-add">Adding New Files: hg add</h4> <div class="level4"> <p> If you create a new file or directory, you'll need to tell Mercurial to start tracking it. You do this by the following: </p> <pre class="code">hg add filename</pre> <p> Adding a directory recursively adds all of its contents. Note that Mercurial will ignore empty directories. </p> <p> Once you add a file it'll show up in the status listing with an “A”. Note that newly added files aren't actually in the repository until you commit them. If you omit the filename, all unknown files and directories in the current directory are added. </p> </div> <h4 id="removing-fileshg-remove">Removing Files: hg remove</h4> <div class="level4"> <p> To remove a file or directory from the repository type: </p> <pre class="code">hg remove filename</pre> <p> Once a file is removed, it'll show up in the status listing with a “R”. The file is removed from your working directory immediately, but it isn't removed from the repository until your next commit. If you remove all the files in a directory, the directory will be automatically removed as well. Removing a directory recursively removes all of its contents. </p> <p> This command can be abbreviated as <code>hg rm</code>. </p> </div> <h4 id="moving-and-renaming-fileshg-move">Moving and Renaming Files: hg move</h4> <div class="level4"> <p> To move or rename a file or directory: </p> <pre class="code">hg move old_location new_location</pre> <p> This will preserve the revision history of the file or directory from its old name or location. </p> <p> This command can be abbreviated as <code>hg mv</code> and is equivalent to <code>hg rename</code>: </p> <pre class="code">hg rename old_name new_name</pre> </div> <h4 id="copies-and-forkshg-copy">Copies and Forks: hg copy</h4> <div class="level4"> <p> To copy a file or directory: </p> <pre class="code">hg copy original copied</pre> <p> This will preserve history in both copies, effectively forking the file. </p> <p> This command can be abbreviated as <code>hg cp</code>. </p> </div> <h3 class="sectionedit16" id="working-offline">Working Offline</h3> <div class="level3"> <p> The fundamental difference between working with a distributed version control system, like Mercurial, versus a standard version control system, like CVS or Subversion, is that with a standard version control system, when you want to save your work to the repository, you must synchronize with the server, merge your changes with others', and commit your changes, sending them to the server all as one operation. With a distributed version control system, these are handled as individual operations, generally only performed on your local repository. Synchronizing your local repository with the central repository is a separate operation. This means you are free to commit your work in smaller increments at will, only to merge them with other people's work and send them to the central repository when you are ready to do so. </p> </div> <h4 id="pull-vs-update">Pull vs. Update</h4> <div class="level4"> <p> The command </p> <pre class="code">hg pull -u</pre> <p> combines two operations in one: an <code>hg pull</code> followed by an <code>hg update</code>. </p> <pre class="code">hg pull hg update</pre> <p> Pulling only updates your local repository so it knows about the newer changesets on the server; it does not affect your working directory (i.e. you'll have the changes, but you won't see them). Update brings your working directory up to date by merging those new changesets into your working directory (so they show up in your files). If you want to download new changesets while you are connected but merge them with your changes sometime later, you can pull now (without <code>-u</code>) and update later (with <code>hg update</code>). </p> </div> <h4 id="commit-vs-push">Commit vs. Push</h4> <div class="level4"> <p> Mercurial allows you to commit changes to your local copy of the repository, allowing you to save your work in stages (and assign separate commit messages to each stage) without communicating with the central server. This is why <code>hg commit</code> and <code>hg push</code> are separate commands: commit saves any uncommitted changes as a changeset, and push sends all new changesets to the central repository. You can commit locally as many times as you want, and then push all your changesets to the server at once. </p> <p> However, if you do this, you'll need to get comfortable with <code>hg merge</code> and/or <code>hg rebase</code>, since it's quite likely that other people have continued work on the central repository while you've been working offline. </p> </div> <h4 id="patch-queues">Patch Queues</h4> <div class="level4"> <p> Another way to manage offline changes is to use <a href="http://mercurial.selenic.com/wiki/MqTutorial" class="urlextern" title="http://mercurial.selenic.com/wiki/MqTutorial" rel="ugc nofollow">Mercurial Queues</a>, which manages your local changes as pseudo-commits that you can apply, unapply, revise, and rearrange before you formally commit and push. Details about using patch queues are beyond the scope of this document. </p> </div> <h4 id="rebasing-changesets">Rebasing Changesets</h4> <div class="level4"> <p> Mercurial's branching and merge operations gracefully handle multiple people simultaneously commiting work into their local repositories and then resynchronizing later. The only downside to this situation is that the change history of the central repository can become somewhat convoluted and difficult for others to follow. One way to avoid this is to use Mercurial Queues. Another is to “rebase” your changesets before pushing. </p> <p> Rebasing tells Mercurial to recompute your changes so that they appear to be made after the changes that other people have made. If your changes don't conflict, this can be simply achieved by replacing your pull operation with: </p> <pre class="code">hg pull --rebase</pre> <p> You can alternatively rebase your changes after a pull (in place of a merge) using: </p> <pre class="code">hg rebase</pre> <p> If there are conflicts, you can abort the rebase operation and then merge your work instead (as described above): </p> <pre class="code">hg rebase --abort</pre> <p> Resolving rebase conflicts is beyond the scope of this document. Rebasing is not currently considered mandatory for our repositories, but it is good form. </p> <p> <img src="/lib/images/smileys/exclaim.svg" class="icon smiley" alt=":!:" /> If you are working on a decentralized project, don't rebase any changesets that others have pulled from you. (Rebasing changes a changeset's ID, causes all kinds of confusion if those changesets are shared.) </p> </div> <h4 id="comparing-repositories">Comparing Repositories</h4> <div class="level4"> <p> You may find it useful to compare the state of your local repository to the central repository from time to time. This can help you understand if you're in a situation where you'll need to merge or rebase your work before pushing it. </p> </div> <h5 id="checking-for-local-changesetshg-outgoing">Checking for Local Changesets: hg outgoing</h5> <div class="level5"> <p> You can list the set of changesets that you have made, which have not been sent to the central repository, by the following: </p> <pre class="code">hg outgoing</pre> <p> This lists all changesets that would be sent to the central repostitory if you <code>hg push</code>. If it doesn't list any, then you have no local changesets and won't need to <code>hg merge</code> when you pull. </p> <p> This operation does not result in any changes to either the central repository or your local repository. </p> <p> This command can be abbreviated as <code>hg out</code>. </p> </div> <h5 id="checking-for-remote-changesetshg-incoming">Checking for Remote Changesets: hg incoming</h5> <div class="level5"> <p> You can list the set of changesets that other people have made to the central repository, which you do not already have locally, by the following: </p> <pre class="code">hg incoming</pre> <p> This lists all changesets that would be received from the central repositor if you <code>hg pull</code>. If it's empty, there are no new changesets to pull from the repository or merge with your local changes. </p> <p> If you have made changes, you'll see a list of all of your changesets that have not been sent to the central repository. This operation does not result in any changes to either the central repository or your local repository. </p> <p> This operation does not result in any changes to either the central repository or your local repository. </p> <p> This command can be abbreviated as <code>hg in</code>. </p> </div> <h3 class="sectionedit17" id="archaeology">Archaeology</h3> <div class="level3"> <p> Since your Mercurial clone is a full copy of the repository, you have the entire version history available locally, which you can investigate. The following are some examples: </p> <ul> <li class="level1"><div class="li"> To list the last 5 changesets with an <abbr title="American Standard Code for Information Interchange">ASCII</abbr> art diagram of changeset branching: <code>hg glog -l 5</code></div> </li> <li class="level1"><div class="li"> To annotate each line of a file with the changeset that added it: <code>hg annotate filename</code></div> </li> <li class="level1"><div class="li"> To show metadata about changeset #7: <code>hg log -r 7</code></div> </li> <li class="level1"><div class="li"> To show the differences from changeset #7 to changeset #19: <code>hg diff -r 7 -r 19</code></div> </li> <li class="level1"><div class="li"> To take your working directory back to changeset #7: <code>hg update -r 7</code></div> </li> <li class="level1"><div class="li"> To revert a particular file to its contents as of changeset #7 (causing it to appear modified): <code>hg revert -r 7 filename</code></div> </li> </ul> <p> Use <code>hg help</code> to learn more about each command. </p> <p> If you need to edit history, e.g. undo/drop your latest change set, see: </p> <ul> <li class="level1"><div class="li"> <a href="http://mercurial.selenic.com/wiki/EditingHistory" class="urlextern" title="http://mercurial.selenic.com/wiki/EditingHistory" rel="ugc nofollow">http://mercurial.selenic.com/wiki/EditingHistory</a></div> </li> </ul> <p> In particular, <code>hg strip</code> is useful for dropping the most recent changeset. </p> </div> <h2 class="sectionedit18" id="cvssubversion-cheat-sheet">CVS / Subversion Cheat Sheet</h2> <div class="level2"> <p> If you are used to using Subversion or CVS, the following commands are roughly equivalent: </p> <pre class="code">cvs update == svn update == hg pull --rebase cvs commit == svn commit == hg commit . ; hg push cvs stat == svn status == hg status . cvs diff -u == svn diff == hg diff . cvs add == svn add == hg add svn move == hg move cvs remove == svn remove == hg remove</pre> <p> <img src="/lib/images/smileys/exclaim.svg" class="icon smiley" alt=":!:" /> Note that unlike CVS or Subversion, most Mercurial commands operate on the entire repository by default, not just the directory you're in. </p> </div> <h2 class="sectionedit19" id="wait-i-had-work-that-i-didn-t-commit-in-the-old-cvssubversion-repository">Wait, I Had Work That I Didn't Commit In The Old CVS/Subversion Repository</h2> <div class="level2"> <p> We recently moved to Mercurial. If you had been working on a checkout from the old CVS or Subversion repository and hadn't committed your changes before the move, the best way forward is to clone a new Mercurial repository in a different directory, then copy your added or changed files from your old working directory into your new Mercurial working directory, then commit and push from there. </p> </div> <h2 class="sectionedit20" id="more-information">More Information</h2> <div class="level2"> <p> There are many more in-depth guides to Mercurial available on the web, here are a few: </p> <ul> <li class="level1"><div class="li"> <a href="http://hginit.com" class="urlextern" title="http://hginit.com" rel="ugc nofollow">Hg Init: a Mercurial tutorial by Joel Spolsky</a></div> </li> <li class="level1"><div class="li"> <a href="http://hgbook.red-bean.com/" class="urlextern" title="http://hgbook.red-bean.com/" rel="ugc nofollow">Mercurial: The Definitive Guide</a></div> </li> <li class="level1"><div class="li"> <a href="http://mercurial.selenic.com/" class="urlextern" title="http://mercurial.selenic.com/" rel="ugc nofollow">Mercurial Project Home Page</a></div> </li> </ul> <p> Also Mercurial itself has pretty good documentation. Use </p> <pre class="code">hg help</pre> <p> for a list of commands and </p> <pre class="code">hg help command</pre> <p> for documentation on a particular command. </p> </div> <h2 class="sectionedit21" id="still-need-help">Still Need Help?</h2> <div class="level2"> <p> If you're stuck, you can <a href="mailto:mailto:peter.linss@hp.com" class="mail" title="mailto:peter.linss@hp.com">email Peter</a> for help with the repository. </p> <p> Also, remember, this is a wiki. If you can improve these instructions, please do. </p> </div>  </div> <div class="clearer"> </div> <div class="stylefoot"> <div class="meta"> <div class="user"> </div> <div class="doc"> <bdi>tools/hg.txt</bdi> · Last modified: 2017/01/30 16:55 by <bdi>plinss</bdi> </div> </div> <div class="bar" id="bar__bottom"> <div class="bar-left" id="bar__bottomleft"> <form class="button btn_source" method="post" action="/tools/hg"><div class="no"><input type="hidden" name="do" value="edit" /><button type="submit" accesskey="v" title="Show pagesource [V]">Show pagesource</button></div></form> <form class="button btn_revs" method="get" action="/tools/hg"><div class="no"><input type="hidden" name="do" value="revisions" /><button type="submit" accesskey="o" title="Old revisions [O]">Old revisions</button></div></form> </div> <div class="bar-right" id="bar__bottomright">  <form class="button btn_login" method="get" action="/tools/hg"><div class="no"><input type="hidden" name="do" value="login" /><input type="hidden" name="sectok" value="" /><button type="submit" title="Log In">Log In</button></div></form>  </div> <div class="clearer"></div> </div> </div> </div> <div class="footerinc"> <a href="/feed.php" title="Recent changes RSS feed"><img src="/lib/tpl/csswg/images/button-rss.png" width="80" height="15" alt="Recent changes RSS feed" /></a> <a href="http://validator.w3.org/check/referer" title="Valid XHTML 1.0"><img src="/lib/tpl/csswg/images/button-xhtml.png" width="80" height="15" alt="Valid XHTML 1.0" /></a> <a href="http://jigsaw.w3.org/css-validator/check/referer" title="Valid CSS"><img src="/lib/tpl/csswg/images/button-css.png" width="80" height="15" alt="Valid CSS" /></a> <a href="http://wiki.splitbrain.org/wiki:dokuwiki" title="Driven by DokuWiki"><img src="/lib/tpl/csswg/images/button-dw.png" width="80" height="15" alt="Driven by DokuWiki" /></a> </div> <div class="no"><img src="/lib/exe/taskrunner.php?id=tools%3Ahg&1732735229" width="2" height="1" alt="" /></div> </body> </html>