まぁ、自分がMercurialユーザーだったらvim-jpの記事を読んで間違いに気づくはずだ。
まず、Mercurialでのブランチというのはどういうものが理解すべき。Mercurialでは、ブランチというのは、一種のtagとheadsの総称でしかない。gitだとローカルブランチとリモートブランチという概念があって、ブランチをpushするときには、特別な方法を取る必要があるけど、mercurialの場合は通常のpushに自分で作ったブランチが含まれてしまう (もちろんheadsが合わなければリジェクトされるし、明示的にブランチへのpushを使う必要もある)。
だから、多数での開発をしてる際に自分のコードを管理するためにブランチを作るのはよくない。Mercurialにおけるブランチは永続的なものなので、pushする場合にはそのブランチは大元のレポジトリへの影響を与えてしまう可能性がある。
でMercurial上で管理されたコードのパッチを書く場合はどうしたらいいかというとMercurial Queue (mq)を使うのが現状ではベスト。mq形式でパッチを作成しておけば、パッチを受け取った人は、qimportで自分のmqに取り込んで、qfinでコードを直接コミットすることが可能。しかもパッチの説明とか作成者情報とかもmq形式に含まれるんで、受け取る側はrebase以外に手間がかからない。mqの使い方は、実際Mozillaで使ってるやり方とかMercurialのドキュメントとかを参考にするといいです。
もちろん一生pushしないレポジトリだったら別にブランチを使うのもいいけど、一生pushしないってそれ寂しくない？
たぶん、vim-jpの人はgitの知識があるから、こういう情報を書いてしまったんじゃないかな？gitの場合で新規コードを書くときはローカルブランチを作って、それで管理するやり方をするからね。ローカルブランチだからpushする際に影響受けないし、削除も簡単だし。
だから、SCMは各々思想が違うから同じやり方が正しいということは一切ない
