[p4] Perforce evaluation
rjackson at symantec.com
Wed Jul 19 19:30:38 PDT 2000
First, here is our environment:
Perforce server: Compaq 3000 Dual 600 Mhz processor system with 4 Gigs of
RAM running NT 4.0/SP6.
500,000+ files in server.
30+ Gigs of data files in the server.
Currently 429 users, but soon to be close to 500. (Waiting for new license
p4 verify's speed depends on whether or not you tell Perforce to maintain a
digest for each file. I won't be able to tell you the exact time until the
next time I run verify which will be automatically this Sat. night, but I
know it is very fast after the first time you tell it to compute the
Perforce checkpoint size: 2.1 Gigs. It takes about 30 minutes to complete
that checkpoint currently. If you don't have more memory than the size of
your Perforce db files, then the time to make this size checkpoint will be
in the hours instead of minutes.
Perforce database total size: Approx. 2.6 Gigs. The performance of the
server scales very well. The only things that really seem to be affected by
the database size is verify, obliterate and checkpoint. The less memory you
have, the longer each of those commands takes.
We have not had any serious problems with data loss. There was one time
where the obliterate command wasn't doing something correctly, and we lost
a couple of the first revisions on a branch, but that is it, and that
problem was corrected very quickly by Perforce.
There are a lot of things you can do in terms of queries on the data, but
often you have to parse some data, or combine a couple of different queries
to get exactly what you are looking for.
Perforce requires very little in terms of maintenance. Most of it can be
automated. It needs a decent amount of improvement in the security
department, but it can be made to do what you want, if you are willing to
manage the complexity that will grow in the protections file.
It is not too difficult to use for novice users as long as they are running
on Windows so that they can use the GUI. Most novice computer users don't
want anything to do with a command line. All of our graphics publishers and
tech writers use Perforce to store their files.
Perforce works extremely well with remote users. In fact that is one of the
reasons we selected Perforce for our version control system. The concept of
Perforce is that the developers keep their data files locally, and only
changes are sent back and forth to the server, and those changes can be
Please let me know if you have any other questions, I'll be happy to answer
Russell C. Jackson
Additional contact information:
909-212-0636 cell phone
rcjackson at alum.atu.edu - home email
"Grant Thorton" <mrxml at webave.com>@perforce.com on 07/17/2000 12:41:24 AM
Sent by: perforce-user-admin at perforce.com
To: perforce-user at perforce.com
cc: support at perforce.com
Subject: [p4] Perforce evaluation
During my evaluation of Perforce I have come up with some questions.
If anyone can supply me with actual numbers, I would be appreciative. I am
curious how long it takes to run p4 verify on a large system. How long
does it take to run checkpoint? Of course, these numbers are useless
without such data as how many files you have and how many users you have?
What is the total size of your db.* files? I read that the database
requires .5K per user per file. With 200+ users and ~300K files you get
200 * 300,000 * .5K of data. Perforce is _very_ fast in my tests with two
users and 1000 files, but does the performance scale well?
Has anyone had problems with data loss/corruption? Is the database used a
Perforce creation? Is there any way to run queries directly against the
How hard is the tool to administrate? How hard is it to train users on
Perforce? Are less technical users like graphics designers or
documentation writers able to use Perforce?
How well does Peforce work with remote users?
Any other good or bad things that I should consider?
Free email with personality! Over 200 domains!
perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user