3 ms·

SVN had a great feature set, and a great way to handle merges, and sane defaults. too bad they hit some limits as repos become larger and larger, tried to impl

SVN had a great feature set, and a great way to handle merges, and sane defaults. too bad they hit some limits as repos become larger and larger, tried to implement a new storage engine, and basically they never managed to iron out all bugs out of it in time, while the older storage engine entered feature freeze and was basically abandoned. I've been checking them for years, and there were file corruption issue for so long, I lost interest in tracking the status anymore, as by that point I wrapped my head around the git model.

masklinn 4y ago
> and a great way to handle merges Nope. That took a very long while to be added. When the current crop of DVCS started appearing, one of their significant draw was actually that by necessity merges worked well. At the time, SVN made it extremely easy to fork branches, and almost impossible to merge them. Per the official doc (https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmer...) merge tracking was introduced in subversion 1.5, released in May 2008. That's 3 years after the initial release of Git, Mercurial, and Bazaar. Before then you had to keep note of what you'd merged by hand so you didn't double merge it, and that was distinctly not fun.
msbarnett 4y ago
> SVN had a great feature set, and a great way to handle merges, and sane defaults. Are you kidding? Subversion had a notoriously awful way of handling merges, which was a huge driver of people onto Git as soon as it appeared. You truly had to have been there to believe it, but in all but the simplest of merge scenarios, declaring branch bankruptcy and manually moving things back into the target branch by hand was your only real option. Early to mid 2000s, the most common team branching strategy I saw with subversion was "there's only one branch and everybody does all the development in it because god help you if you try to put it back together after branching for something". It wasn't until well after the momentum was clearly in Git's favour and a huge chunk of the user base was gone that Subversion finally fixed it to not be complete dogshit.
- avereveard 4y ago
  it was great, it basically forced developers into the equivalent of a git rebase, maybe the cli wasn't the best, but that was a problem that tortoise solved quite well, in 2002

masklinn 4y ago

> and a great way to handle merges Nope. That took a very long while to be added. When the current crop of DVCS started appearing, one of their significant draw was actually that by necessity merges worked well. At the time, SVN made it extremely easy to fork branches, and almost impossible to merge them. Per the official doc (https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmer...) merge tracking was introduced in subversion 1.5, released in May 2008. That's 3 years after the initial release of Git, Mercurial, and Bazaar. Before then you had to keep note of what you'd merged by hand so you didn't double merge it, and that was distinctly not fun.

msbarnett 4y ago

> SVN had a great feature set, and a great way to handle merges, and sane defaults. Are you kidding? Subversion had a notoriously awful way of handling merges, which was a huge driver of people onto Git as soon as it appeared. You truly had to have been there to believe it, but in all but the simplest of merge scenarios, declaring branch bankruptcy and manually moving things back into the target branch by hand was your only real option. Early to mid 2000s, the most common team branching strategy I saw with subversion was "there's only one branch and everybody does all the development in it because god help you if you try to put it back together after branching for something". It wasn't until well after the momentum was clearly in Git's favour and a huge chunk of the user base was gone that Subversion finally fixed it to not be complete dogshit.

avereveard 4y ago
it was great, it basically forced developers into the equivalent of a git rebase, maybe the cli wasn't the best, but that was a problem that tortoise solved quite well, in 2002