3 ms·

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) th

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.