Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

51–60 of 238 posts

Re: GitHub Sunsetting Subversion Support

#51
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 when nobody is really facing that issue anymore.

It's still running because Subversion has better CLI.

PS The joke is not that funny when it lasts for 13 years. Ha-ha, how funny (not).

Re: GitHub Sunsetting Subversion Support

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

[deleted]

Re: GitHub Sunsetting Subversion Support

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

"easier to use" a great reason to prefer it. I want to write software, not manage a source control system.

Re: GitHub Sunsetting Subversion Support

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

[deleted]

Re: GitHub Sunsetting Subversion Support

#55
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 the full revision history contents sitting in my clone.

Re: GitHub Sunsetting Subversion Support

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

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

Re: GitHub Sunsetting Subversion Support

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

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

There is also this: https://github.com/msofficesvn/msofficesvn

Re: GitHub Sunsetting Subversion Support

#58
post #18

Earlier quoted context omitted.

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.

> The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server

Though it only logs refs that the server itself has seen, which is more or less what I meant by "local". None of its state is shared during push/pull, it's computed entirely based upon what some individual client/server directly observes.

Re: GitHub Sunsetting Subversion Support

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

I think April 1st should definitely be "Crazy-but-real announcement day". It'll take some attention off the unfunnier-every-year "jokes" which have turned a pleasant and fun yearly occasion into the internet being unusable for ~36 hours.

Re: GitHub Sunsetting Subversion Support

#60
post #11

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

We used it at my first job, up until a disgruntled contractor locked every single file in our repo on the day he got fired. We couldn't do a damn thing for like a week, until we migrated to... TFS, sadly, but even that was an improvement.
Post reply on HN