What are the benefits of Mercurial or git over svn for branching/merging?

Question

I've heard for instance that merging branches with git or mercurial is easier than with svn.

Reading last Joel on software blog entry, I didn't get it exactly why. Could you provide a concrete example where merging with git/mercurial lead to less merge conflicts compared to svn please?

Answer 1

Check HGINIT out. It's an article/tutorial by Joel Spolsky (not his latest blog entry) on the topic. You might find the Subversion Re-Education part specially interesting.

Answer 2

One simple example is git can automatically convert a merge into a "fast forward". For example, let's say I have a branch that looks like this:

Master:

A ---> B ---> C

And I create a feature branch based on Master with new commits D and E.

Feature:

A --- > B ---> C
                \
                 D ---> E

In svn, when you merge the feature branch back into master, you must create an entirely new commit that applies the changes of D and E on Master. So, it looks like:

Master:
    A ---> B ---> C -----------------> F
Feature:           \                  /
                    ---> D ---> E -->

In git we have a choice of how to incorporate the branch feature into master. If we do a

git rebase feature

git will automatically recognize that this is a trivial merge and perform a fast-forward merge, which will add the new commits to the master branch. The result of the rebase is:

Master:

A ---> B ---> C ---> D ---> E

Both the head of Master and Feature point at commit E (in other words, they look exactly the same). A fast-forward merge is similar to what happens when you do an update in svn.

Additionally, you have the option of forcing git to create a merge commit. If instead we do:

git merge feature

git will create a merge commit. The result of the merge is:

Master:
    A ---> B ---> C -----------------> F
Feature:           \                  /
                    ---> D ---> E -->

Commit F is the combination of D and E.

Answer 3

Subversion conviniently implements only the single concept - fearure branches. This means one branch is always a parent and the other is feature. Feature can pull the updates from parent over time (merge), but parent can pull feature's changes only once (merge --reintegrate) and then the child should be closed. It is sufficient in many cases but not always. Not all branches are feature branches. I've got a couple of examples.

1. First. A good example is a release branch. Suppose, you're preparing a release based on a thoroughly tested trunk revision. You make a release branch from the desired trunk revision. Now you're not affected by any subsequent trunk modifications. But you may want to commit hotfixes to the release branch and you may want to backport those to trunk without closing the release branch. This cannot be implemented with svn's feature branches. With svn you will have to wait until your release branch is no longer needed and then reintegrate it. Or to backport the hotfixes by hand.
2. Second. Per-team or per-developer branches. Don't have a ready example of when they're really useful, but you won't like them in svn for sure. It'll be painful to synchronize such branches.