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?
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.
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"
So you've decided to double down on the not-knowing-what-you're-talking-about thing? It would have taken you less time to look up the relevant facts than typing out that comment. Besides that, the whole thing reeks of post-hoc argumentation. This will be my last comment in this thread.
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
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.
> 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).
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.
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).
On Tuesday, April 10th between 00:40 UTC and 17:38 UTC, SourceForge experienced a filesystem failure that affected a limited number of svn commits, causing them not to be saved. We resolved the issue as soon as we became aware of it, but commits from a small number of projects, including yours, were affected.
The best approach to recovery will be for yuu to do a new fresh checkout and copy the changes over and make a new commit.
Hey, maybe SVN can host its source on GitHu--oh, wait.
Seriously though, everyone loves GitHub now but it is a giant single point of failure, just like SourceForge was back in the day. Git is more resilient (local copies of history), but we would still have to go through the exercise of migrating projects to a new home, notifying package maintainers and everyone else, etc., etc. I mean, I like GitHub, but I also remember when the Internet was federated.
The github monoculture isn't about individuals setting their own repos so much as items like submodules and issues and code depending on github. Go modules use the github url in the import statements. GH is a lot more ingrained in the community than SF ever was
Github really is a disaster waiting to happen. It is only a matter of time. With luck, people will have started to migrate away before anything major happens, but I doubt it.
From what I've gathered and seen around the web the problem isn't really that git isn't decentralized, it's that it's purely a code versioning tool. With GitHub you have a community, an issue tracker, a wiki, possibly a website hosted with them and so on. Honestly, the biggest hurdle is just community. By not using GitHub you are losing a ton of potential contributors and users just by lack of exposure. It saddens me a bit, but I can live with it. I host my own Git, am setting up a Drone testing server but still mirror everything to GitHub.
It is unfortunate that project management tools that build on top of git instead of around git haven't really managed to succeed enough on a wider scale to coalesce into a some degree of defacto standard.
It's pretty surprising to me that there's only one or two serious attempts (eg, Fossil) at bundling a bug tracker and stuff inside a DVCS repository, so you keep everything together with the code. I was looking at this a year or two ago and couldn't find anything which met my particular requirements.
It doesn't even need to be standardized, just reasonably portable.
I haven't kept count, but I think I've seen like a dozen attempts of making git-based issue trackers over the times. Of course it is debatable how "serious" these attempts ever have been.
> Of course it is debatable how "serious" these attempts ever have been.
I doubt things like this will really gain traction.
I mean, you could always host your own GitLab instance for free if you are worried about GitHub ever going down.
The ergonomics are terrible. For me to submit a bug, are you really telling me that I need to fork a repository, commit my issue and then submit a pull-request? Ughh, pass...
Most in-repository bug trackers have (or plan to have) a way to get bug reports committed to the repository automatically, usually via email or a web site.
For the same reason that you could use cvs or svn, but choose to use git: if the bug database is part of the source-code repository (or is checked into the repository, which is much the same thing), then it goes with you when you're offline. You might be riding a train through the Rockies, but you can still add new bug reports, and mark existing ones fixed, as part of your normal work and then push those commits to the server when the train stops in Denver.
You probably still have a server holding a copy of the repository that you can push your commits to simply because it simplifies the logistics. Likewise you would want a server hosting a web view of the bug database, because it simplifies the logistics. Think of the layers of management who you would have to teach git commands to, or the QA department who were still using spreadsheets a few years ago.
In principle there is nothing that you would lose out on. Of course in practice there are several existing bug trackers that have had years or decades of work put into them and therefore have a huge checklist of features. I'll grant you that I've never seen a distributed bug-tracking system with a similarly long checklist.
BTW, this is the same argument that people used to use against distributed version control. Why give up this long feature checklist to get a version control system that works on the train? Because even when you are connected to the internet, every time you wait on a server is time you'll never get back. Even if it's only a hundred milliseconds, your life is too short.
> BTW, this is the same argument that people used to use against distributed version control.
Maybe people do, but it's Apple's and organges. Modifying files locally is the nature of software development. Switching from SVN to git didn't change the actual developer workflow of "make changes and commit", which is just not how issues are dealt with in reality.
Also, what about authentication for the web front-end? Are you going to have a database to manage users? Every use case of a distributed issue tracker just seems to go against the grain.
A better approach would be to build a traditional issue tracker (centralized) that has the ability to use git internally as a database engine for issues only (not users, settings, etc). Commit author names/emails are linked to actual user accounts and users could optionally clone the issues repository, use a cli-tool and push it back up to the server.
This would be to issue trackers what GitHub/GitLab is to repositories.
Seriously though this is bad. Plenty of software still lives there. Are there any backups so that humanity doesn’t loose a huge part of open source history?
The two dozen sourceforge users left will be devastated.
I honestly won't download anything from that site anymore. If it isn't infected with their adware, I just assume it is outdated and/or comprised with malware.
Unfortunately for the new owners trust, once lost, is hard to regain.
When setting up a new PC last week, I had to spend a non-trivial amount of time searching for a non-SourceForge source for a particular tool. SourceForge was one a trusted source, but because of their bad behavior I have to assume they are up to no good and avoid them like the plague.
And that issue aside, the Sourceforge platform has been at a standstill for many years. The features they provide on their site (discussion, wiki, bug tracking) are all incredibly primitive, and have seen no meaningful improvements during the last decade or more. I have never seen a significant open-source project using any of Sourceforge's features beyond artifact hosting (i.e, release downloads) and occasionally source code management.
Why is he still using SVN in 2018? This wouldn’t have happened with Git. If our hosted git repo got hosed, it would be a simple matter of sending out a slack message and the developer who did the latest push, repushing the code.
Why is he still using SourceForge? They wrapped software in malware and adware. Even if the new owners don’t. Why would anyone trust them?
I love git, and know it better than almost all of developers I've met – but yet I see a lot of projects that would be better served by other VCS, including SVN.
For 99% of the workflow, teaching someone how to use something like tortoise git will get them where they need to go. I taught developers how to use tortoise git who had never used source control in their life.
Git is not a good fit for projects which include large versioned binaries. Projects that involve a lot of artistic work -- like video games, movies, and music -- are hit particularly hard.
SVN is still perfectly acceptable for many users and developers. Yes git may be superior for x, y, and z, but if you have a bunch of infrastructure set up around svn then you have to weigh the “benefits” of git over the cost of migration.
I know for many purposes git’s lack of monotonically increasing version numbers makes tasks that are trivial in svn much harder. To the extent that many projects are investigating commit hooks that literally modify commit data to include a revision number.
Let’s be clear here though: I am not saying git is bad. What I’m saying is that git may not be a trivial switch, or superior feature set, for everyone out there.
That said - it’s always amazing to see anyone still using sourceforge (or that it still exists) precisely because of things like this, or the malware injection they were doing a few years ago, etc
I setup a process at my last job that added the git hash as part of building dll’s and executables. It’s not that hard. We didn’t do branches or use the typical git flow workflow. If you needed to do a hot fix to code in production, you simply looked at the file version that’s part of the Windows metadata, created a branch, released it and merged it back into master.
EDIT:
Wow, looking at the downvotes, the SVN fans are coming out in force.
The problem isn’t “what branch was this built from” - it’s a whole raft of other issues in tooling and workflow that are built around svn and/or incrementing revision numbers.
Clearly simple incrementing revision identifiers are an important tool given large projects like blink are apparently investigating having commit hooks add revision numbers.
The other thing (probably the bit that is causing downvotes) is that you appear to be simply ignoring that the advantages (if they’re even relevant to a given project) of git are simply not sufficient to justify the work involved in migrating from svn.
Most companies in 2018, shouldn’t be hosting their own data center at all. If Netflix of all companies thought it made more sense to move all of their infrastructure to AWS when Amazon is a competitor, that should tell most other companies something.
This is a dangerous idea and a dangerous trend. I’m not a blockchains obsessed federate/decentralize everything person either but putting increasingly large amounts of the internet in increasingly fewer buckets is dangerous to the internet as a whole.
No one is perfect and no one is immune. We should haver fewer single points of failure, not more.
That also says nothing about how notoriously petty big tech companies get in areas they compete.
This is a dangerous idea and a dangerous trend. I’m not a blockchains obsessed federate/decentralize everything person either but putting increasingly large amounts of the internet in increasingly fewer buckets is dangerous to the internet as a whole.
No one is perfect and no one is immune. We should haver fewer single points of failure, not more.
That also says nothing about how notoriously petty big tech companies get in areas they compete.
So you mean you shouldn’t depend on a central location to keep your source control and move to a more distributed system where every committer has the entire source control history?
As you can see, that opinion is getting downvoted a lot....
But back to the point. You can have the best of both worlds if you don’t completely trust AWS and you still want to take advantage of their infrastructure - use an AWS volume gateway in stored mode. You then have a local copy on prem and it’s automatically backed up redundantly to AWS.
And if your data center goes down. Bring up a VM and reattach the AWS hosted volume in cached mode and you’re in business.
I don’t see what the controversy is about. Sourceforge just proved that both trusting SVN for your source code in 2018 isn’t the best approach and that they aren’t competent enough to be trusted running their own infrastructure. When have you heard a story about AWS losing data if you went with their recommended best practices?
> If this happened on Git, things could have been easily restored by the project side, but with Subversion, it is impossible to completely restore things back to the original state.
I see quite a few comments asking the question why anyone still uses Sourceforge in this day. I thought I would share some links to projects I use almost on daily basis hosted on Sourceforge
- SQL Squirrel[1] - SQL frontend.
- ART[2] - A reporting tool. Simple BI tool that packs a punch
I am pleased when a project has a repository on Sourceforge as I can grab a single tarball and sling it over to the dev machines ( no Internet connection )
Hi, president of SourceForge here. This issue affected a very small number of projects (.03%) and they were contacted directly. It is very unfortunate but we are not "hiding it".
Also, I see a lot of comments here not realizing SourceForge has been under new ownership since 2016. Since we took over we immediately eliminated all bundled adware, we also now scan all projects for malware, all downloads are now over https, & more. Big redesign just rolled out too https://arstechnica.com/information-technology/2016/06/under...
We've taken steps to ensure we never lose any commits again.
96 comments
[ 2.8 ms ] story [ 182 ms ] threadSee the referenced article.....
That, and the fact that GitHub is a closed source backend under control of a corporation that's accountable to no one.
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"
1. https://allura.apache.org/
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
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.
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).
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.
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).
"Unfortunately, we are unable to restore the missing commits, you will have to commit them again. Thank you, SourceForge Support"
-----
On Tuesday, April 10th between 00:40 UTC and 17:38 UTC, SourceForge experienced a filesystem failure that affected a limited number of svn commits, causing them not to be saved. We resolved the issue as soon as we became aware of it, but commits from a small number of projects, including yours, were affected. The best approach to recovery will be for yuu to do a new fresh checkout and copy the changes over and make a new commit.
Sincerely, SourceForge Support
Seriously though, everyone loves GitHub now but it is a giant single point of failure, just like SourceForge was back in the day. Git is more resilient (local copies of history), but we would still have to go through the exercise of migrating projects to a new home, notifying package maintainers and everyone else, etc., etc. I mean, I like GitHub, but I also remember when the Internet was federated.
* https://notabug.org/
* https://bitbucket.org/
* https://gitlab.com/
* https://allura.apache.org/
* https://en.wikipedia.org/wiki/Comparison_of_source_code_host...
While GitHub is a massive repository, developers can change the origin with ease if necessary.
Github is just where most of the community is because of network effect.
It doesn't even need to be standardized, just reasonably portable.
> Of course it is debatable how "serious" these attempts ever have been.
I doubt things like this will really gain traction.
I mean, you could always host your own GitLab instance for free if you are worried about GitHub ever going down.
The ergonomics are terrible. For me to submit a bug, are you really telling me that I need to fork a repository, commit my issue and then submit a pull-request? Ughh, pass...
Why not just install GitLab or Bugzilla on that server?
This reminds me of something someone (forgot who) said, "If it can be built with JavaScript, for better or for worse, it will be."
I think the same thing applies blockchain and edge-computing.
You probably still have a server holding a copy of the repository that you can push your commits to simply because it simplifies the logistics. Likewise you would want a server hosting a web view of the bug database, because it simplifies the logistics. Think of the layers of management who you would have to teach git commands to, or the QA department who were still using spreadsheets a few years ago.
So, you want to loose-out on the many benefits of having <best-in-class> issue system because of that one time you decide to dev on a moving train?
Open up notepad, man. Your next stop is only a few hours away.
BTW, this is the same argument that people used to use against distributed version control. Why give up this long feature checklist to get a version control system that works on the train? Because even when you are connected to the internet, every time you wait on a server is time you'll never get back. Even if it's only a hundred milliseconds, your life is too short.
Maybe people do, but it's Apple's and organges. Modifying files locally is the nature of software development. Switching from SVN to git didn't change the actual developer workflow of "make changes and commit", which is just not how issues are dealt with in reality.
Also, what about authentication for the web front-end? Are you going to have a database to manage users? Every use case of a distributed issue tracker just seems to go against the grain.
A better approach would be to build a traditional issue tracker (centralized) that has the ability to use git internally as a database engine for issues only (not users, settings, etc). Commit author names/emails are linked to actual user accounts and users could optionally clone the issues repository, use a cli-tool and push it back up to the server.
This would be to issue trackers what GitHub/GitLab is to repositories.
https://svn.apache.org/repos/asf/subversion/
What was apparently lost was some other projects that SourceForge uses the Subversion software to host.
So the title should probably say something like "in Subversion" rather than "of Subversion".
Seriously though this is bad. Plenty of software still lives there. Are there any backups so that humanity doesn’t loose a huge part of open source history?
I honestly won't download anything from that site anymore. If it isn't infected with their adware, I just assume it is outdated and/or comprised with malware.
https://sourceforge.net/blog/introducing-the-new-sourceforge... discussed here https://news.ycombinator.com/item?id=16108750
When setting up a new PC last week, I had to spend a non-trivial amount of time searching for a non-SourceForge source for a particular tool. SourceForge was one a trusted source, but because of their bad behavior I have to assume they are up to no good and avoid them like the plague.
Is there any compelling reason to ever use them again? They are a dinosaur with a history of herpes
https://arstechnica.com/information-technology/2015/05/sourc...
Two questions:
Why is he still using SVN in 2018? This wouldn’t have happened with Git. If our hosted git repo got hosed, it would be a simple matter of sending out a slack message and the developer who did the latest push, repushing the code.
Why is he still using SourceForge? They wrapped software in malware and adware. Even if the new owners don’t. Why would anyone trust them?
I know for many purposes git’s lack of monotonically increasing version numbers makes tasks that are trivial in svn much harder. To the extent that many projects are investigating commit hooks that literally modify commit data to include a revision number.
Let’s be clear here though: I am not saying git is bad. What I’m saying is that git may not be a trivial switch, or superior feature set, for everyone out there.
That said - it’s always amazing to see anyone still using sourceforge (or that it still exists) precisely because of things like this, or the malware injection they were doing a few years ago, etc
EDIT:
Wow, looking at the downvotes, the SVN fans are coming out in force.
Please (re-)read and follow the site guidelines:
https://news.ycombinator.com/newsguidelines.html
Clearly simple incrementing revision identifiers are an important tool given large projects like blink are apparently investigating having commit hooks add revision numbers.
The other thing (probably the bit that is causing downvotes) is that you appear to be simply ignoring that the advantages (if they’re even relevant to a given project) of git are simply not sufficient to justify the work involved in migrating from svn.
No one is perfect and no one is immune. We should haver fewer single points of failure, not more.
That also says nothing about how notoriously petty big tech companies get in areas they compete.
So you mean you shouldn’t depend on a central location to keep your source control and move to a more distributed system where every committer has the entire source control history?
As you can see, that opinion is getting downvoted a lot....
But back to the point. You can have the best of both worlds if you don’t completely trust AWS and you still want to take advantage of their infrastructure - use an AWS volume gateway in stored mode. You then have a local copy on prem and it’s automatically backed up redundantly to AWS.
And if your data center goes down. Bring up a VM and reattach the AWS hosted volume in cached mode and you’re in business.
I don’t see what the controversy is about. Sourceforge just proved that both trusting SVN for your source code in 2018 isn’t the best approach and that they aren’t competent enough to be trusted running their own infrastructure. When have you heard a story about AWS losing data if you went with their recommended best practices?
This is less about data loss and more about uptime. There have been multiple high profile AWS failures.
Hmm.
- SQL Squirrel[1] - SQL frontend.
- ART[2] - A reporting tool. Simple BI tool that packs a punch
- JasperServer[3] reporting server
- Talend ETL [4]
I also download a number of portable apps[5]. All these are mature projects that get frequent updates. I guess devs on these projects are fine with Sourceforge. I have contributed a few patches on Sourceforge projects using Mercurial. Experience wasn't to bad. I am saddened by events that have happened at Sourceforge but I am grateful for these projects. I do hope they can sort out the issues. [1]http://www.squirrelsql.org/ [2]http://art.sourceforge.net/ [3]https://community.jaspersoft.com/ [4]https://sourceforge.net/projects/talend-studio/ [5]https://portableapps.com/
>>SVNHub Isn't necessary because GitHub supports Subversion!
Also, I see a lot of comments here not realizing SourceForge has been under new ownership since 2016. Since we took over we immediately eliminated all bundled adware, we also now scan all projects for malware, all downloads are now over https, & more. Big redesign just rolled out too https://arstechnica.com/information-technology/2016/06/under...
We've taken steps to ensure we never lose any commits again.