GitHub Sunsetting Subversion Support • Hacker News Board

Re: GitHub Sunsetting Subversion Support

#121

Post by neallindsay » Fri, Jan 20, 2023, 10:17 PM UTC

yoden wrote: post #118

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…

> I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hosting the Linux kernel. And forget even about its distributed nature; Git was already better at the centralized model than "centralized-only" version control systems ever were. I think you're forgetting about Mercurial, which was also created by a Linux kernel developer around the same time. It brought all the sa…

Maybe I'm the weird one, but Mercurial never made sense to me. I thought that Git's model made perfect sense.

I never tried BitKeeper, so I can't speak to that. But being proprietary seemed to doom it.

Re: GitHub Sunsetting Subversion Support

#122

Post by woodruffw » Fri, Jan 20, 2023, 10:18 PM UTC

js2 wrote: post #103

woodruffw wrote: post #67

Only partially related, but since they mention it at the bottom of the post: I really like GH's "brownout" approach to discontinuing services. They've done it a couple of times before (like this one[1]), and it's always struck me as a very sensible way to handle deprecations on such a massive service. [1]: https://github.blog/changelog/2021-08-10-brownout-notice-api...

These are also known as scream tests. We use them internally at $dayjob as part of EOL'ing APIs. Are they not common?

I have no clue! I just appreciated them as a lowly user.

Re: GitHub Sunsetting Subversion Support

#123

Post by OkayPhysicist » Fri, Jan 20, 2023, 10:19 PM UTC

tcoff91 wrote: post #97

ProAm wrote: post #56

Earlier quoted context omitted.

> It's quite easy to teach a junior dev how to use SVN. Git takes much longer to master. This is pretty much it, ease of use. No one really knows git (beyond 5 commands). Everyone knows how to google git commands or talks to the wizard in the company that can fix the mess someone created. While in theory git is more powerful, in the art of getting things done easily SVN wins, simple, stupid and it works.

I remember having all kinds of strange issues with subversion that were hard to resolve as a novice, not being able to commit for cryptic reasons, etc... Perforce is the only tool I've used that was actually pretty simple, and even then I'd say that dealing with merging streams was not nearly as easy as merging git branches.

Heh, funny story about Perforce. I bumped into one of their founders at a camp I go to, real down to earth dude. We had struck up a conversation over a few drinks, and the conversation drifted over to what we did. He asked "You know version control software?", and I replied "Like Git?" and he just responded with an exasperated sigh.

Re: GitHub Sunsetting Subversion Support

#124

Post by xorcist » Fri, Jan 20, 2023, 10:24 PM UTC

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.

I don't "prefer" svn (or anything else), but if you are interested in what svn does differently than git, which can suit some use cases better, here are some suggestions:

1. The trivial commit graph makes some concepts easier. You know from the commit number which is more recent. There are no complex merges.

2. The above makes for useful GUIs. There are no git GUIs that a user can not aim at their own foot, and needs the real client to clean up the mess.

3. The lack of complex operations makes access control easier. You still have to manage hooks, but it's easier or at least with less unintended consequences.

4. All clones are sparse. Together with a zero copy data storage makes for some cute concepts, such as branches and tags and directories actually being the same object. Sparse clones can be very useful.

5. The system tracks file system operations, such as moves and copies. It can actually be used for things, directly and without heuristics. (This is actually the one point where I can say I prefer the svn way. Git could have done something similar without breaking the conceptual model and it would have been useful.)

6. The metadata is, or at least used to be, more developed for non-unix file systems. I'm not sure if this is still the case.

7. Storing binary data is somewhat less bad. But still bad.

All that said, outside of specialized applications I'm not sure there's much reason to use svn for any new projects. And if you use it, keep in mind that git works perfectly well with svn archives. They just become a linear graph with funny commits and you can use that familiar git tools.

Re: GitHub Sunsetting Subversion Support

#125

Post by filmgirlcw » Fri, Jan 20, 2023, 10:25 PM 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…

Thank you for building this. Best 13 year “joke” ever — and I do think it also did some good.

Re: GitHub Sunsetting Subversion Support

#126

Post by flandish » Fri, Jan 20, 2023, 10:29 PM 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…

Y’all should sunset it on April 1st.

Re: GitHub Sunsetting Subversion Support

#127

Post by _a_a_a_ » Fri, Jan 20, 2023, 10:37 PM 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…

And I just want you to know that I know of SVN's shortcomings but I do like it's comprehensibility very much, and though I use git it has caused me a lot of unnecessary pain. FYI.

Re: GitHub Sunsetting Subversion Support

#128

Post by jldugger » Fri, Jan 20, 2023, 10:42 PM UTC

kevincox wrote: post #76

TillE wrote: post #32

Earlier quoted context omitted.

Subversion fixed all the truly horrific things about CVS, it's quite adequate for centralized source control.

Reminds me of Linus Torvald's Google Tech Talk on Git. https://youtu.be/4XpnKHJAok8 > I see Subversion as being the most pointless project ever started, because the slogan for Subversion for a while was "CVS done right" or something like that and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.

I mean, he was definitely selling a product there. SVN was pretty good, barring the merge logic being a PITA.

Re: GitHub Sunsetting Subversion Support

#129

Post by gschoeni » Fri, Jan 20, 2023, 10:44 PM UTC

histriosum wrote: post #55

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.

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…

Been working on a version control system to solve this large binary file problem as well.

It's called Oxen and is initially targeted towards unstructured machine learning datasets, but could be good for this use case as well. Would love to get any feedback on it!

https://github.com/Oxen-AI/oxen-release

Re: GitHub Sunsetting Subversion Support

#130

Post by snickerbockers » Fri, Jan 20, 2023, 10:46 PM UTC

IgorPartola wrote: post #65

vtbassmatt wrote: post #16

Earlier quoted context omitted.

As the PM who ended up finally killing it, I (on behalf of the team) thank you for your "joke" that wasn't really a joke. It did help some customers who had legacy SVN workloads land on GitHub. I wanted to announce this on April Fool's Day, but just couldn't make the timing work.

Instead add FTP version control support with the ability to create backup files.

i'm still angry at mozilla and google for deprecating that, being able to set up a simple anonymous FTP server and send normies a link to it that they can open in their browsers was really convenient. Now if I want to use FTP i have to explain to them that they have to copy it into the windows file explorer or download filezilla.