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

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.

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.

1 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 8: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: stackoverflow. Com/questions/2475831/merging-hg-git-vs-svn/… I have only found that example where Subversion fails and Mercurial wins.

– Martin Geisler Mar 31 '10 at 15:54.

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.

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 1 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 @jk thanks, I will follow your advice – yves Baumes Mar 26 '10 at 9:28.

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

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 at 4:17.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.