Mercurial: Branching for releases?

 

Previous history: The last couple of years I used SVN. Releasing a new version of a software project included following steps:

  • creating a branch for the new release: /repo/branches/0.1
  • getting the code into a release-worthy state there
  • creating a tag for a release candidate: /repo/tags/0.1-RC1
  • creating branch for RC1 to fix bugs: /repo/branches/0.1-RC1
  • creating tag for a new release candidate: /repo/tags/0.1-RC2
  • {...}
  • creating a tag for v0.1 from the last RC: /repo/tags/0.1
  • merging 0.1 into trunk

    • As far as I got Mercurial sees branches and tags slightly different than SVN and this finally leads to my question:

    Do I create branches (and tags) for releases? And if not: What else wants Mercurial me doing to archive something similar to the described development pattern/cycle?

    You can easily keep using this method. I'm not sure what you'd need a separate RC1 branch for, but I guess there are good reasons.

    There is a bit of an annoyance in the way tags are stored in Mercurial, which is a versioned file listing them one by one. As a result tag creation constitutes a changeset. You should strive to keep all such tag-creating changesets on one branch, or you will get merge conflicts (which are easily resolved, but annoying nonetheless).

    You can use old workflow, but:

  • Branch per release really needed (in any SCM) only if you have to maintain some amount (>1) of releases in production at the same time, gor single maintained release branches-tree not needed
  • I see a lot of (rather complex) projects, which use two-branches method ("Stable" with mergesets only and tags + "Devel" for every-day development (short-term branch-per-task are also possible, but it's more question of tastes and habits, than "a must")
    • 链接地址: http://www.djcxy.com/p/37538.html

    上一篇: Mercurial - 恢复到旧版本并从那里继续

    下一篇: Mercurial：分支版本？