3 ms·

At least one big company that was using Perforce to store tons (TB's+) of binary assets that was looking to migrate to Git after talking it over with them I end

by icefox 14y ago

At least one big company that was using Perforce to store tons (TB's+) of binary assets that was looking to migrate to Git after talking it over with them I ended up recommended they stick with Perforce. For users that are just looking for a place to store files and not looking to take advantage of features of a distributed revision control system Git isn't the best solution. A good example is a special effects company where you have a massive amount of assets (PB?) including storing multiple copies of each frame in full resolution raw for the movie. If it you only wanted HEAD local hard drives can't even hold all that data and you only want to work with small parts at a time. For this situation stock Git is absolutely not what you want. Before anyone tries to sell you that "of course Git scales" you really need to find out more information. Git does have large file support via extra tools that solve it in a handful of different ways, (sidenote one tool: bup is a very very cool from a technical perspective). With large repositories you must also find out are you dealing with a lot of small files or a handful or large files. Windows for example will fall on its face if you try to dump it with a ton of files which git will stat (say just a 4GB git repo) when you run git status while linux can't handle it with no problem. Once you get beyond 4GB in repository size you need to evaluate the problem more closely. Nine times out of ten it has been as simply as splitting the repo into two, one that contains the source and is 1GB and leaving the 399GB of binaries (for 6 platforms, debug and release, etc etc) in a better long term archive storage system be that another git repo using one of the above tools, perforce, or most likely some server that IT manages. An easy way to look at the 400GB repo is today I doubt you are syncing all 400GB to your laptop from perforce (Stock macbook air's max out at only 256GB for example) so how is your perforce client setup? What data does it grab? which data does it leave on the server?

to3m 14y ago
The point about using separate storage is reasonable. Leaving aside the issue of locking binary files, having to potentially use multiple systems or repositories is partly my stumbling block when it comes to any serious replacement to perforce. There are real benefits to having just one system, and having absolutely everything in just one place. One set of revision numbers, one client program. And, most importantly, no need to think about what to do if you have something you want to keep (aside from putting it in an appropriate folder, as you rightly point out). If you want to keep it, it goes in perforce. Doesn't matter what it is, or how much of it there is, perforce will take it. And that's that. I've seen the annoyances of using multiple depots/databases/repos/etc. with Alien Brain in the past, and that was just one system. Now I'm working on a smaller project that uses both git and SVN, and even though it's a smaller project, it's still annoying today. Being able to have just one system, that can swallow absolutely everything without a fuss (while not being especially annoying to use, like Alien Brain was), is a big advantage.
- icefox 14y ago
  Well don't put Perforce on such a high horse. Yes it can hold a lot of data, but one common reason brought up from corporate IT guys about why they were looking into Git was that they were having some problems scaling Perforce. From downtime to storage issues, cpu's overloading, etc. The lag from a remote office was annoying, the read-only replication servers had some annoying bugs that forced some users to abandon it, etc. On more than one occasion I have heard horror stories about the lag if you want to sync from 8:30-9:30 in the morning or are trying to sync/commit at 5pm in a large development office. Various perforce commands are very expensive and they all run on the server side so the equivalent of git blame can really tax the server. And if the server ever went down unlike Git you can't keep working. All of the above means you need beefier and more expensive Perforce servers. And don't forget about the licensing costs! Sure Perforce is nice, but it is hardly perfect. No product is perfect and for every situation you want to evaluate what the real issues that need to be solved and make the tradeoff's necessary.

by icefox 14y ago

to3m 14y ago

The point about using separate storage is reasonable. Leaving aside the issue of locking binary files, having to potentially use multiple systems or repositories is partly my stumbling block when it comes to any serious replacement to perforce. There are real benefits to having just one system, and having absolutely everything in just one place. One set of revision numbers, one client program. And, most importantly, no need to think about what to do if you have something you want to keep (aside from putting it in an appropriate folder, as you rightly point out). If you want to keep it, it goes in perforce. Doesn't matter what it is, or how much of it there is, perforce will take it. And that's that. I've seen the annoyances of using multiple depots/databases/repos/etc. with Alien Brain in the past, and that was just one system. Now I'm working on a smaller project that uses both git and SVN, and even though it's a smaller project, it's still annoying today. Being able to have just one system, that can swallow absolutely everything without a fuss (while not being especially annoying to use, like Alien Brain was), is a big advantage.

icefox 14y ago
Well don't put Perforce on such a high horse. Yes it can hold a lot of data, but one common reason brought up from corporate IT guys about why they were looking into Git was that they were having some problems scaling Perforce. From downtime to storage issues, cpu's overloading, etc. The lag from a remote office was annoying, the read-only replication servers had some annoying bugs that forced some users to abandon it, etc. On more than one occasion I have heard horror stories about the lag if you want to sync from 8:30-9:30 in the morning or are trying to sync/commit at 5pm in a large development office. Various perforce commands are very expensive and they all run on the server side so the equivalent of git blame can really tax the server. And if the server ever went down unlike Git you can't keep working. All of the above means you need beefier and more expensive Perforce servers. And don't forget about the licensing costs! Sure Perforce is nice, but it is hardly perfect. No product is perfect and for every situation you want to evaluate what the real issues that need to be solved and make the tradeoff's necessary.