Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

211–220 of 238 posts

Re: GitHub Sunsetting Subversion Support

#211

Earlier quoted context omitted.

Yeah a simple `python3 -m http.server` works pretty well.

Python http.server doesn't handle concurrent requests, so it works pretty well until it doesn't. Example don't use it to serve an ISO to iLO/iDRAC, boot will fail.

I believe this was updated in a recent version of Python to use threads.

Re: GitHub Sunsetting Subversion Support

#212
post #190
post #153

Earlier quoted context omitted.

That's called a "sparse checkout" in git-land. https://www.git-scm.com/docs/git-sparse-checkout

A sparse checkout isn't quite the same thing. It still has to clone the whole repository, it just only puts part of it in the working tree. With svn, you don't have to pull down anything for other directories. More recently, you can combine a sparse checkout with partial clone to get more similar functionality, but it isn't exactly simple.

FWIW, it's called a shallow clone:

https://git-scm.com/docs/shallow

Re: GitHub Sunsetting Subversion Support

#213
post #146
post #13

This reminds me of when Slack shutdown its IRC bridge [0], and in a pretty negative way. I get that usage is down, but that tends to happen. Supporting niche users is how you win customer goodwill. The active users of SVN on GitHub clearly aren't going to switch to git, and I can respect the maintenance costs, but they're probably just going to switch to a different provider. For them, their workflow is now in-danger…

I relate here with Atlassian discontinuing their Jira Server product. I suppose they did the analysis and it wasn’t worth their dev time but there are some customers who CANT move to Jira Cloud for compliance reasons. So now we are stuck. Stick with unsupported Jira Server, pay $40k/yr for Jira Data Center (!!) or switch with all the business costs associated with that.

Given the datacenter product still exists, I'm fairly sure dev time is not why Atlassian does that.

Re: GitHub Sunsetting Subversion Support

#214
post #66

Earlier quoted context omitted.

I use Subversion at my gig in several places. I don't use it to manage source code revision control, but I have several processes that require business users to manage binary files (such as audio files) in order for them to be automatically deployed to production. Git or Mercurial are pretty awful at this kind of role. Subversion let's me check out at a subfolder level of a repository, and not pay the cost of having…

Git is much better at it nowadays thanks to Git LFS which just stores the blobs.

in exchange for yet another set of things to worry about to explain to/debug for non-technical users.

Re: GitHub Sunsetting Subversion Support

#215

Earlier quoted context omitted.

You mean the internet being actually lighthearted and fun (like it used to be) for 36 hours?

There is nothing funny or lighthearted about modern-day Internet April Fools. It is too ingrained in ‘social media marketing’ culture at this point. What used to be ‘people having fun’ is now a temporal dumping ground for a bunch of unfunny forced jokes pumped out by soulless marketing teams as some sort of brand awareness exercise. Bring back Google TISP I say.

Bring back Slashdot, OMG Ponies!

Re: GitHub Sunsetting Subversion Support

#217

Earlier quoted context omitted.

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 s…

> 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 yo…

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

Re: GitHub Sunsetting Subversion Support

#218
post #12

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done. We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it…

> … I'm surprised to some degree that it's still running 13 years later …

Nothing lasts longer than a temporary fix.

Re: GitHub Sunsetting Subversion Support

#219
post #12

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done. We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it…

My company only moved from subversion to got 3 years ago.

Re: GitHub Sunsetting Subversion Support

#220
post #214
post #66

Earlier quoted context omitted.

Git is much better at it nowadays thanks to Git LFS which just stores the blobs.

in exchange for yet another set of things to worry about to explain to/debug for non-technical users.

I don't think the intended audience for Git LFS is non-technical users.
Post reply on HN