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?

SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
yves Baumes
  • 8,836
  • 7
  • 45
  • 74
  • 1
    Do http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2477089#2477089 and http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn/2472251#2472251 help (for the merging part)? – VonC Mar 25 '10 at 20:17
  • @yves Baumes: from your name and your "exemple" spelling error I could tell you were french speaking, fixed it ;) – SyntaxT3rr0r Mar 25 '10 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. – SyntaxT3rr0r Mar 25 '10 at 20:51
  • @VonC yes I didn't find those entries, and it helps, thx a lot – yves Baumes Mar 26 '10 at 09:28
  • @WizardOfOdds you're right, I am french :-) ! I've read, or should I say, I understood that merginin with Hg/git is easier. I've followed the video presentation of git by Torvalds at google. He explained that he does many merge every day in linux repository with source code he didn't commit himself. I understood that Git is better at helping during merge process that svn. Linus Torvalds was suggesting it wouldn't have been possible with svn – yves Baumes Mar 26 '10 at 09:33
  • 2
    Please see my answer to another question for a concrete example where Subversion creates a conflict, but Mercurial doesn't: http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2486662#2486662 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. – Martin Geisler Mar 30 '10 at 08:19

3 Answers3

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.

Alex Rockwell
  • 1,454
  • 9
  • 13
  • 2
    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 Mar 30 '10 at 08:23
  • @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 Mar 31 '10 at 13:11
  • 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 Mar 31 '10 at 15:54
  • 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. – Max Nanasy Feb 20 '13 at 04:31
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.

Pablo Santa Cruz
  • 176,835
  • 32
  • 241
  • 292
  • 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 Mar 25 '10 at 19:50
  • 2
    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. Mar 25 '10 at 21:57
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.
Alexey B.
  • 1,106
  • 8
  • 17
  • 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. – ripper234 May 30 '11 at 04:17