Perforce is not fast, it cheats: You tell the server in advance what you are doing, so that the submit is fast. This comes at a tremendous price: Your editor/IDE has to have a perforce plugin to do what should be the VCS' job (tell perforce what is happening in your workspace), and the connection to the server has to be reliable and low latency, lest you want to spend seconds every time you make an edit in a file that has not been checked out already.
In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.
Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce.
There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
> Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce.
Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits.
Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase).
Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.
I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't.
When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about.
> I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't.
Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries.
However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.
I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.
> Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.)
With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
The GP's words were: "With git, you don't have to worry about it."
I never said that perforce would perform in any way better, but I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. Try pushing your changes via email to your CI server. Fully decentralized would be beautiful, but I seriously don't see many teams that use git (or any other system) in that manner. Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.
> I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around.
I agree. The first time I read your argument, I interpreted it as a reason to not use git itself, but I think we're on the same page.
> Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.
What else can be done? I don't really want to push changes to my co-workers individually, I want a place to push changes that any co-worker can then pull from — do I not? Toward this goal, certainly I could create n servers, and make pushing redundant over those n servers, have then do consensus to agree on HEAD, etc., but that seems to me to be what I'm paying GitHub to do.
There are good managed git services for companies that don't want to run their own. If my sysadmins are truly incompetent I can use a free private bitbucket repository.
I have used it for some full moons. I didn't like it. This was before I learned about DVCS, so my only real reference was SVN, but for what I did (medium-size business apps, a few years of history) I can't say it felt faster than SVN.
OTOH Perforce had some serious downsides like
* immature eclipse plugin (would crash eclipse more
than once a week, forcing a full reset every.single.time)
* no Netbeans plugin (back then)
* the whole idea of having to decide in advance, -while in
the office or otherwise connected, which files you
needed to modify and therefore "check out" -
* which brings me to the next problem: by default only one
person can work at a file at the same time.
YMMW, I see some people liking Perforce, OTOH I see people using Macs for coding as well. (That last part is tongue-in-cheek, yes, I really wish I liked Macs and I recommend everyone to consider them.)
Perforce sucks. From a UX perspective, it really is rotten. Furthermore, contrary to popular belief, it scales poorly.
Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo.
I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.
Hacker News is a website (so even with their code being open-sourced, I cannot verify what exactly they're running anyway), not software I'm running (JS aside).
The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that.
I can choose not to run proprietary software without having to not use the web.
I avoid it as much as I possibly can. I don't know what more to tell you. I never said I'm proprietary code-free, but just that I avoid it at all costs.
Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.
