Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
What makes you think git does not support branches? –  nbt Jun 10 '11 at 10:00
    
I am not very familiar with git, I've used it extremely little (A few github pushes), so maybe it supports branches. My deduction came from reading "Why I Like Mercurial More Than Git" linked to above where he whines about git lacking the "family" convention, which in mercurial represents the branch. –  Ernelli Jun 10 '11 at 13:14
    
This is a good primer on git branching. It's easy! /end_derail –  jozzas Jun 23 '11 at 5:59
add comment

1 Answer

up vote 5 down vote accepted

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.

share|improve this answer
2  
+1: I have seen far too many online resources promoting the "clone to branch" methadology. Mercurial has excellent support for in-repo branches; it's a shame that so many choose not to use it. –  Nicol Bolas Jul 2 '11 at 23:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.