4 ms·

Why do people still use this garbage?

vortico 9y ago
For many projects, the <30 minutes required to switch to another provider and source control software is more than they consider it to be worth.
- alkonaut 9y ago
  Migrating a large project from svn to another centralized storage is pretty simple but you need support in all your other systems (builds, issue tracking, ...). That might limit the choices of centralized vcs available. Migrating a very large subversion repo to git is not trivial. The KDE team spent a lot of time just developing the tools required to do it https://github.com/svn-all-fast-export/svn2git https://github.com/svn-all-fast-export/svn2git But even with those tools it’s still quite a process. If there are lots of large binary assets (often the reason for using centralized to begin with) the adoption of Git-LFS, GVFS etc is a time consuming process. I have waited years just for the tools to mature (LFS etc) and now I expect to spend a few weeks at least, migrating our single svn repo to git. Switching from SourceForge should be a no brainer though, completely agree with that - even for projects that stay on SVN.
  - jwilk 9y ago
    Who else offers free Subversion hosting?
    - smudgymcscmudge 9y ago
      GitHub
      - deleted 9y ago
        [deleted]
      - jwilk 9y ago
        AIUI, what GitHub offers is Subversion access to Git repositories; it doesn't host Subversion repositories per se.
  - majewsky 9y ago
    > The KDE team spent a lot of time just developing the tools required to do it KDE was a special case because we wanted to split a monorepo into one repo per application at the same time, yet retain as much history as possible (including across restructurings of the source tree). Also, the massive size of the monorepo (about 1.5 million revisions) made it infeasible to use the standard tooling of git-svn to do it. Most projects will not have these problems. At work, I migrated a rather large application (~500k LOC) from SVN to Git while retaining the entire history, with the standard tooling (`git svn clone && git push`, basically).
    - alkonaut 9y ago
      Ours isn’t even very large, I’d call it “medium”. The svn working copy is around 2GB and the entire 100krev history is about 80Gb. This is easy to handle centralized but we obviously need LFS or GVFS for it to be feasible in Git (keeping all the binary assets AND the 100k rev history is a requirement). Migrating it using git svn is a couple of days (and annoying when it stops half way because of some issue) At least with svn2git we can test-convert including lfs migration in just a couple of hours.
      - majewsky 9y ago
        Ah yeah, repos with (a large number of) large binary files are a different story. I'm usually dealing with code only (and maybe some bitmaps for UIs).
- ams6110 9y ago
  I think the impact on most non-trivial projects is quite a bit more than 30 minutes. If you have all of your development processes, tools, testing, and release-building built around SVN, switching to git would be a fairly major undertaking, and if your project is working well with SVN, why would you want to change?
  - megaman22 9y ago
    If changing a VCS root for building, testing and packaging a project is a major task, you might be using a janky CI/CD tool.
  - scarface74 9y ago
    why would you want to change? See the referenced article.....
  - gmueckl 9y ago
    Besides, Sourceforge services are much more encompassing than Github. Mailing lists, forums, a structured download area where you can find stuff...
- mattbillenstein 9y ago
  I'll say it's probably closer to 3 minutes for most -- how can you be a developer today and not have at least touched github once or twice?
  - carussell 9y ago
    It's possible (likely, even) that experience of using GitHub is the exact reason why someone has decided not to settle there. Keep in mind that the Linux kernel—the very project that Git owes its existence to—is itself developed by a group that has eschewed with GitHub almost entirely for collaboration. That, and the fact that GitHub is a closed source backend under control of a corporation that's accountable to no one.
    - mattbillenstein 9y ago
      Yeah, but we're talking about sourceforge which has none of those advantages either and is probably actually the worst of all worlds.
      - carussell 9y ago
        Literally untrue. If the facts aren't on your side, or you don't know them well enough to know whether they are or not, why even comment?
        mattbillenstein 9y ago
        The only real fact you cited isn't actually any sort of advantage for sourceforge over GH [1]. I don't think sourceforge has an open backend or any iota of accountability given their history of injecting malware. And I have no problem with a project not wanting to use github for this reason either - everyone is free to roll their own, or use something else, but the point stands that SF isn't exactly a better alternative for those reasons and most small projects should just end up on github because that's where a lot of OSS development has coalesced anyway and at least github has a been a decent steward providing free OSS project hosting. 1. "and the fact that GitHub is a closed source backend under control of a corporation that's accountable to no one"
fundamental 9y ago
A whole variety of reasons including pre-existing momentum, a different feature set for issue tracking compared to other options, integrated mailing lists, better access control systems, more complex/more-featured project web hosting, better project statistics, better organized file downloads, etc. A very significant one is going to be avoiding the effort of changing platforms (from one to many different ones in some cases), but there are some nice technical benefits of the software they've produced. I think it's a shame that they struggle with uptime, stability, and maintaining a consistent management as there's a lot that's nice about their system overall (at least in my opinion).

