5

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?

Improve this question
6
  • 1
    Do stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/… and stackoverflow.com/questions/2471606/… help (for the merging part)? Commented Mar 25, 2010 at 20:17
  • @yves Baumes: from your name and your "exemple" spelling error I could tell you were french speaking, fixed it ;) Commented Mar 25, 2010 at 20:44
  • @yves Baumes: have you read that working with a DVCS was easier (it is, by a fair margin) or that working with a DVCS meant less merge conflicts? It is unclear from your question, because you stated both. These are two very different things. In my opinion Mercurial (we switched from SVN to Mercurial) completely rocks because it's fast, darn fast, incredibly fast compared to Subversion and because we tend to have way less corrupted repos. And cloning/backuping repos is so much easier, etc. Commented Mar 25, 2010 at 20:51
  • @VonC yes I didn't find those entries, and it helps, thx a lot Commented Mar 26, 2010 at 9:28
  • 2
    Please see my answer to another question for a concrete example where Subversion creates a conflict, but Mercurial doesn't: stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/… I have yet to find another example -- it's easy to find lots of people who make vague accusations against Subversion, but nobody backs them up with real examples. Commented Mar 30, 2010 at 8:19

3 Answers 3

Reset to default
6

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

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 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.
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: stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/… I have only found that example where Subversion fails and Mercurial wins.
Correction: Under the default settings, git merge feature will do a fast-forward if possible. git merge --no-ff feature or setting git config merge.ff [--global] false before git merge feature will do a real merge.
5

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.

Improve this answer

2 Comments

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?
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.
0

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.
Improve this answer

1 Comment

This is incomplete. You should not treat release branches as feature branches. svn does handle non-feature branches well - just merge every hotfix back to trunk. This will mark the change as merged, so you know not to merge it again later - just don't ever reintegrate it.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.