Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

71–80 of 238 posts

Re: GitHub Sunsetting Subversion Support

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

A few different SVN -> Git migration tools failed to migrate a large legacy repo at a previous employer. I thought I was doomed to be stuck on subversion forever.

It was GitHub's migration that finally worked and got us migrated across.

Funny we were only svn because I had previously been part of an effort to migrate them to svn when I'd joined a few years prior because before that they were using an old TFS system where developers would block each other by checking out files which would lock them for the whole repo.

I knew that switching immediately to git would have been too much of a culture shock so I got them over to a CVS where people could at least work independently first. ( I also have a soft spot for svn anyway, I think for many small teams it works just as well as git with fewer opportunities to shoot oneself in the foot. )

Re: GitHub Sunsetting Subversion Support

#73
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…

> I've heard that git branching is better(?), but haven't seen that being used anywhere really.

How are you merging without branches?

Git is mostly faster and more flexible than svn, and the merging works far better. Unless svn's merging has improved in the past decade or so, which is entirely possible.

When I switched to git from svn, the main differences were: merging was usable, making new branches and switching branches and such were _instant_ instead of many seconds, and I could work more flexibly (git doesn't require being connected to the server).

Re: GitHub Sunsetting Subversion Support

#74
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…

If my memory is correct, the content on svnhub.com used to look different back then, was it related to the April Fool's Day joke?

https://svnhub.com/

Re: GitHub Sunsetting Subversion Support

#75
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…

Core Git is not the greatest at large binaries, so for that you indeed probably want an addon like git-annex or Git LFS or an alternative such as dvc, but in recent versions it absolutely can[1] only give you only part of the history or part of the objects: the former is known as “shallow clones”, the latter as “partial clones” (there are also “sparse checkouts”[2], but those only concern the working tree IIUC).

[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-...

[2] https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...

Re: GitHub Sunsetting Subversion Support

#76
post #32
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.

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.

Re: GitHub Sunsetting Subversion Support

#77

Is there an alternative way to download select folders without svn?

> Why do people still use Subversion on GitHub, anyhow? Besides simple inertia, there were workflows which Git didn’t support until recently. The main thing we heard when speaking with customers and communities was checking out a subset of the repository–a single directory, or only the latest commit. I have good news: with sparse checkout, sparse index, and partial clone, Git can now do a pretty decent job at these workflows.

Re: GitHub Sunsetting Subversion Support

#78

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.

I was about to respond with WebKit but it looks like they switched to git last July.

Re: GitHub Sunsetting Subversion Support

#79

There is only one thing about subversion I miss when using git -- the deletion of branches (which were, admittedly, just directories in a folder called branches) was version controlled, so you could recover deleted branches.

Conversely, the deletion of branches is version-controlled in git, because when someone force-pushes or deletes a branch on the remote it can still be restored from anyone's clone :)

I've seen this happen a few times with a dev running `git push -f` with the intent to update their dev branch, except that it would force-push all branches in their clone that were associated with the remote, like master. It probably doesn't happen these days though, because the default was changed at some point to only push the current branch.

Re: GitHub Sunsetting Subversion Support

#80
post #11

How about Visual SourceSafe? I actually loved that for a small team.

Are you serious? I'm not even sure if Visual SourceSafe is better than "Once a week I copy all the files into a ZIP and date it" as a strategy for version management.

for one thing, zips are far less likely to destroy data than sourcesafe, which was famous for doing just that
Post reply on HN