mozilla

Revision 52519 of Mercurial basics

  • Revision slug: Mercurial_basics
  • Revision title: Mercurial basics
  • Revision id: 52519
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment first cut, warnings only

Revision Content

I am about to tell you some stuff about Mercurial that will save you a lot of frustration.

Avoiding trouble

Use Mercurial 1.0 or later. (hg version to check.)

Configure your merge program. The #1 source of frustration. You know how CVS leaves conflict markers in your files sometimes? Mercurial, by contrast, wants you to fix the conflicts right now, using a merge program (like kdiff3) which it launches for you.

By default, Mercurial uses the first merge program it finds on your system, and most merge programs are incomprehensible to most people. If you don't get the merge exactly right, Mercurial has no way of knowing. It won't loudly complain and prevent you from committing a bad merge. And bad merges are bad news. Sometimes it takes people days to find out what went wrong. Grown men have been known to walk away from whole hg trees, citing inexplicable hg behavior, literally abandoning work because of a bad merge. Bottom line: You will be well and truly screwed if you don't configure and test a merge program that makes sense to you. DO IT NOW. See MergeProgram in the Mercurial wiki.

If you use Mercurial Queues, back up your work. Use hg qinit -c to create a backup repository for your patches and hg qcommit -m backup regularly.

Don't use Mercurial Queues in a repository that someone might pull from. Just don't.


Recovering

If you are confused about the state of your repository:

  • Don't randomly try stuff to see if it'll magically fix it. Keep in mind what you stand to lose, and set down the chainsaw while you still have one good arm.
  • Ask for help on IRC in #developers.
  • Learn how to use read-only commands (hg status, hg head, hg parents, hg log, hg diff) to check the status of your repository. A key skill.

Revision Source

<p>I am about to tell you some stuff about <a href="en/Mercurial">Mercurial</a> that will save you a lot of frustration.
</p>
<h3 name="Avoiding_trouble"> Avoiding trouble </h3>
<p><b>Use Mercurial 1.0 or later.</b>  (<code>hg version</code> to check.)
</p><p><b>Configure your merge program.</b>  The #1 source of frustration.  You know how CVS leaves conflict markers in your files sometimes?  Mercurial, by contrast, wants you to fix the conflicts <i>right now</i>, using a merge program (like <code>kdiff3</code>) which it launches for you.
</p><p>By default, Mercurial uses the first merge program it finds on your system, and most merge programs are incomprehensible to most people.  If you don't get the merge exactly right, Mercurial has no way of knowing.  It won't loudly complain and prevent you from committing a bad merge.  And bad merges are <i>bad news</i>.  Sometimes it takes people days to find out what went wrong.  Grown men have been known to walk away from whole hg trees, citing inexplicable hg behavior, literally abandoning work because of a bad merge.  Bottom line: <i>You will be well and truly screwed if you don't configure and test a merge program that makes sense to you.  DO IT NOW.</i>  See <a class="external" href="http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram">MergeProgram</a> in the Mercurial wiki.
</p><p><b>If you use Mercurial Queues, back up your work.</b>  Use <code>hg qinit -c</code> to create a backup repository for your patches and <code>hg qcommit -m backup</code> regularly.
</p><p><b>Don't use Mercurial Queues in a repository that someone might pull from.</b>  Just don't.
</p><p><br>
</p>
<h3 name="Recovering"> Recovering </h3>
<p>If you are confused about the state of your repository:
</p>
<ul><li> Don't randomly try stuff to see if it'll magically fix it.  Keep in mind what you stand to lose, and <i>set down the chainsaw</i> while you still have one good arm.
</li></ul>
<ul><li> Ask for help on IRC in #developers.
</li></ul>
<ul><li> Learn how to use read-only commands (<code>hg status</code>, <code>hg head</code>, <code>hg parents</code>, <code>hg log</code>, <code>hg diff</code>) to check the status of your repository.  A key skill.
</li></ul>
Revert to this revision