Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

Post reply on HN
Print view View original

31–40 of 238 posts

Re: GitHub Sunsetting Subversion Support

#31

Post by ceejayoz »

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…

> Until nobody believed us.

I remember having this problem with Gmail's "1GB for everyone!" April 1 announcement.

Re: GitHub Sunsetting Subversion Support

#32

Post by TillE »

jldugger wrote: post #6
doublepg23 wrote: post #4

Not sure I’m familiar with any projects using Subversion. I think the most odd-ball version control I’ve seen in prod is SQLite using Fossil (which does seem to have benefits over git) and OpenBSD sticking with CVS.

SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.

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

Re: GitHub Sunsetting Subversion Support

#33

Post by gmueckl »

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.

SVN is still simply unsurpassed by any other open source version control I know when it comes to the handling of large files and fine grained access control.

The truth is that git is pretty abysmal overall. There are commercial offerings that easily surpass it, if you are willing to pay.

Re: GitHub Sunsetting Subversion Support

#34

Post by masklinn »

avereveard wrote: post #26
jldugger wrote: post #6

Earlier quoted context omitted.

SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.

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…

> and a great way to handle merges

Nope. That took a very long while to be added. When the current crop of DVCS started appearing, one of their significant draw was actually that by necessity merges worked well. At the time, SVN made it extremely easy to fork branches, and almost impossible to merge them.

Per the official doc (https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmer...) merge tracking was introduced in subversion 1.5, released in May 2008. That's 3 years after the initial release of Git, Mercurial, and Bazaar.

Before then you had to keep note of what you'd merged by hand so you didn't double merge it, and that was distinctly not fun.

Re: GitHub Sunsetting Subversion Support

#35

Post by benatkin »

czx4f4bd wrote: post #22
benatkin wrote: post #15

GitHub hasn't heard of Docker? It seems they could use it to run Subversion without any effect on their git hosting. Just kidding, but remember back in the DotCloud days when they pointed out you could run Perl? That was pretty cool. https://news.ycombinator.com/item?id=2518526 > In 2010, when GitHub introduced Subversion support, the version control landscape was very different. That was waaaaay before Microsoft acq…

> Reminds me of how Microsoft dumped Atom (and then fauxpen-sourced VSCode before dumping the last remnants of Atom). I'm confused by this. Microsoft released the VS Code source in 2015, long before they acquired GitHub in 2018 and sunset Atom in 2022.

They moved Atom into de-facto maintenance mode much earlier than that, when VSCode was much less fauxpen-source than it is now.

Re: GitHub Sunsetting Subversion Support

#36

Post by arp242 »

doublepg23 wrote: post #4

Not sure I’m familiar with any projects using Subversion. I think the most odd-ball version control I’ve seen in prod is SQLite using Fossil (which does seem to have benefits over git) and OpenBSD sticking with CVS.

Apache httpd uses subversion.

That's the only example of a well-known project I could find that's not directly related to subversion itself. I'm sure there are others, but all the other ones I could recall have since migrated (usually to git).

Re: GitHub Sunsetting Subversion Support

#37

Post by adamsb6 »

This reminds me of the time on Something Awful that radium banned the one user that was using WebTV.

> About 91% of visitors are on Windows. Mac users make up 5% and Linux is 2%. The other 2% are permabanned IRC trolls browsing the forums with a text-based browser written in Ruby on OpenBSD. Oh yeah, we have one guy using WebTV but I banned him because WTF.

Re: GitHub Sunsetting Subversion Support

#38

Post by arp242 »

TillE wrote: post #32
jldugger wrote: post #6

Earlier quoted context omitted.

SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.

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

"cvs add image.jpg" and then discovering you can't just do that 2 years later after a fresh checkout was fun.

Re: GitHub Sunsetting Subversion Support

#39

Post by ecnahc515 »

stouset wrote: post #18
nighthawk454 wrote: post #14

Earlier quoted context omitted.

Just in case - you can in git as well. Branches are just pointers to a commit SHA, so can always create another pointer to the same commit and your branch is back. https://stackoverflow.com/questions/3640764/can-i-recover-a-...

I suspect GP knows this, but there's no way to go back and see what the branch ref was at a prior point in time. I believe they wish that refs themselves were versioned. And yes, I know they're kept in the reflog. But that is short-lived and (I believe) local rather than eternal and global like everything else in git.

The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server, so not much use in eg, GitHub. That being said, GitHub also exposes some of these details, for example: in PRs when you force push on your branch.

So in the general sense, there's no reason we can't have exactly what's being discussed, but it just doesn't exist yet.

Re: GitHub Sunsetting Subversion Support

#40

Post by jcadam »

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.

Not using it now, but the last project I was on that did was at a defense contractor about 5 years ago.

Basically, the lead engineer that was in charge of the new project set up what he liked before the rest of the team was in place. So when I was hired on the team consisted of me, a senior engineer who hadn't used subversion in years, and a bunch of junior engineers who were completely unfamiliar with it. No amount of pleading would get him to migrate to git.

It was partially a control thing, I think. He liked having full control of the repo to himself. The system architecture was also... dated.

Post reply on HN