title: How to manage concurrent development with mercurial?
body: <p>This is a best practice question, and I expect the answer to be "it depends". I just hope to learn more real world scenarios and workflows.</p>
  
  <p>First of all, I'm talking about different changes for the same project, so no subrepo please.</p>
  
  <p>Let's say you have your code base in an hg repository. You start to work on a complicated new feature A, then a complicated bug B is reported by your trusted tester (you have testers, right?).</p>
  
  <p>It's trivial if (the fix for) B depends on A. You simlply ci A then ci B.</p>
  
  <p>My question is what to do when they are independent (or at least it seems now).</p>
  
  <p>I can think of the following ways:</p>
  
  <ol>
  <li>Use a separate clone for B.</li>
  <li>Use anonymous or named branches, or bookmarks, in the same repository.</li>
  <li>Use MQ (with B patch on top of A).</li>
  <li>Use branched MQ (I'll explain later).</li>
  <li>Use multiple MQ (since 1.6)</li>
  </ol>
  
  <p>1 and 2 are covered by an <a href="http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/" rel="nofollow noreferrer">excellent blog</a> by @Steve Losh linked from a <a href="https://stackoverflow.com/questions/1405604/managing-release-branches-in-mercurial">slightly related question</a>.</p>
  
  <p>The one huge advantage of 1 over the other choices is that it doesn't require any rebuild when you switch from working on one thing to the other, because the files are physically separated and independent. So it's really the only choice if, for example, A and/or B touches a header file that defines a tri-state boolean and is included by thousands of C files (don't tell me you haven't seen such a legacy code base).</p>
  
  <p>3 is probably the easiest (in terms of setup and overhead), and you can flip the order of A and B if B is a small and/or urgent fix. However it can get tricky if A and B touches the same file(s). It's easy to fix patch hunks that  failed to apply if A and B changes are orthogonal within the same file(s), but conceptually it's still a bit risky.</p>
  
  <p>4 can make you dizzy but it's the most powerful and flexible and scalable way. I default <code>hg qinit</code> with <code>-c</code> since I want to mark work-in-progress patches and push/pull them, but it does take a conceptual leap to realize that you can branch in MQ repo too. Here are the steps (mq = hg --mq):</p>
  
  <ol>
  <li><code>hg qnew bugA</code>; make changes for A; <code>hg qref</code></li>
  <li><code>mq branch branchA; hg qci</code></li>
  <li><code>hg qpop; mq up -rtip^</code></li>
  <li><code>hg qnew bugB</code>; make changes for B; <code>hg qref</code></li>
  <li><code>mq branch branchB; hg qci</code></li>
  <li>To work on A again: <code>hg qpop; mq up branchA; hg qpush</code></li>
  </ol>
  
  <p>It seems crazy to take so many steps, and whenever you need to switch work you must <code>hg qci; hg qpop; mq up &lt;branch&gt;; hg qpush</code>. But consider this: you have several named release branches in the same repository, and you need to work on several projects and bug fixes at the same time for all of them (you'd better get guaranteed bonus for this kind of work). You'd get lost very soon with the other approaches.</p>
  
  <p>Now my fellow hg lovers, are there other/better alternatives?</p>
  
  <hr>
  
  <p>(UPDATE) <code>qqueue</code> almost makes #4 obsolete. See Steve Losh's elegant description <a href="http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/#multiple-patch-queues" rel="nofollow noreferrer">here</a>.</p>