[p4] Server Migration and Client Files - Sheryl McKeown - com.perforce.perforce-user

2 messages in com.perforce.perforce-user[p4] Server Migration and Client Files

From	Sent On	Attachments
Sheryl McKeown	24 Apr 2001 11:58
Chuck Karish	24 Apr 2001 13:33

Subject:	[p4] Server Migration and Client Files
From:	Sheryl McKeown (ibou...@yahoo.com)
Date:	04/24/2001 11:58:05 AM
List:	com.perforce.perforce-user

Ok, I'll give these procedures a try during my practice migration.

Couple other questions:

1. When p4 verify is running should developers be allowed access to the depot for changes etc. 2. For test purposes, can I tar the depot wihout limiting developer access? (I need to get some bench marks.)

Thanks, Sheryl

--- "J. A. Bowles" <jab at piccoloeng.com> wrote:

I think you might be a bit too cautious, creating a bit more work than you need.

You bring up good questions: 1. you haven't run "p4 verify //..." ever; 2. you haven't ever restored from a checkpoint.

On a strictly technical level, you can just checkpoint the database, move everything to the new machine, restore from the checkpoint, and continue work - telling your users to set P4PORT to the new machine. (If you're lazy, you could just use the same IP address and machine name for the new machine. You will need a new license file from Perforce if you have a new machine name or IP address for the server - depending on the type of license file - so check with the support folks.)

But you can eliminate the uncertainty prior to the move, easily: 1. "p4 verify" is CPU-intensive, so running it will take some time. Start running it before going home for the weekend, and let it update ("verify -u", if memory serves) the database to store the computed checksums in the metadata for later use. 2. And sometime soon, just make a checkpoint and restore from it. Do both of these prior to the move, and you'll have a fairly boring move to the new machine.

Ask Perforce Tech Support about the new license file for the new machine fairly soon, however.

-Jeff Bowles

ps. An unspoken thing herein: when you're moving to a new machine, even an identical Unix machine, it's probably best to move the metadata in a checkpoint form and restore on the destination end. That guarantees, among other things, that you have a recent checkpoint sitting around in case of a problem/mistake.

At 01:01 PM 4/20/2001 -0700, you wrote:

Hello,

We are approaching our 2GB limit on our current Sun box. Therefore, we are preparing to migrate our Perforce installation from the older server running SunOS 5.5.1 to a brand spanking new Sun box running SunOS 5.8.

We have approximately 250 developers working on 3-5 codelines, each codeline has a few branches.

I would like all developers to check-in their code before the migration and re-sync afterwards. I am planning to 'revert' all open change lists before the move.

I'm doing this because our depot has never had p4 verify run against it nor is it ever rebuilt. Therefore, I want to avoid any possible data corruption when moving between OSs.

The issues is that there will be developers who 'cannot' check in their code as it is not ready to be built with the rest of the product. And this is ok. But what I need to determine is their exact procedure to 're-sync' to the database without losing their changes.

Branching is not an option and I don't want the developer to have to 'copy code to a safe place, re-sync, then copy the code back.'

I have the Perforce FAQ regarding "How do you work disconnected from the perforce server?" and this is most likely the procedure I will use.

So, has anyone used/scripted this procedure and what where the results. And, any input (experiences, watch-outs etc) you may have had on a migration project?

Thanks, Sheryl McKeown

perforce-user at perforce.com

http://maillist.perforce.com/mailman/listinfo/perforce-user