[p4] Splitting a depot
Prakash Ranade
pranade at vmware.com
Mon Dec 11 11:45:19 PST 2006
About 5 months ago we have split the giant perforce depot into 1. DEV only
server 2. QA+IT+misc server.
Here is the process we have used in splitting a depot at VMWare.
Little background...
We had one giant ~90 GB depot with around ~50 GB db.have records. Our
perforce server was functionally divided into 85% of DEV activity, 15% QA, IT
& misc code.
Steps...
1. Took a checkpoint and restored it on two separate servers with depot(*,v
files also duplicated on separate servers)
2. Using protection table we have established restrictions on accessing QA
depots on DEV and vice versa.
3. Using perforce super-user account, we have ran trimClient(home grown)
script which removes now obsolete clients from each servers.
4. Those perforce client which overlaps on both server has also trimmed for
those depots which maps now restricted to the source server.
5. Run complete checkpoint on both server and restored from the checkpoint
for db tree rebalancing.
6. Bumped up the change counter above million number on QA server to identify
different changes.
7. And weekend run of "p4 obliterate" of single QA depot from DEV
server(Remember "p4 obliterate" is expensive process and it can lock the
development if it run in the business hours)
Timeline...
This process took almost 4 weeks since we planned to have minimal disruption
to the engineering, and so executed it on the weekends.
Issues...
1. You need to advertise to your engineering almost 4 weeks ahead of the time
about such splits. Send enough emails, FAQs, How-To's guide to clarify the
intension and educate them about whom to contact. We have had emails flying
all around about depots restricted and my changes has not gone in and every
time we have to point them to the FAQs.
2. If you have CM controlled branch creation script then improve it with
split depots condition.
3. Your build process might get affected since now it has to sync from two
different P4PORT.
This process has helped us to reduce "db.have"(~35GB) size on primary server
and minimize the race for read/write locks for p4d by reducing user base.
Hope this email help your planning.
Regards,
Prakash Ranade
VMWare Inc.
-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Jamison, Shawn
Sent: Monday, December 11, 2006 8:41 AM
To: perforce-user at perforce.com
Subject: [p4] Splitting a depot
Howdy everyone. Hope you had a good weekend!
I have a server with close to 10 million files and the P4ROOT is just under
100 GB in size.
Fully half of what is there is not needed on a day to day basis and
checkpoints, backup and DR planning can be problematic and costly with that
much data.
Does anyone have any arguments for or against splitting a large depot?
What problems or issues did you experience?
How big was the depot?
How long did it take?
Thanks for your input!
-Shawn J>
Perforce Admin
Ciena Corp.
_______________________________________________
perforce-user mailing list - perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user
More information about the perforce-user
mailing list