4 ms·

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

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 hosting the Linux kernel. And forget even about its distributed nature; Git was already better at the centralized model than "centralized-only" version control systems ever were. When Subversion came out I was overjoyed; finally someone had fixed most of the broken things about CVS. I jumped on it with gusto. But when Git came out it was so much better than SVN that I was blown away. And it wasn't long before there were great tools to translate between SVN and Git. By the time Github released its SVN bridge feature I think the place I was working at had already used those freely-available tools to move our old SVN repos to Git with full history. It was so easy to do! The only hard part was organizing all the developers to stop using the SVN server and switch to pushing to the Git server at the same time. Sometimes a new technology comes out and it's immediately obvious that it's the future. The ones that come to mind for me are Git, the iPhone, and node.js.

yoden 4y ago
> I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hosting the Linux kernel. And forget even about its distributed nature; Git was already better at the centralized model than "centralized-only" version control systems ever were. I think you're forgetting about Mercurial, which was also created by a Linux kernel developer around the same time. It brought all the same benefits of git, but had a simpler command line API and better cross platform support. Mercurial saw wide use, especially in large corporations like Facebook. Indeed, a lot of people will say that it was the success of github itself that pushed git over the top. In a world where bitbucket won instead of github, we could all be using mercurial. Although I've never used it, I'm not sure how much of an improvement either of these was over BitKeeper. The primary impetus to create git and mercurial was licensing changes in BitKeeper, not technical deficiencies.
- neallindsay 4y ago
  Maybe I'm the weird one, but Mercurial never made sense to me. I thought that Git's model made perfect sense. I never tried BitKeeper, so I can't speak to that. But being proprietary seemed to doom it.
  - bionade24 4y ago
    I also do not understand why people claim that mercurial is more beginner-friendly. Especially putting relatively basic features into optional modules is very confusing in the beginning.
no_wizard 4y ago
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 see part of the code. It was really good for monorepos. It has its quirks, and when I used it, could be a bit slower on the execution side, but generally thought it was really nice. I also maintain that Mercurial & Fossil are superior to git, but git won the marketshare so its kinda moot now.
- tom_ 4y ago
  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, and that's how everybody gets updated builds or data. History is per-file, so (in effect) you can treat any folder as a submodule, which simplifies having an enormous multi-project monorepo. This is something I've never done much with personally, but colleagues have had good results leveraging this to look after shared code that's used by multiple projects at different revisions. The check in/check out model is also quite easy to reason about, and works well for the non-mergeable binary files that most games developers work with. (Programmers seem to kind of like it when they have some horrid complicated thing to get to grips with, that comes with a pile of new terminology and endless ways to cause yourself increasingly painful problems. Artists, designers and production staff... not so much.) Main issues with Perforce: - nobody seems to work on the product any more. If it's changed at all in the past 10 years, it's changed in some part that I, user of p4v (the GUI client) and p4 (the command line client) haven't found obvious - the command line experience is pretty terrible, as it's inconsistent, and not very well documented, and the supposedly machine-readable output mode quite often just feeds you nothing more than an array of the same strings you'd see using the normal mode. But I can't deny that you can usually eventually get it to do what you want, provided you can assume the server charset - the offline experience is rather poor! But this is increasingly less of a problem over time, and that process will continue Somebody please figure out how to eat Perforce's lunch. We discuss this occasionally at work, but we're too busy working on actual projects...
Aeolun 4y ago
None of those except for the iPhone were obvious to me. And in hindsight I’m happy I only switched to Git and Node when they’d matured a bit.
ivanmontillam 4y ago
> 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?
- jen20 4y ago
  My guess is that GitHub is what ensured Git won.
- fdr 4y ago
  The risk. It's probably hard to imagine, but Github was promising, but small back then. You can't put one egg in three baskets.
vvanders 4y ago
Git was better for everything except binaries, but if you could afford it Perforce did much better there. CVS though, uf da. We had some rough times in gamedev land until we moved over to SVN and then Perforce with proper proxies for a distributed team.

yoden 4y ago

> I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hosting the Linux kernel. And forget even about its distributed nature; Git was already better at the centralized model than "centralized-only" version control systems ever were. I think you're forgetting about Mercurial, which was also created by a Linux kernel developer around the same time. It brought all the same benefits of git, but had a simpler command line API and better cross platform support. Mercurial saw wide use, especially in large corporations like Facebook. Indeed, a lot of people will say that it was the success of github itself that pushed git over the top. In a world where bitbucket won instead of github, we could all be using mercurial. Although I've never used it, I'm not sure how much of an improvement either of these was over BitKeeper. The primary impetus to create git and mercurial was licensing changes in BitKeeper, not technical deficiencies.

neallindsay 4y ago
Maybe I'm the weird one, but Mercurial never made sense to me. I thought that Git's model made perfect sense. I never tried BitKeeper, so I can't speak to that. But being proprietary seemed to doom it.
- bionade24 4y ago
  I also do not understand why people claim that mercurial is more beginner-friendly. Especially putting relatively basic features into optional modules is very confusing in the beginning.

no_wizard 4y ago

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 see part of the code. It was really good for monorepos. It has its quirks, and when I used it, could be a bit slower on the execution side, but generally thought it was really nice. I also maintain that Mercurial & Fossil are superior to git, but git won the marketshare so its kinda moot now.

tom_ 4y ago
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, and that's how everybody gets updated builds or data. History is per-file, so (in effect) you can treat any folder as a submodule, which simplifies having an enormous multi-project monorepo. This is something I've never done much with personally, but colleagues have had good results leveraging this to look after shared code that's used by multiple projects at different revisions. The check in/check out model is also quite easy to reason about, and works well for the non-mergeable binary files that most games developers work with. (Programmers seem to kind of like it when they have some horrid complicated thing to get to grips with, that comes with a pile of new terminology and endless ways to cause yourself increasingly painful problems. Artists, designers and production staff... not so much.) Main issues with Perforce: - nobody seems to work on the product any more. If it's changed at all in the past 10 years, it's changed in some part that I, user of p4v (the GUI client) and p4 (the command line client) haven't found obvious - the command line experience is pretty terrible, as it's inconsistent, and not very well documented, and the supposedly machine-readable output mode quite often just feeds you nothing more than an array of the same strings you'd see using the normal mode. But I can't deny that you can usually eventually get it to do what you want, provided you can assume the server charset - the offline experience is rather poor! But this is increasingly less of a problem over time, and that process will continue Somebody please figure out how to eat Perforce's lunch. We discuss this occasionally at work, but we're too busy working on actual projects...

Aeolun 4y ago

None of those except for the iPhone were obvious to me. And in hindsight I’m happy I only switched to Git and Node when they’d matured a bit.

ivanmontillam 4y ago

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

jen20 4y ago
My guess is that GitHub is what ensured Git won.
fdr 4y ago
The risk. It's probably hard to imagine, but Github was promising, but small back then. You can't put one egg in three baskets.

vvanders 4y ago

Git was better for everything except binaries, but if you could afford it Perforce did much better there. CVS though, uf da. We had some rough times in gamedev land until we moved over to SVN and then Perforce with proper proxies for a distributed team.