What should go in the 'default' branch of a Hg repository? [closed]

Question

In large Libre Source software projects, versioned with Mercurial or similar DVCS tools, which of the following is considered to be more conventional:

1. Keeping the latest "stable" version of the software in the default branch. Tagging each release in default so you know which revision got packaged up as a download. Merging patches into default as soon as they are tested. Keeping new features, etc. in named branches to be merged into default on the next release.
2. Keeping each release in a named branch, or similar. Using default to keep bleeding-edge code that's only intended to be run by developers or the very foolhardy.

Or... is there some better pattern of workflow that it widely accepted?

Answer 1

Mercurial has a fairly strong opinion on what you should use your default branch for. It's documented in the Standard Branching wiki page. The summary is:

• You should not use a name other than default for your main development branch.

  The reason is that default is the branch that is checked out by new clones. If you try to use some other name for your "main" branch, users will get a more or less random branch when they clone and commit things in the wrong place, which is generally undesirable.

  Even with tons of documentation that says "branch before adding a new feature" (see next point), people will forget this when they send you patches. They then have the trouble of cleaning up things by moving changesets around.

  So always put the bleeding-edge code in the default branch and use other branches for your stable releases.

• Don't treat branch names as disposable

  Branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced. Thus you will want to give some thought to your branch names so that you don't pollute the branch namespace.

  Also, if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial and the tools surrounding it are designed to work well with hundreds of branches. Mercurial itself still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow alredy stabilized.

  We have caches in place internally in Mercurial, so the problems are mostly UI problems: hosting sites and log viewers might run hg branches to load all 10,000 branches into a single drop-down menu. That is really slow and useless for the poor user that want to select a single branch from the gigantic menu.

  If the branches are closed, then they wont show up in hg branches, and so the problem should be minimized. However, the tools might want to show closed branches too — it all depends on the tool.

  I'm sorry this is a little vague. The main point is that Mercurial is built to scale in the number of changesets, not the number of named branches. We have addressed the biggest performance problems with named branches with the cache I mentioned before, so today I'm not too concerned about having many branches, especially if the number of open branches is kept small (less than, say, 100).

Answer 2

I have fallen into the habit if using default in Mercurial and master in Git for the actual work, the bleeding edge, and using tags and branches for the releases. hgsubversion and Git-Svn seem to take this tack.

Answer 3

There are not, in common, such thing as "most conventional" - each and every workflow is a matter of local convention and development policy in team.

I saw both mentioned policy often, and intermediate variations - also.

In case of strong testing|release policy and intensively used branches ("branch per task") "default" branch often exist only as merges-only branch (merges from feature-branches before QA-testing) and means "Code, which work with finished features, without throwing errors, but with unstested functionality".

Minor versions form named branches, each release in such branch is tag. Bugfix branches are merged after completing into "default" and active versions branches

But this workflow is just one more example, not better|worse than others, suitable for mid-size teams with responsibility separation established, doesn't work well in "chaotic anarchy" development