4 ms·

Subversion actually records merge metadata in recent versions. In my experience though it often still fails to work when working in branches.

by jeltz 14y ago

xyzzyb 14y ago
Yeah? That's awesome. Do you mean that the metadata fails to work with branches or that merging itself fails?
- jeltz 14y ago
  The metadata is not enough to track the merging so you get conflicts where there should be enough knowledge to avoid the conflict. If I remember correctly this happens only in some merging patterns.
- eli 14y ago
  It's been around for some time now. I think 1.7 added it. I don't know if it was buggy or if we were doing something wrong, but it still caused merging disasters even though in theory it should have been able to avoid them.
dfrey 14y ago
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.

Subversion actually records merge metadata in recent versions. In my experience though it often still fails to work when working in branches.

by jeltz 14y ago

Subversion actually records merge metadata in recent versions. In my experience though it often still fails to work when working in branches.

xyzzyb 14y ago

Yeah? That's awesome. Do you mean that the metadata fails to work with branches or that merging itself fails?

jeltz 14y ago
The metadata is not enough to track the merging so you get conflicts where there should be enough knowledge to avoid the conflict. If I remember correctly this happens only in some merging patterns.
eli 14y ago
It's been around for some time now. I think 1.7 added it. I don't know if it was buggy or if we were doing something wrong, but it still caused merging disasters even though in theory it should have been able to avoid them.

dfrey 14y ago

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.