title: Managing release branches in Mercurial
body: <p>Recently I switched from SVN to Mercurial. Now I wonder how to realize my intended branching work flow in Mercurial according to good practice, hoping other developers understand what happens in the repository.</p>
  
  <p>This is the work flow:</p>
  
  <ol>
  <li>Usually I have a trunk/default branch where work on the current release series happens. Let's say that is 1.x. At the same time I use a branch 2.x to work on the next major release. Changes in this branch may be radical, so merging with the trunk/default/1.x branch makes no sense here.
  
  <ul>
  <li>After a while work on 2.x may be finished and version 2.0 gets released. Now I want the 2.x branch to be the new default/trunk branch and the current default/trunk to be the 1.x branch.</li>
  <li>Repeating this process, there may come a new 3.x branch. As before, if 3.0 gets released, 3.x should become the new default branch while the then current default should become the 2.x branch (again).</li>
  </ul></li>
  </ol>
  
  <p>My question is <em>not</em> whether this work flow is a good one (I guess it's not fundamentally wrong). My questions is whether the way I realize this in Mercurial can be seen as good practice or if there are better opportunities.</p>
  
  <p>So here is how I plan to manage branches in Mercurial ...</p>
  
  <p>Starting from a repository with a single branch which holds the code of the current release series 1.x:</p>
  
  <pre><code>$ hg init
  $ echo "hello world" &gt; file1.txt
  $ hg ci -A -m "Initial commit of 1.x code"
  </code></pre>
  
  <p>Start working on release 2.x:</p>
  
  <pre><code>$ hg branch 2.x
  $ hg ci -m "Create new branch for 2.x development"
  $ echo "Big new feature for 2.x" &gt; file2.txt
  $ hg ci -A -m "Add big new feature"
  </code></pre>
  
  <p>Meanwhile, do some work in current release series (1.x):</p>
  
  <pre><code>$ hg up default
  $ echo "Minor adjustments specific for 1.x" &gt; file3.txt
  $ hg ci -A -m "Minor adjustments"
  </code></pre>
  
  <p>After some time release 2.0 is ready, yippee! Make <em>default</em> branch to <em>1.x</em> and <em>2.x</em> to <em>default</em>:</p>
  
  <pre><code>$ hg up default
  $ hg branch 1.x
  $ hg ci -m "Make default branch to 1.x branch"
  $ hg up 2.x
  $ hg ci --close-branch -m "Close branch 2.x"
  $ hg branch --force default
  $ hg ci -m "Make former 2.x branch to new default"
  </code></pre>
  
  <p>Now create a new branch <em>3.x</em> and work in it, also work on <em>default</em>. Again, after some time 3.0 is ready and it's time again to manage branch names:</p>
  
  <pre><code>$ hg up default
  $ hg branch --force 2.x # (reuse previously closed 2.x branch name)
  $ hg ci -m "Make default branch to 2.x branch"
  $ hg up 3.x
  $ hg ci --close-branch -m "Close branch 3.x"
  $ hg branch --force default
  $ hg ci -m "Make former 3.x branch to new default"
  </code></pre>
  
  <p>The repo now may look like this ('o' are the heads):</p>
  
  <pre><code>o Branch default (3.x)
  |
  | o Branch 2.x
   \|
    | o Branch 1.x
     \|
      |
      .
  </code></pre>
  
  <p>The main point I'm not sure about is if <strong>reusing</strong> branch names and juggling with the branch name <em>default</em> is good practice.</p>
  
  <p>A lot of text for that question - sorry - but I wanted to be clear about what I'm doing.</p>