4 ms·

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king

by TinkersW 11mo ago

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

steveklabnik 11mo ago
Right now, nothing special. But this is very much an area that's known about and something may happen in this area, we'll see.
- tombert 11mo ago
  If you could elegantly handle large or frequently-changing binaries I think I'd be willing to switch immediately. It has always annoyed me that there's not any clever way to handle binary changes with version control.
jasonpeacock 11mo ago
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.
- dafelst 11mo ago
  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.
- tom_ 11mo ago
  1. Perforce checkout requests always do the round trip to the server. 2. Artists can actually understand Perforce.
  - jasonpeacock 11mo ago
    > 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.
    - tom_ 11mo ago
      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!)
- bananaboy 11mo ago
  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.
  - jasonpeacock 11mo ago
    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.
    - dijit 11mo ago
      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.
      - jasonpeacock 11mo ago
        Not a belief, but my experience. Maybe I've had a blessed experience with LFS? It's always "just worked" for me.
        dijit 11mo ago
        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.
zamalek 11mo ago
It uses Git for storage and does not support LFS, so it's as bad as Git used to be for this specific usecase.
- steveklabnik 11mo ago
  LFS sorta kinda works in my understanding, it’s not super nice yet though.

steveklabnik 11mo ago

Right now, nothing special. But this is very much an area that's known about and something may happen in this area, we'll see.

tombert 11mo ago
If you could elegantly handle large or frequently-changing binaries I think I'd be willing to switch immediately. It has always annoyed me that there's not any clever way to handle binary changes with version control.

jasonpeacock 11mo ago

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.

dafelst 11mo ago
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.
tom_ 11mo ago
1. Perforce checkout requests always do the round trip to the server. 2. Artists can actually understand Perforce.
- jasonpeacock 11mo ago
  > 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.
  - tom_ 11mo ago
    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!)
bananaboy 11mo ago
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.
- jasonpeacock 11mo ago
  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.
  - dijit 11mo ago
    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.
    - jasonpeacock 11mo ago
      Not a belief, but my experience. Maybe I've had a blessed experience with LFS? It's always "just worked" for me.
      - dijit 11mo ago
        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.

zamalek 11mo ago

It uses Git for storage and does not support LFS, so it's as bad as Git used to be for this specific usecase.

steveklabnik 11mo ago
LFS sorta kinda works in my understanding, it’s not super nice yet though.