Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

171–180 of 238 posts

Re: GitHub Sunsetting Subversion Support

#171
post #165

Earlier quoted context omitted.

Just because I don't get to talk about this much, as far as centralized version control goes, I liked Perforce when I used it. It could store everything: assets, builds, source code all in one, and you could do fine grain checkouts (I think git structures this as shallow clones but they're hard to get right). It also let you put permissions on the repository itself, so if you didn't have the correct ACLs you couldn't…

Perforce is still popular with games developers. It scales pretty well, even if you have tons of stuff in your depot, and since all the state is on the server the disk space cost locally is just the data. As you say, you can just put everything in there, and use it as your centralized file store for distribution of absolutely everything. Not unusual to have the CI system just commit the results back into Perforce, an…

What is the best public source on how Perforce works?

Re: GitHub Sunsetting Subversion Support

#172
post #135

Earlier quoted context omitted.

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

I don't know if he was selling a product. Git is a FOSS utility, after all. GitHub and others came much later, and have no affiliation with the Git project or Torvalds (some might not know this). Torvalds created Git for the Linux Kernel folks, and didn't really care if it was used anywhere else. Torvalds only went about creating Git because BitKeeper and the Kernel folks had a very public falling-out (much to BitKee…

Selling has more connotations than earning money. If he is at a Google event he is promoting it.

Re: GitHub Sunsetting Subversion Support

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

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

Obviously it's unimportant compared to the rest of the post, but, in case you like to know, the feature is your brainchild. You would be its brainparent, I guess.

Re: GitHub Sunsetting Subversion Support

#174

Earlier quoted context omitted.

source.php.old.ReallyOld.bak.thistimeitsold.old

I wonder how much PHP source code is publically reachable out on the Internet because people would do this without realizing that modphp wouldn't treat it like a PHP file anymore, so an HTTP request to it would cause it to dump the file's source code.

index.php~ for anyone using Emacs

Re: GitHub Sunsetting Subversion Support

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

Yes, as you say, I'd have to write the commit names down, and eventually they would get garbage collected. You could tag, but then you are just polluting your tag namespace with old branches.

You can also search logs to recover a commit, besides the other ways mentioned.

> ok but then I lose it's nice handle.

Then don't delete the handle? Maybe rename it with a `deleted/` prefix?

It's hard to imagine what the expected behaviour is when branch names are just local convenience labels.

Re: GitHub Sunsetting Subversion Support

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

[deleted]

Re: GitHub Sunsetting Subversion Support

#177

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?

Re: GitHub Sunsetting Subversion Support

#178

Earlier quoted context omitted.

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.

[deleted]

Re: GitHub Sunsetting Subversion Support

#179

Earlier quoted context omitted.

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.

Why not an HTTP server with a directory index? FTP is a pretty clunky protocol: it's round-trip heavy, not friendly to NAT on the client-side when you don't use PASV, not friendly to firewalls on the server-side when you do. I'm not sure what benefits there are to it these days.

https://github.com/sigoden/dufs

A file server that supports static serving, uploading

MIT/Apache-2 in Rust

Re: GitHub Sunsetting Subversion Support

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

I’ll add to that:

8. Naming of commands is sensible and inline with other similar tools.

9. No major issues with large files in your repo.

10. No flamewars break out online if you admit you don’t understand how part of the tool works.

Post reply on HN