Merge metadata was recorded since the 1.5 releases of Subversion in 2006. As you mentioned, it's still not as nice as the way Git or Mercurial works. One nice

Merge metadata was recorded since the 1.5 releases of Subversion in 2006. As you mentioned, it's still not as nice as the way Git or Mercurial works. One nice thing about Subversion's branching model is that it is relatively easy to merge single revisions from one branch to another and have that information be recorded in merge metadata. In Git or Mercurial, you can cherry pick revisions by essentially duplicating them in a new location in the graph of revisions. This is annoying in scenarios like this: c--d--e / a--b \ f Now we want the change from commit d applied on the branch with head f so we cherry-pick the revision into place. This essentially applies the delta of revision d as a patch over revision f. c--d--e / a--b \ f--d' Now we make another change (rev g)and then decide that what was done in revision d was incorrect, so we undo those changes (rev h). c--d--e / a--b \ f--d'--g--h Now we decide that we want to merge branch with head e into branch with head h. c--d--e---- / \ a--b i \ / f--d'--g--h In Git or Mercurial, the change originally made in revision d (and later undone in revision h) will appear in revision i. Subversion won't make this mistake because when revision d will already be marked as merged into that branch. I'm much happier with the DAG model of Git and Mercurial than I was with the Subversion branching model, but the DAG model is not universally superior.