Hacker News Reader

Comment by vortico | Hacker News Reader

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.

View on HN

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.

Who else offers free Subversion hosting?

GitHub

AIUI, what GitHub offers is Subversion access to Git repositories; it doesn't host Subversion repositories per se.

> 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.

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

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?

why would you want to change?

See the referenced article.....

Besides, Sourceforge services are much more encompassing than Github. Mailing lists, forums, a structured download area where you can find stuff...

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.

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?

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.

Yeah, but we're talking about sourceforge which has none of those advantages either and is probably actually the worst of all worlds.

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?

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.

Ok, I stand corrected -- it is OSS based on Apache Allura.

1. https://allura.apache.org/

Reply on news.ycombinator.com