5 messages in com.perforce.perforce-user[p4] Moving Perforce installation to ...| From | Sent On | Attachments |
|---|---|---|
| Kimberly McClintock | 16 Aug 2001 09:56 | |
| Stephen Vance | 16 Aug 2001 10:38 | |
| Jeff A. Bowles | 16 Aug 2001 10:39 | |
| Jeff A. Bowles | 16 Aug 2001 14:09 | |
| Russell C. Jackson | 16 Aug 2001 18:05 |
| Subject: | [p4] Moving Perforce installation to a new machine |
|---|---|
| From: | Jeff A. Bowles (ja...@pobox.com) |
| Date: | 08/16/2001 10:39:50 AM |
| List: | com.perforce.perforce-user |
At 10:56 AM 8/16/2001 -0600, Kimberly McClintock wrote:
Wonder if anyone has experience moving an installation of Perforce from a server running NT to another server running NT?? Issues, problems? Concerns that arose? Hassle factor?
Do it twice. Once to test, once for real.
To test: * Start from a current checkpoint, which is a representation of all the db.* files. (You can start from a checkpoint plus the journal, but make it easy on yourself and just start from a made-this-morning checkpoint.) * So, make the checkpoint. Let's call it "checkpoint.22". * Copy the checkpoint and all the depot/* subtrees to the new machine in its new location. * Get a new license file from Perforce Tech Support, which might take a short while. * Uncompress the checkpoint ("p4d -r . -jr checkpoint.22" in the new machine, with the argument to '-r' being either "." for the current directory or the full pathname to the Perforce root.) * Start it up." * Run "p4 info" to make sure it's up, that it's connecting to the correct [new] server, that the license file is in place. * Run "p4 files //..." to see if it can talk to the database that's in the db.* files. Do the same for "p4 changes" and "p4 clients" and "p4 protect -o". There should be no errors. * Run "p4 describe" on several changelists. This will touch the depot/* trees also. There should be no errors. * Run "p4 verify //..." (or //depot/...) to have it read the contents of each revision of each file. Since your production environment is still running on the original machine, double-check each file that it complains about ("MISSING!") against the original server - this checks for missing revisions in the depot/* tree. Once you're satisfied with the test, remove the test data/area (keep that license file) and do it for real. You now know how long it will take, what hassles to expect, so that the for-real conversion should be boring.
And boring is what we like, when it comes to things like this.
I also have to upgrade my clients...should I do it all at the same time?
Your choice. No real need, you can always do that once the uncertainty of the server upgrade is finished.
-Jeff Bowles Perforce Consulting Partner
ps. That "p4 verify //..." is a good idea to do (with some flags to store the results in the database and compare new results against what's already been stored to find failing disk sectors) as a regular maintenance item.