For many projects, the <30 minutes required to switch to another provider and source control software is more than they consider it to be worth.

alkonaut 9y ago
Migrating a large project from svn to another centralized storage is pretty simple but you need support in all your other systems (builds, issue tracking, ...). That might limit the choices of centralized vcs available. Migrating a very large subversion repo to git is not trivial. The KDE team spent a lot of time just developing the tools required to do it https://github.com/svn-all-fast-export/svn2git https://github.com/svn-all-fast-export/svn2git But even with those tools it’s still quite a process. If there are lots of large binary assets (often the reason for using centralized to begin with) the adoption of Git-LFS, GVFS etc is a time consuming process. I have waited years just for the tools to mature (LFS etc) and now I expect to spend a few weeks at least, migrating our single svn repo to git. Switching from SourceForge should be a no brainer though, completely agree with that - even for projects that stay on SVN.
- jwilk 9y ago
  Who else offers free Subversion hosting?
  - smudgymcscmudge 9y ago
    GitHub
    - deleted 9y ago
      [deleted]
    - jwilk 9y ago
      AIUI, what GitHub offers is Subversion access to Git repositories; it doesn't host Subversion repositories per se.
- majewsky 9y ago
  > The KDE team spent a lot of time just developing the tools required to do it KDE was a special case because we wanted to split a monorepo into one repo per application at the same time, yet retain as much history as possible (including across restructurings of the source tree). Also, the massive size of the monorepo (about 1.5 million revisions) made it infeasible to use the standard tooling of git-svn to do it. Most projects will not have these problems. At work, I migrated a rather large application (~500k LOC) from SVN to Git while retaining the entire history, with the standard tooling (`git svn clone && git push`, basically).
  - alkonaut 9y ago
    Ours isn’t even very large, I’d call it “medium”. The svn working copy is around 2GB and the entire 100krev history is about 80Gb. This is easy to handle centralized but we obviously need LFS or GVFS for it to be feasible in Git (keeping all the binary assets AND the 100k rev history is a requirement). Migrating it using git svn is a couple of days (and annoying when it stops half way because of some issue) At least with svn2git we can test-convert including lfs migration in just a couple of hours.
    - majewsky 9y ago
      Ah yeah, repos with (a large number of) large binary files are a different story. I'm usually dealing with code only (and maybe some bitmaps for UIs).
ams6110 9y ago
I think the impact on most non-trivial projects is quite a bit more than 30 minutes. If you have all of your development processes, tools, testing, and release-building built around SVN, switching to git would be a fairly major undertaking, and if your project is working well with SVN, why would you want to change?
- megaman22 9y ago
  If changing a VCS root for building, testing and packaging a project is a major task, you might be using a janky CI/CD tool.
- scarface74 9y ago
  why would you want to change? See the referenced article.....
- gmueckl 9y ago
  Besides, Sourceforge services are much more encompassing than Github. Mailing lists, forums, a structured download area where you can find stuff...
mattbillenstein 9y ago
I'll say it's probably closer to 3 minutes for most -- how can you be a developer today and not have at least touched github once or twice?
- carussell 9y ago
  It's possible (likely, even) that experience of using GitHub is the exact reason why someone has decided not to settle there. Keep in mind that the Linux kernel—the very project that Git owes its existence to—is itself developed by a group that has eschewed with GitHub almost entirely for collaboration. That, and the fact that GitHub is a closed source backend under control of a corporation that's accountable to no one.
  - mattbillenstein 9y ago
    Yeah, but we're talking about sourceforge which has none of those advantages either and is probably actually the worst of all worlds.
    - carussell 9y ago
      Literally untrue. If the facts aren't on your side, or you don't know them well enough to know whether they are or not, why even comment?
      - mattbillenstein 9y ago
        The only real fact you cited isn't actually any sort of advantage for sourceforge over GH [1]. I don't think sourceforge has an open backend or any iota of accountability given their history of injecting malware. And I have no problem with a project not wanting to use github for this reason either - everyone is free to roll their own, or use something else, but the point stands that SF isn't exactly a better alternative for those reasons and most small projects should just end up on github because that's where a lot of OSS development has coalesced anyway and at least github has a been a decent steward providing free OSS project hosting. 1. "and the fact that GitHub is a closed source backend under control of a corporation that's accountable to no one"

fundamental 9y ago

A whole variety of reasons including pre-existing momentum, a different feature set for issue tracking compared to other options, integrated mailing lists, better access control systems, more complex/more-featured project web hosting, better project statistics, better organized file downloads, etc. A very significant one is going to be avoiding the effort of changing platforms (from one to many different ones in some cases), but there are some nice technical benefits of the software they've produced. I think it's a shame that they struggle with uptime, stability, and maintaining a consistent management as there's a lot that's nice about their system overall (at least in my opinion).