BranchPlan

• extend changelog format to allow storing new attributes

• add a .hg/branch file to indicate the branch name in the working directory

• read the .hg/branch file on commit

• update the .hg/branch file on checkout

• leave it alone on merge (we stay on the current branch)

• add a branchtags() function to localrepo with a cache

• teach lookup about branch names

• teach log and friends about branch names

• teach hg id about branch names

• get hg pull -r <branch> working

• add a command to show all existing branches

• add a command to change the current branch

• deprecate old -b options

• if a branch is set, update should update to the tip of the current branch

• merging a branch that's descended from the current branch should fast-forward

• heads <branch> should show all heads of that branch

Need more smarts for the following:

• teach hgweb about branch names
• log should have an option to show the history of a single branch, stopping at its fork point (-B ?)
• updating to a revision on a different branch should require a merge (?)
• Need a way to close/hide inactive branches. One possibility: have a special branch name like 'inactive', and commit to that branch on top of the branch you want to close. Then have hg log et al. ignore any branches which are parents of any 'inactive' revisions by default.

Renaming and deleting named branches

Without support for branch renaming and deletion, named branches quickly become a frustrating experience. Of course branches can't actually be deleted, but they can be hidden from normal branch display and update commands. Generalizing from the inactive branch idea, here's one approach:

• To close a branch, make an empty (pure changelog) commit containing a field in the 'extra' dictionary like branch_closed: 1. This hides the branch from the branches command and makes it unavailable as a tag, as well as allowing a new branch of the same name to be created without a branch-shadow warning. The branches.cache file should simply remove the existing entry.

• Renaming a branch is not the same as creating a new branch from the last commit: updates do not cross branches normally. To support a rename, an entry in the 'extra' dictionary of the form branch_oldname: oldname could be included in the first commit on the new name (which can be an empty commit). The branch cache should again hide the old name, and update should look for a branch_oldname entry in the changelog along the path from the source to the destination revision, suppressing the branch-crossing logic where appropriate.

As an example, the mutt repository was converted from CVS using an old version of the convert extension that put most commits on a branch called HEAD. At one point a named-branch-unaware hg client committed to HEAD as if it were 'default'. To fix this repository, the existing 'default' branch could be closed, and the tip on HEAD could be renamed to default.

One problem with this proposal is that older clients cannot make use of either the close or rename operations. I believe that the degradation should be graceful (about the same experience that current clients have), but should think through it further.