4 ms·

Not sure I’m familiar with any projects using Subversion. I think the most odd-ball version control I’ve seen in prod is SQLite using Fossil (which does seem to

Not sure I’m familiar with any projects using Subversion. I think the most odd-ball version control I’ve seen in prod is SQLite using Fossil (which does seem to have benefits over git) and OpenBSD sticking with CVS.

jldugger 4y ago
SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.
- avereveard 4y ago
  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
- TillE 4y ago
  Subversion fixed all the truly horrific things about CVS, it's quite adequate for centralized source control.
  - arp242 4y ago
    "cvs add image.jpg" and then discovering you can't just do that 2 years later after a fresh checkout was fun.
  - kevincox 4y ago
    Reminds me of Linus Torvald's Google Tech Talk on Git. https://youtu.be/4XpnKHJAok8 https://youtu.be/4XpnKHJAok8 > I see Subversion as being the most pointless project ever started, because the slogan for Subversion for a while was "CVS done right" or something like that and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.
    - jldugger 4y ago
      I mean, he was definitely selling a product there. SVN was pretty good, barring the merge logic being a PITA.
      - Alupis 4y ago
        I don't know if he was selling a product. Git is a FOSS utility, after all. GitHub and others came much later, and have no affiliation with the Git project or Torvalds (some might not know this). Torvalds created Git for the Linux Kernel folks, and didn't really care if it was used anywhere else. Torvalds only went about creating Git because BitKeeper and the Kernel folks had a very public falling-out (much to BitKeeper's ultimate misfortune - who even knows about BitKeeper these days). He, and the Kernel folks, were very happy with BitKeeper up until then - and a lot of the BitKeeper features that were unique at the time ended up landing in Git. This tech talk was because people outside of the Kernel became interested in a similar workflow - namely distributed and "free" branching. Also, I can't help but marvel... this one person created not only the most prolific Kernel in existence - but also the more prolific VCS. I have a hard time just getting out of bed in the morning...
jakub_g 4y ago
Subversion was the main thing in opensource space in before-git before-GitHub mid-2000, when projects were hosted on SourceForge. Old times!
arp242 4y ago
Apache httpd uses subversion. That's the only example of a well-known project I could find that's not directly related to subversion itself. I'm sure there are others, but all the other ones I could recall have since migrated (usually to git).
- netol 4y ago
  Well, I think it is a bit related, being subversion an Apache project: https://subversion.apache.org/ https://subversion.apache.org/
  - arp242 4y ago
    Many Apache projects use git these days. I looked at some other well-known Apache projects, and they all used git; sometimes on the Apache git servers, sometimes on GitHub. I'm sure there are some others that use subversion, but it's not common. AFAIK for the most part Apache (the foundation) is fairly hands-off in telling people how to run their Apache project, and every project is mostly free to "do whatever".
petepete 4y ago
I was about to respond with WebKit but it looks like they switched to git last July.

jldugger 4y ago

SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.

avereveard 4y ago
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
TillE 4y ago
Subversion fixed all the truly horrific things about CVS, it's quite adequate for centralized source control.
- arp242 4y ago
  "cvs add image.jpg" and then discovering you can't just do that 2 years later after a fresh checkout was fun.
- kevincox 4y ago
  Reminds me of Linus Torvald's Google Tech Talk on Git. https://youtu.be/4XpnKHJAok8 https://youtu.be/4XpnKHJAok8 > I see Subversion as being the most pointless project ever started, because the slogan for Subversion for a while was "CVS done right" or something like that and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.
  - jldugger 4y ago
    I mean, he was definitely selling a product there. SVN was pretty good, barring the merge logic being a PITA.
    - Alupis 4y ago
      I don't know if he was selling a product. Git is a FOSS utility, after all. GitHub and others came much later, and have no affiliation with the Git project or Torvalds (some might not know this). Torvalds created Git for the Linux Kernel folks, and didn't really care if it was used anywhere else. Torvalds only went about creating Git because BitKeeper and the Kernel folks had a very public falling-out (much to BitKeeper's ultimate misfortune - who even knows about BitKeeper these days). He, and the Kernel folks, were very happy with BitKeeper up until then - and a lot of the BitKeeper features that were unique at the time ended up landing in Git. This tech talk was because people outside of the Kernel became interested in a similar workflow - namely distributed and "free" branching. Also, I can't help but marvel... this one person created not only the most prolific Kernel in existence - but also the more prolific VCS. I have a hard time just getting out of bed in the morning...

jakub_g 4y ago

Subversion was the main thing in opensource space in before-git before-GitHub mid-2000, when projects were hosted on SourceForge. Old times!

arp242 4y ago

Apache httpd uses subversion. That's the only example of a well-known project I could find that's not directly related to subversion itself. I'm sure there are others, but all the other ones I could recall have since migrated (usually to git).

netol 4y ago
Well, I think it is a bit related, being subversion an Apache project: https://subversion.apache.org/ https://subversion.apache.org/
- arp242 4y ago
  Many Apache projects use git these days. I looked at some other well-known Apache projects, and they all used git; sometimes on the Apache git servers, sometimes on GitHub. I'm sure there are some others that use subversion, but it's not common. AFAIK for the most part Apache (the foundation) is fairly hands-off in telling people how to run their Apache project, and every project is mostly free to "do whatever".

petepete 4y ago

I was about to respond with WebKit but it looks like they switched to git last July.