Hacker News Reader

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

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.

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.

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.

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

What is the best public source on how Perforce works?

Mecurial isn't superior to git, it's simpler. The stuff that people tend to "criticize" git for is useful complexity. Although, I suppose most of these features are available via extension now?

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

My guess is that GitHub is what ensured Git won.

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.

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.

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.