GitHub Sunsetting Subversion Support • Hacker News Board

Re: GitHub Sunsetting Subversion Support

#191

Post by scarface74 » Sat, Jan 21, 2023, 4:35 AM UTC

rsstack wrote: post #93

magicalhippo wrote: post #64

Earlier quoted context omitted.

We use SVN still. I'd like to switch to Git soon, given tooling like CI/CD is better/more available with Git, but apart from that it works. That said, SVN works, and I do think the learning issue is the primary obstacle for us moving to Git. It should be said we're a small team though, 10 devs. I can imagine Git looking a lot more attractive to a larger team.

Almost a decade ago, I was part of a 10 person team (that was growing) and while there was consensus around transition to Git, it kept getting pushed back. I eventually forced the issue by changing the deployment job in Jenkins for one of the main projects to deploy from Git instead of SVN. I had to give several talks to existing and new employees about how Git works and how to use it. I was also that #1597 guy ( htt…

I worked for General Electric back between 2012-2014. My department brought a trainer in who worked for GitHub for a two day class on git.

Re: GitHub Sunsetting Subversion Support

#192

Post by adql » Sat, Jan 21, 2023, 4:41 AM UTC

somerando7 wrote: post #41

kypro wrote: post #25

I'd love to hear from someone who's still using SVN professionally and can explain why they prefers it to Git. I used SVN very early in my career. I think the only good thing I can say about it is that it's easier to learn. It's quite easy to teach a junior dev how to use SVN. Git takes much longer to master.

What's better about git? I haven't used svn, but have used perforce/mercurial professionally/git professionally, and use git personally, but I find all of them to provide the same "feature set" when doing basic development: have your own branch, and merge it in to the main branch when done/reviewed. Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but ha…

> Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but haven't seen that being used anywhere really.

Much better working merges was reason many people moved to SVN but since then SVN just got better at it

Re: GitHub Sunsetting Subversion Support

#193

Post by zerocrates » Sat, Jan 21, 2023, 4:53 AM UTC

avgcorrection wrote: post #147

ynik wrote: post #143

Earlier quoted context omitted.

It fails if someone merges main into their feature branch, and then performs a fast-forward merge of their feature branch to main. Now the two parents are in the opposite of the expected order, and --first-parent will follow along the feature branch. This can cause the new state of main to have a lower number of first-parent-commits than prior to the merge! However, if you have infrastructure that prevents fast-forwa…

> However, if you have infrastructure that prevents fast-forward merges to main I did say merge, did I not? Yes. > > If you have a main branch which is always merged into then If fast-forward is a “merge” too then fuck it, I can’t be bothered to use Git lingo since every idiotic little thing needs to be qualified (see also: Git tag, which is sometimes only an annotated tag but also sometimes also its cousin “lightwei…

People will tend to think of a fastforward as a "merge" of sorts since it will happen when you run "git merge," when possible.

Re: GitHub Sunsetting Subversion Support

#194

Post by fdr » Sat, Jan 21, 2023, 5:06 AM UTC

ivanmontillam wrote: post #177

neallindsay wrote: post #108

I remember when they added Subversion support; I thought it was hilarious. And it worked! This quote from the linked blog post made me raise my eyebrows though: > In 2010…it was not yet clear that distributed version control would eventually take over, and even less clear that Git would be the dominant system. I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hostin…

> At that point in time, it was not yet clear that distributed version control would eventually take over, and even less clear that Git would be the dominant system. Literally reading it on GitHub's blog, where the whole endeavor has the name of a source control system in it. Jokes aside, did they knew Git was going to win or did they just take on a massive risk that would otherwise gone wrong?

The risk. It's probably hard to imagine, but Github was promising, but small back then. You can't put one egg in three baskets.

Re: GitHub Sunsetting Subversion Support

#195

Post by joshu » Sat, Jan 21, 2023, 5:27 AM UTC

wayvey wrote: post #181

joshu wrote: post #155

Earlier quoted context omitted.

This is the right way to do April Fool's. Similarly, I added support to del.icio.us for color: urls for april fool's. It worked, correctly, everywhere.

what did it do?

instead of a url, it would just show a rectangle of color.

Re: GitHub Sunsetting Subversion Support

#196

Post by adra » Sat, Jan 21, 2023, 5:51 AM UTC

kejaed wrote: post #146

Shank wrote: 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.

They want those subscription revenues and that's as simple as that. In 2-5 years server will be back as never before but you'll be paying a subscription rate.

Re: GitHub Sunsetting Subversion Support

#197

Post by Sniffnoy » Sat, Jan 21, 2023, 6:08 AM UTC

schacon wrote: 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…

> brainchild

I have to point out that you've reversed the meaning of this word...

Re: GitHub Sunsetting Subversion Support

#198

Post by jesuspiece » Sat, Jan 21, 2023, 6:09 AM UTC

When are we going to admit to ourselves that everything else is worse than git?

Re: GitHub Sunsetting Subversion Support

#199

Post by vvanders » Sat, Jan 21, 2023, 6:22 AM UTC

neallindsay wrote: post #108

I remember when they added Subversion support; I thought it was hilarious. And it worked! This quote from the linked blog post made me raise my eyebrows though: > In 2010…it was not yet clear that distributed version control would eventually take over, and even less clear that Git would be the dominant system. I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hostin…

Git was better for everything except binaries, but if you could afford it Perforce did much better there.

CVS though, uf da. We had some rough times in gamedev land until we moved over to SVN and then Perforce with proper proxies for a distributed team.

Re: GitHub Sunsetting Subversion Support

#200

Post by djur » Sat, Jan 21, 2023, 6:29 AM UTC

Shank wrote: 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…

> The active users of SVN on GitHub clearly aren't going to switch to git

Seems likely to me that some significant percentage of GitHub SVN usage comes from decade-old scripts running on a build server somewhere. I suspect most of those users will choose to rewrite the script rather than moving to a new provider.