On Jul 1, 2005, at 3:45 AM, Jeremy Kemper wrote:

> On Jul 1, 2005, at 1:35 AM, Ryan Davis wrote:
>
>> These are all very good points, and with the exception of trac  
>> (although there is an open bug on this exception), all of these  
>> points are also supported by perforce.
>>
>
> Perforce a great product but it's never appropriate for large-scale  
> anonymous access due to its heavily-centralized design.  All  
> metadata is stored on the server.  Even asking what files you've  
> changed means a server hit.  And then you're stuck with host-based  
> or SSH auth.

"Never"? You know that when you see that on the SATs and other  
standardized tests that it is almost always false, right?

>> Perforce is free for open-source development and is used by larger  
>> groups like freebsd (http://perforce.freebsd.org/).
>
> FreeBSD restricts p4 to committers for the reasons above.  Their  
> metadata database is ~10GB for only ~120 users, so a beefy server  
> with lots of RAM is needed just for this modest team.

I don't really see how that is applicable here. 1) we have a much  
much smaller repo, even after duplicating out all of the branches; 2)  
ruby has a very sane branch methodology; 3) I worked at a company  
that had the largest integrate DB (merge metadata) that perforce has  
ever seen (gawkable in size, it was 6gig alone), and yet the server  
did fine unless a developer did something truly horrific. This was in  
a 5m LoC source base tho with 50-100 branches. I sat next to the p4  
admin. Sure, they made mistakes that caused pain now and then, but  
most of that is avoidable by #2 above.

I highly doubt we'll ever have a problem.

> Perforce is easy to use but it is not easy to maintain.  cvs and  
> svn scale far better (and darcs, arch, bk, git obviate the need to.)

I don't have any problems maintaining mine, but my repro is much  
smaller.