Hacker News Reader

Comment by shamiln | Hacker News Reader

Ugh Perforce...

Poor Perforce. Once upon a time it was a very useful and interesting product. For those of you who have only known a world of git, there was a time where a product like perforce was just awesome. Fast, functional, reasonably priced, and supported a variety of platforms (VMS!). But that was a long time ago.

Once git arrived, they didn't have the same place in the world and now its... a very different company.

The only advantage Perforce has, and the reason why giants such as Ubisoft have committed to it, is that "it handles large files better". That's it.

It also offers granular ACLs where git doesn't.

Also has partial checkouts, important for huge repos.

Ive done partial checkouts in Git before as well.

Its called a "sparse checkout".

https://www.git-scm.com/docs/git-sparse-checkout

Yes, but (sorry for yelling, that's in the source)

> THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN THE FUTURE.

> The only advantage Perforce has,

Perforce is also ripping fast for updating/status checking, (run git status on the Unreal Engine repo to see the difference), is centralized (a feature, not a bug), has full support for partial and shallow checkouts. It also offers support for _running_ perforce, not just their hosted offering.

> and the reason why giants such as Ubisoft have committed to it

The reason companies like Ubisoft, Epic, etc use it is because it predates git.

> is that "it handles large files better". That's it.

Lets' not pretend that "better" is a good comparison. Until 5-6 years ago, git didn't handle large binary files at all. Even now, it's a "pick your poison".

Did they ever get over the idea that a version control system should try to prevent two people from modifying (or "checking out") a file at the same time? That always drove me insane. Every time I got on a plane I'd have to do whatever trick that was that let me edit files even though I never told the server I was going to, and deal with the consequence later. I don't exactly remember the details or how bad the consequences were, but it always seemed ridiculous.

Oh, and cloning a repo so you have a second copy of it for an experiment took ages because you couldn't just 'cp -a' the directory, you had to "enlist" in all the files with the server... I do not recall p4 fondly.

> Did they ever get over the idea that a version control system should try to prevent two people from modifying (or "checking out") a file at the same time?

Checking out is still a fundamental concept of perforce, and it's the reason it's so fast. Not all files need exclusive locks, that's usually reserved for binary assets (and is a selling point of perforce as it prevents an unsolvable merge conflict later on). When I started using perforce 13 years ago, every editor I used had either a perforce plugin, or an option to "checkout on edit or save",

> Oh, and cloning a repo so you have a second copy of it for an experiment took ages because you couldn't just 'cp -a' the directory, you had to "enlist" in all the files with the server...

I don't really see the problem. doing `cp -a` on a large git repo can be an extra 30GB if not more on disk. The tradeoff of a very uncommon operation (duplicating a repo for an experiment sounds like a great use for shelves in p4, or branches in git) taking longer for performance on the golden path seems like a really good one to me.

For me, duplicating a repo usually means i want the two different things side by side at the same time, rather than a single directory switching between branches.

It has a fantastic GUI three-way merge tool p4merge, which is available for free and works with git.

I miss its version of blame (time-lapse view) and wish there was a git gui that matched it.

Reply on news.ycombinator.com