What are the differences between GIT and SVN when it comes to merge conflicts solving

I keep hearing that branching in git is so much easier than in SVN, because it's easier to merge the branch back to trunk/master. I've read some tutorials, but they only covered basic merge conflicts ("Alice changed line 8 of code.cpp and开发者_JS百科 at the same time Bob changed line 8 of code.cpp...") and there are no differences between SVN and all other distributed source control systems.

Can you give me the examples of changes in branch that would cause troubles in SVN repository, but would be handled gracefully by git?

---

I finally had some time to tinker with branches/merging with git and svn and found the case that kills svn but works perfectly with git:

Let's say the project consists of those files:

/main.cpp
/sub1/sub1.cpp
/sub1/sub1.h

1. Create branch
2. In trunk, move sub1.* to root directory, delete sub1 subdirectory.
3. In branch make some changes in /sub1/sub1.cpp
4. In trunk make some changes in /sub1.cpp
5. Merge branch and trunk.

SVN loses all changes made in branch in point 3, similar changes in git are perfectly merged. That's enough for me to reject SVN as version control system for any project that requires branching.

---

hgInit.com is related to Mercurial but will give you a very good overview of the difference between a DVCS and SVN for merging conflicts.

The reason why Subversion has trouble with merging has to do with the way it stores the version history. Subversion likes to think about revisions. A revision is what the entire file system looked like at some particular point in time. In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision.

So Subversion compares whole files when merging while Mercurial (or Git) compares each change set individually. Conflicts occur far less frequently when dealing with changesets.