3 ms·

The article mentions that merging in svn was not as easy as what BK did and what git needed. It allowed merges but they were “big deals” where git makes merges

The article mentions that merging in svn was not as easy as what BK did and what git needed. It allowed merges but they were “big deals” where git makes merges very easy and common. I remember projects where out of 50 people only 1-2 were capable and trusted to do merges. And that was a tedious and boring job so the joke was that you never wanted anyone to know you could merge a code base for release.

dboreham 4y ago
I suspect this is a myth. I used svn for years and don't remember merging being problematic. In fact I remember it being better (less need to manually merge) than today's git. What svn couldn't support well is: zillions of branches. So branch-happy workflows would kill the server. Today's PR-style would probably work ok since it mirrors how we typically worked with svn -- small frequent commits to trunk. Branches only used for maintenance on past releases.
- olddustytrail 4y ago
  You are remembering correctly. Branching on svn was painful; on git it's basically free.
- froh 4y ago
  rebasing of chains of check-ins is a pita in svn, and with git taking over the world, the svn book is no longer getting the love it needs so the de facto reference documentation is no longer fully up to date with the tool.
- bombcar 4y ago
  The thing that CVS/SVN didn't like much was people working on the same area of the code at the same time. Arguably git doesn't like it much as well, but it can branch easier. The real thing needed was the decentralization, CVS/SVN weren't setup to allow every copy to be a master copy on equal footing (and even now most people do NOT use git that way, they setup main or master and let GitHub be the central authority).
- Forge36 4y ago
  It can be slow. As in: 20+ minutes slow. It's possible to only commit part of a merge. It's possible to accidentally include additional changes after a merge.

dboreham 4y ago

I suspect this is a myth. I used svn for years and don't remember merging being problematic. In fact I remember it being better (less need to manually merge) than today's git. What svn couldn't support well is: zillions of branches. So branch-happy workflows would kill the server. Today's PR-style would probably work ok since it mirrors how we typically worked with svn -- small frequent commits to trunk. Branches only used for maintenance on past releases.

olddustytrail 4y ago
You are remembering correctly. Branching on svn was painful; on git it's basically free.
froh 4y ago
rebasing of chains of check-ins is a pita in svn, and with git taking over the world, the svn book is no longer getting the love it needs so the de facto reference documentation is no longer fully up to date with the tool.
bombcar 4y ago
The thing that CVS/SVN didn't like much was people working on the same area of the code at the same time. Arguably git doesn't like it much as well, but it can branch easier. The real thing needed was the decentralization, CVS/SVN weren't setup to allow every copy to be a master copy on equal footing (and even now most people do NOT use git that way, they setup main or master and let GitHub be the central authority).
Forge36 4y ago
It can be slow. As in: 20+ minutes slow. It's possible to only commit part of a merge. It's possible to accidentally include additional changes after a merge.