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…
GitHub Sunsetting Subversion Support
171–180 of 238 posts
Re: GitHub Sunsetting Subversion Support
#172Earlier 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…
Re: GitHub Sunsetting Subversion Support
#173As 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…
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
#174Earlier 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.
Re: GitHub Sunsetting Subversion Support
#175Earlier 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.
> 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
#176As 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…
Re: GitHub Sunsetting Subversion Support
#177I 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…
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
#178Earlier 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.
Re: GitHub Sunsetting Subversion Support
#179Earlier 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.
A file server that supports static serving, uploading
MIT/Apache-2 in Rust
Re: GitHub Sunsetting Subversion Support
#180I'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…
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.