4 ms·

When I interviewed Jim Blandy, the creator of Subversion, he said one of his mistakes was trying to be clever with merges. In Git a merge is whatever you say it

by agbell 6y ago

When I interviewed Jim Blandy, the creator of Subversion, he said one of his mistakes was trying to be clever with merges. In Git a merge is whatever you say it is and that is actually probably the flexibility that people what. Is that where the innovation is here, Darcs style patch sets?

fanf2 6y ago
Do you have a link to that interview? It's surprising to hear that svn tried to be clever with merges, because its merge support was no better than CVS until svn 1.5, which was released some years after git. (This is one of the reasons I went straight from CVS to git.)
- gmueckl 6y ago
  SVN started to try to be clever with merges by tracking past merges between copies of files. This required tracking a lot of new information for each file. The developers used a combination of implicitly inferred merge history and annotations stored in SVN properties on each file for that. Combined with the fact that merge and commit were two separate steps in the workflow with manual conflict resolution in-between, this lead to sometimes severe usability issues. The merge would adjust the mergeinfo properties along with the files. Users would sometimes go and do svn revert on some of those files as part of conflict resolution. This would also silently reset the mergeinfo properties that were just updated. The current merge would still work out OK. But future merges involving the current branch or its descendants would get horribly mangled because SVN ends up applying sets of changes that are out of sync with the actual state of the files involved. That's part of what gave SVN its bad reputation.
  - ahaferburg 6y ago
    AFAIK the default use case is to only track merge info on the top level directory, as long as you only do branch/merge operations on the top level. By not doing that, yes, you can shoot yourself in the foot. But it's not necessary at all. Maybe we're talking about different versions, though. I used to use SVN 1.6+ IIRC.
- agbell 6y ago
  Yep, here it is: https://corecursive.com/software-that-doesnt-suck-with-jim-blandy/ https://corecursive.com/software-that-doesnt-suck-with-jim-b...
apostacy 6y ago
I totally agree with that. Git's flexibility is great. In practice, I can synthesize the functionality I want. Unless a merge is fairly straight forward, I often use --no-commit and only select the files I want to merge, and defer a complete merge for later. It is so easy to make intermediate branches, or just pick what I want from one branch to another. I haven't used Darcs or Pijul, but I feel like trying to "solve" merging and source code isn't fully possible.
- gnufx 6y ago
  > Git's flexibility is great. In practice, I can synthesize the functionality I want. Not if the functionality you want a patch-based system, which is just so much easier to use. After 30 years or so experience of using revision control systems with distributed projects, I can't see the appeal of git.
pmeunier 6y ago
Anu is not "trying to be clever" in merges, it implements a mathematical theory. This contrasts with Git and its default 3-way merge, which can sometimes shuffle your file ups, as shown there: https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html

by agbell 6y ago

fanf2 6y ago

Do you have a link to that interview? It's surprising to hear that svn tried to be clever with merges, because its merge support was no better than CVS until svn 1.5, which was released some years after git. (This is one of the reasons I went straight from CVS to git.)

gmueckl 6y ago
SVN started to try to be clever with merges by tracking past merges between copies of files. This required tracking a lot of new information for each file. The developers used a combination of implicitly inferred merge history and annotations stored in SVN properties on each file for that. Combined with the fact that merge and commit were two separate steps in the workflow with manual conflict resolution in-between, this lead to sometimes severe usability issues. The merge would adjust the mergeinfo properties along with the files. Users would sometimes go and do svn revert on some of those files as part of conflict resolution. This would also silently reset the mergeinfo properties that were just updated. The current merge would still work out OK. But future merges involving the current branch or its descendants would get horribly mangled because SVN ends up applying sets of changes that are out of sync with the actual state of the files involved. That's part of what gave SVN its bad reputation.
- ahaferburg 6y ago
  AFAIK the default use case is to only track merge info on the top level directory, as long as you only do branch/merge operations on the top level. By not doing that, yes, you can shoot yourself in the foot. But it's not necessary at all. Maybe we're talking about different versions, though. I used to use SVN 1.6+ IIRC.
agbell 6y ago
Yep, here it is: https://corecursive.com/software-that-doesnt-suck-with-jim-blandy/ https://corecursive.com/software-that-doesnt-suck-with-jim-b...

apostacy 6y ago

I totally agree with that. Git's flexibility is great. In practice, I can synthesize the functionality I want. Unless a merge is fairly straight forward, I often use --no-commit and only select the files I want to merge, and defer a complete merge for later. It is so easy to make intermediate branches, or just pick what I want from one branch to another. I haven't used Darcs or Pijul, but I feel like trying to "solve" merging and source code isn't fully possible.

gnufx 6y ago
> Git's flexibility is great. In practice, I can synthesize the functionality I want. Not if the functionality you want a patch-based system, which is just so much easier to use. After 30 years or so experience of using revision control systems with distributed projects, I can't see the appeal of git.

pmeunier 6y ago

Anu is not "trying to be clever" in merges, it implements a mathematical theory. This contrasts with Git and its default 3-way merge, which can sometimes shuffle your file ups, as shown there: https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html