After using mercurial daily for over a year, we are about to find a better workflow for our DVCS. Inspired by a successful Git branching model we are about to move away from our push daily work into master repo and fork off release branches at regular intervals workflow into work on separate feature branches and merge finished features back into master.Anyway, the problem I have had with branching and mergeing in mercurial (branch using clone) is the actual merge process. I have no problem with merges generating additional changesets, the problem I have is that it usually generates huge changesets that contains more changes than the original changeset+merges, The merge changeset also contains changesets from other heads as well.So I have recently realised that when we do pull from master repo,then update/merge and finally push, we create these unnecesary large changesets.What we should do is rebase instead of pull, update/merge.Now rebase was originally an extension to mercurial, it is still an extension but is nowadays shipped together with the mercurial distribution.When following other threads, especially those comparing git with mercurial, it seems like one of the largest difference between the two is the fact that git does not support branches, but has native support for rebase. Mercurial has no native suppport for rebase but support branches.So my question then, if we should adopt to a more flexible workflow using feature branches, we must have a solid branch/merge workflow that does not cause havoc in the master branch. The master branch should be peach containing only  changesets containing a single feature without any extra changesets for any merge operations carried out. Now can that be done in mercurial without rebase support?As a separate issue, I would like some input on how to aggregate multiple changesets in a feature branch into one single changeset when pushing into the main branch.I have read A Guide to Branching in Mercurial but it never mentions the pros or cons regarding ease of mergeing, or more specifically, how the results of the merge is commited into the master branch.
Mercurial branch or rebase?
version control;mercurial;branching
Have you considered to use named branches for your feature branches? This way you can develop a feature by committing to it as often as you want, while the master branch is not polluted by these commits. When a feature is ready you merge the corresponding feature branch into your master branch. This will produce a merge changeset which only contains the difference between the feature branch and the master branch. When we started to use Mercuial we also used a workflow where we separated feature development solely by separate clones. However, since we use name branches life got much easier for us. The changesets are cleanly separated and you can have all branches within one repository without getting confused. Furthermore, you can switch between different branches easily. And as I said, you get a much cleaner history.