Recovering A Deleted Workspace

How can I restore deleted client workspace information?

PROBLEM 

To restore a deleted workspace, you typically need to:

1. Restore the clientspec (workspace) with its associated View mapping.
2. Restore the workspace "have" list (using p4 sync, or restoring journal records).
3. Re-open files for add/edit/delete/integrate (as needed).

SOLUTION

1. Restoring the Workspace View

You can restore the client specification of a workspace by either:

• Using a saved text copy of the workspace.
• Restoring a saved copy from a "spec"-type depot
• Restoring metadata from a checkpoint or journal.

If you saved the contents of your workspace to a file, then you could restore the "myclient" workspace by reading the saved clientspec from that saved file. For example:

p4 client -o myclient > myclient.txt

saves the client specification to the file "myclient.txt", while:

p4 client -i < myclient.txt

reads the contents of "myclient.txt" and creates a new client worskspace, or updates an existing one.

If you have a Perforce depot of type "spec", then edits to client workspaces (and all other Perforce forms) will be automatically version controlled. In this case, you can use "p4 print -q" to output a versioned workspace specification and then pipe it to "p4 client -i". For example:

p4 files //spec/client/...
//spec/client/myclient.p4s#2 - delete default change (ctext)

p4 print -q //spec/client/myclient.p4s#1 | p4 client -i
Client local saved.

If you don't have a saved copy of your workspace in a text file or in a spec depot, then you will have to recover the associated records from an old checkpoint or journal.

Note: In general, if you need to restore records from checkpoints and journals, you should contact Perforce Support.

For example, these steps would recover the workspace "test-local" from the last checkpoint created, "checkpoint.86" on a typical Unix based system. Using the "tee" utility we can write the results to a file and monitor them on standard output:

cd $P4ROOT

grep db.domain checkpoint.86 | grep @test-local@ | tee test-local.txt

@pv@ 3 @db.domain@ @test-local@ 99 @bliss@ @/home/michael/p4work/TEST/local@ @@ @@ @michael@ 1089308159 1110422676 0 1 @Created by michael.

Since the workspace Description can be a multi-line field, you need to append the "@" record delimiter on a separate line if the previous line does not end with one:

echo @ >> test-local.txt

Next, you must extract the view mappings from the checkpoint using the same technique:

grep db.view checkpoint.86 | grep //test-local | tee -a test-local.txt
@pv@ 1 @db.view@ @test-local@ 0 0 @//test-local/...@ @//depot/...@ 

The end result will look something like the following:

cat test-local.txt 
@pv@ 3 @db.domain@ @test-local@ 99 @bliss@ @/home/michael/p4work/TEST/local@ @@ @@ @michael@ 1089308159 1110422676 0 1 @Created by michael.
@
@pv@ 1 @db.view@ @test-local@ 0 0 @//test-local/...@ @//depot/...@ 

After consulting with Perforce support, you would play this journal back into your Perforce server like this:

p4d -r p4root -jr test-local.txt

2. Restoring the Workspace "have" List

The "have" list consists of files the Perforce server tracks as being present on your workspace. The "have" list is synonymous with the "sync state" of your workspace. Restoring your workspace "have" list entails either just re-syncing your workspace, or recovering records from checkpoint and journals.

The quick and easy method to restore your workspace "have" list is to run the p4 sync command. For example:

p4 sync -f

The sync command will re-populate your workspace with files and update the workspace "have" list (tracked on the server in the db.have file).

Otherwise, if you want to restore the "have" list to a specific time, getting this revision list will require recovering records from either a checkpoint or a journal. For example:

grep @db.have@ checkpoint.123 | grep //clientname > workspace.have

to gather the relevant db.have records. Then, you could read the "workspace.have" journal records into the server, as with the db.view records above. Again, performing a p4 sync is generally much safer and quicker.

3. Restoring the Workspace File "check-out" State

As with restoring the workspace View and the workspace "have" list, it is possible to recover file check-out information for a given workspace. However, the process for finding opened file records is somewhat difficult, particularly if there were pending integrations or resolve operations. In general, it is often much safer to manually re-open files for add, edit, delete or integrate. 

Restoring the current workspace check-out state is analogous to reconciling your workspace after working "offline". Steps to automate this process are discussed in KB article #2.

Note: Checkpoint records only have "put" records (@pv@). Journal files have both "put", "update" (@rv@), and "delete" records (@dv@). Extracting metdata records from journal records is more complicated than extracting records from a checkpoint. If you are interested in retrieving information from journal records, please contact Perforce Support.

About This Page

Info & Tags Article #: 803 Created: 07/17/07 Modified: 05/26/08

Links Spec Depots Working Disconnected