[p4] How to best setup workspaces for a build park

[Melissa]

A 2.9G db.have is not a problem. Db.have will always be the largest file
on your Perforce server. If your server can not handle the 2.9G file,
I'd submit that your server and your needs are mismatched. Look into the
bottleneck on the server, and alleviate it. The bottleneck may be disk
speed, memory, or CPU.

However, if you really want to reduce the size of the db.have, first
simply delete all old unused and possibly abandoned clients. This
deletes entries in the db.have. Then you have to back up and restore
your database to do the shrinking. Then see if the size of the db.have
is satisfactory to you. Try this before changing your build system. One
workspace per branch per machine is a completely normal and correct
practice.



-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Rui Casais
Sent: Saturday, January 26, 2008 6:51 AM
To: perforce-user at perforce.com
Subject: [p4] How to best setup workspaces for a build park

Hi

Currently our database file for all the "have" revisions of our users is

2.9 gb. To try to reduce this and improve the performance of our P4 
server I have been thinking of how to reduce the number of workspaces 
that the buildpark we have has.

We have around 15-25 active code branches at any point in time and when 
a programmer submits a changelist one of the machines from the buildpark

will:
- Create a workspace for the branch where the submit happened, if there 
isn't one already
- Sync the workspace to the changelist number
- Compile

Now, this makes it so that we have many many workspaces, as we have 1 
workspace per branch per machine, and each workspace has its own set of 
"have" revisions.

How would you structure the workspaces across buildmachines to minimize 
this problem?

I can see only 2 solutions:
- Have 1 workspace per machine that covers all branches. Problem: The 
buildsystem needs to be changed, as handling 1 workspace per branch is 
easier and cleaner.
- Have 1 workspace per branch, shared by all machines. Problem: The 
machines will need to force sync to the desired changelist number 
everytime there's a new build to process

Thanks for your input!