Perforce’s binary support is basically equivalent to Git LFS, it does the same thing.
What does Perforce binary support have that Git LFS doesn’t?
AFAIK, the base issue that Perforce is already in use and it has enterprise support.
back
3 comments
I am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC.
Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.
From the user's perspective, when setup correctly Git LFS is transparent and they don't see the text pointers - the binary files are replaced on push and pull to the server.
It's the same user experience as Perforce?
Yes, Git is more low-level and it's possible to see those text pointers if you want to.
This is what you want to believe but its not true.
I’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers.
It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone after the call, and it’s clunky to use and to save.
… but technically the feature exists, so it’s harder to argue for better software thats fit for purpose, like miro or mural.
Not a belief, but my experience. Maybe I've had a blessed experience with LFS? It's always "just worked" for me.
But I’d make a guess that the majority of the files you’re working on are text based.
If the primary filetype you use is binary, you’ll start to feel the jank.
1. Perforce checkout requests always do the round trip to the server.
2. Artists can actually understand Perforce.
> Perforce checkout requests always do the round trip to the server
That's literally the antithesis of Git. If that's a requirement, then yeah - Git's the wrong thing.
It's like complaining that bicycles don't have motors like motorcycles. If it had a motor, it wouldn't be a bicycle.
The question as I recall was what Perforce does that Git LFS doesn't, so I'm sorry to disappoint but my hands were tied.
Anyway, I dunno, man. If you want binary files to work, some form of per-file mutex is indeed a requirement. And for this to work well, without being a lot of hassle (and regarding that, see point 2, which I note has been accepted without comment - not that I expected anything else, the argument that Git is the artist-friendly choice would be a difficult one to make), any modification of the mutex's state has to involve a round trip to ensure the info is up to date. You can't rely on something local, that only gets updated sometimes, because then the info can be out of date! Worst case, N people find out too late that they've all been making changes simultaneously, and now N-1 of them will almost certainly lose work.
(You might be inclined to moan at people for not going through the full process, but: we have computers now! They can do the full process for us!)