[p4] 'Promoting' a Perforce proxy to server...

Robert Cowham robert at vaccaperna.co.uk
Sun Mar 13 02:13:43 PST 2005


> The given situation is as follows: We have a medium sized 
> Perforce repository that is ~10GB + metadata. I've set up 
> some proxies at remote locations. What is the most "bandwidth 
> efficient" method of converting one of the proxies to a 
> "real", standalone repository? The proxies are effectively 
> mirrors of the "master" repository that have been created by 
> a sync on the depot root, so all file data is still there...

Are you sure? Have you done a sync on every revision of every file? See
below.

> Background is the possibility to create a separated line of 
> code that keeps the revision history without "cluttering" the 
> existing depot and to possibly split the depot across several 
> machines...
> 
> These are just (sketchy) thoughts at the moment, but I'd like 
> to be prepared for a possible "moment of truth" ;-)

In any case, the mechanism is the same in principle:

In your main server you have depots A, B, C (same principles apply for
subsets of one depot), and let us assume you want to split into 2 servers,
one with A and one with B & C.

- create checkpoint for main server
- copy checkpoint and all file archive data to new location (you can do this
locally if you like)
- restore from checkpoint to new server
- obliterate the stuff you don't want (i.e. B&C)
- now checkpoint again and copy the new checkpoint and archive files for A
to new server machine and restore
- obliterate the stuff you have moved in original server (A)

You could perhaps use the proxy archive data to populate a remote server,
but the chances of missing stuff are quite high and it is probably easier
just to zip up and copy the main stuff. That said, you can check if anything
is wrong by doing a "p4 verify -q //..." - which is good to do at various
points during the above for safety....

Robert




More information about the perforce-user mailing list