3 ms·

The point about using separate storage is reasonable. Leaving aside the issue of locking binary files, having to potentially use multiple systems or repositorie

by 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 to3m 14y ago

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.