views:

441

answers:

3

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?

+2  A: 

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.

Pablo Santa Cruz
I know this tutorial and I've read it carefully. And it make grow my interest in such version control system ... change control system sorry ;-). But I was dispointed by the "merging" section which shows off simple merge on a single leading to ... a merge conflict the user needs to resolve by end, as we are all used to do with svn. I've really heard Mercurial/Git are powerful when it is about merge with less conflicts. Could you provide a concrete exemple please?
yves Baumes
the benefit is mostly not from better conflict resolution but from effectively always working on your own branch, hence you can commit before merging instead of merging before committing. there are a lot of other little benefits as well that all add up. your best bet is probably to install mercurial and spend an hour experimenting with it.
jk
@jk thanks, I will follow your advice
yves Baumes
+3  A: 

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.

Alex Rockwell
I agree with you that it is nice that both Mercurial and Git recognizes this case and lets you continue working without a merge. But I wouldn't say that the merge is bad in Subversion: some people will argue that the merge is nice since it shows you more clearly what is going on. Also, with merge tracking, SVN will know that F is the result of merging D+E.
Martin Geisler
@Martin Thanks for your feedback. I updated my answer to show that in git you have a choice between doing a fast-forward or doing a merge commit. There are definitely situations where a merge is preferable. I'm not familiar with svn's merge tracking feature. Do you know of any limitations svn merge tracking has that git does not? I tried to do some research on svn merge tracking and only found information on basic use cases.
Alex Rockwell
@Alex: Good update. About Subversion, then I too have been trying to figure out what is good and what is bad about Subversion's merge tracking: http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2486662#2486662 I have only found that example where Subversion fails and Mercurial wins.
Martin Geisler
A: 

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.
Mr.Cat