> Wow I'm surprised game development is still like that. Some of the problems are fundamental. We're forced to use certain compressed and signed packaging sch

> Wow I'm surprised game development is still like that. Some of the problems are fundamental. We're forced to use certain compressed and signed packaging schemes which aren't sanely delta compressable. We distribute in self contained blobs because not everyone has older versions lying around, or will not have a worthwhile pipe when they get to where they need to install things and will further sneakernet on their end. Even if we did assume sane deltas are possible, simple information density puts a lower bound on patch size based on how much content changed, and even that theoretical lower bound can frequently be too much and take too long for relatively "beefy" pipes. Heck, even with fiber, people will still be saving these things out to USB drives for good reason. > Then you can actually sync data from your neighbor's machine, in a BitTorrent-ish fashion (possibly getting tiny amounts of metadata from a central server for consistency). Perforce definitely has problems with spurious lock contention, and just a few team members syncing from the same machine can easily clog its pipes if you're not careful. That helps if the bottleneck is the server. Our perforce machines are beefy enough that our bottlenecks are frequently the client and the LAN pipe, neither of which will be helped by BitTorrent style networking. Work from home would be 100% pipe bottlenecked, as the work pipe is able to saturate it quite easily. FTP is still bottlenecked by either the developer's or the publisher's pipe, and wouldn't be helped by p2p either. > I'm not up to date, but I'm pretty sure you can do better than Perforce's delta compression. There's always room for incremental improvements... but not enough to beat out fiber. > You actually want to avoid single-file compression in the repository so you can take advantage of the differential compression. Not always possible due to format requirements. Windows 8 .appx packages, for example, are basically self contained signed .zips containing an application and all it's resources. Want to provide three builds? You just compressed and signed three different entire copies of all your built resources. For bonus points, those were .zip ed again. Insanity! But software cannot magically solve the social problems that let such designs reach the marketplace. And since things break unless you use the exact "correct" certificate for signing, any script that generated the .appx from one set of resources would require distributing the actual private key which is a non starter...