[p4] Recovery of Dropbox Perforce Repository

WetSavannaAnimal perforce-user-forum at forums.perforce.com
Wed Mar 1 16:35:01 PST 2017


Posted on behalf of forum user 'WetSavannaAnimal'.

Dear Sambwise

This is all making a great deal more sense now. My original server was not in
Dropbox (as you rightly point out, I was confusing mappings with P4ROOT), only
the versioned files were and my checkpoints were defective - somehow I must have
been checkpointing the wrong directory.

Not to worry: I have what I need software wise, and I've only been
administering my own Perforce for a few months. But it would be great to have
confidence that I know what I doing if this happens again. So here are my
findings: I'd appreciate if you would confirm that I have my understanding
right.

I have now created a new Perforce server - as you say, there doesn't seem to
be an equivalent to "p4 set -S Perforce
P4ROOT=C:\Users\me\Dropbox\p4root" in P4Admin (I have never really learnt
the Perforce line commands until now, which seems to be the way "real"
Perforce people do things). This is in "C:\Program
Files\Perforce\Server", confirmed with the "p4 info" command.

I have the versioned files in my Dropbox, which I have set with a MAPPING in
P4Admin. The depot is called "HypatiaSimulator" and the command
"p4 depot -o HypatiaSimulator" shows that the HypatiaSimulator depot
is mapped to "C:/Users/RodVance/Dropbox/SoftwareRepository/.."

This morning I took a checkpoint of the new repository from the running server
after I had checked in all my files again with "p4d -jc" and the
checkpoint file looked totally different from what I had ever seen. This tells
me I was somehow screwing up in the checkpointing process: the new checkpoint is
much longer and contains very sensible text information that seems to describe
the depot mapping (where the versioned files are), workspace information and the
adding of and checking in of files to the repository (see the end of my post).

So now I would like to know how I would go about restoring. From all of this
research, armed with the backed up checkpoint and the versioned files in my
dropbox, I would do the following to recover from a disk crash:

1. Install Helix server and P4V
2. Go to P4ROOT and put the latest backed up checkpoint there
3. On a command line run "p4 admin stop"
4. Delete all the server's "db.*",  "*.lbr"
files and "server.locks" from a command line
5. Unpack the checkpoint with "p4d -r <checkpoint>" to create
the new database
6. Restart Windows so that the Perforce server is again running in its root with
the new files.

If I understand correctly, the Perforce server will now know about all of the
versioned files (as long as they continue to live in the same place in my
Dropbox) AND the workspaces because all that information was in the checkpoint
and now presumably in the newly rebuilt database.

Is that all correct? Many thanks for your thoughts.

One last question: It would seem sensible to keep the server off the Dropbox and
store checkpoints instead, no? I say this because Dropbox "fights"
some applications as they try to lock files for various things because, of
course, Dropbox needs to lock and ensure its transactions are atomic too (I find
I can't digitally sign documents from MS-Word when they are on Dropbox for
this reason). So there would be a significant risk of a fight between the
Perforce server and Dropbox, which are trying to do the same things in their own
ways to the server files. In any case, if I want to use P4Admin, then I
can't store the server on the Dropbox anyway.

____________________________________________________

Notes On The Checkpoint

In particular, I can see in the checkpoint text a line that would seem to record
the mapping:

"@pv@ 1 @db.depot@ @HypatiaSimulator@ 0 @@
@C:/Users/RodVance/Dropbox/SoftwareRepository/...@"

and then I see thousands of lines that seem very sensible and seem to be
recording the assignment of Workspace (which I called
"HypatiaMaser")  files to checksums, version info and then
confirmation that they are received, such as

"@pv@ 3 @db.have@
@//HypatiaMaster/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@
@//HypatiaSimulator/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@ 1 0
1463727147"

(here HypatiaMaster is a workspace I have created for myself in P4V) presumably
showing that the files in my workspace have been added to the repository and
then thousands of corresponding lines like:

"@pv@ 9 @db.rev@
@//HypatiaSimulator/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@ 1 0 0 1
1488374325 1463727147 2DC57DE99F2092B6CECEF38C7A59C7DF 20130 0 0
@//HypatiaSimulator/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@ @1.1@
0"

presumably assigning a checksum and version to each file and then

"@pv@ 0 @db.revcx@ 1
@//HypatiaSimulator/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@ 1
0"

@pv@ 9 @db.revhx@
@//HypatiaSimulator/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@ 1 0 0 1
1488374325 1463727147 2DC57DE99F2092B6CECEF38C7A59C7DF 20130 0 0
@//HypatiaSimulator/Hypatia/SimulationEngine/HypatiaMath/Quaternion.hpp@ @1.1@
0"

persumably confirming the checking in to the repository.



--
Please click here to see the post in its original format:
  http://forums.perforce.com/index.php?/topic/5199-recovery-of-dropbox-perforce-repository


More information about the perforce-user mailing list