Perforce Public Knowledge Base - p4d -xx and remote depots
Reset Search
 

 

Article

p4d -xx and remote depots

« Go Back

Information

 
Problem
Metadata relating to files in a remote depot only exists in that remote depot, but there can be links between these remote files and the local ones.
How does 'p4d -xx' check the remote information?
Solution
The '-xx' does not try to access the remote depot, as it is only doing a check on the local database tables.
'-xx' uses the remote depot's spec definition in the local database, allowing it to identify those remote files and stopping the need to check 'remote' data.

Amongst other things, '-xx' compares the table db.integed with db.rev. For files integrated between local locations only, there will be both db.integed records and db.rev records; there can be no integration records for file revisions that don't exist, and '-xx' will endeavour to rectify this for you (note).

If the integration records relate to files in your remote depot, there will be no local 'db.rev' records. The '-xx' process checks the depot spec that relates to the files involved; if the depot is identified as a remote depot, the '-xx' simply doesn't look for local revision metadata, leaving these 'db.integed' records intact. In this situation, the Perforce Server where the remote depot is located doesn't even need to be accessible.

However, if you have integrated from the remote depot to the local one, and later deleted the remote depot, the '-xx' has no reference information for that depot - it doesn't know that the files come from a remote depot. Now, '-xx' tries to find the db.rev records in the local database. There are none, so you get warnings when running '-xx' and the jnl.fix file attempts to remove the db.integed records:
 
$ p4d -r `pwd` -q -xx
Perforce server error:
    db.integed/db.rev inconsistencies found.
Perforce server error:
    db.integed/db.rev inconsistencies found.

$ cat jnl.fix
@nx@ 2 1418404019 @38@ 1 3 0 0 0 @/p4/root@ @jnl.fix@ @@ @@ @@
@dv@ 0 @db.integed@ @//depot/alpha@ @//remote/alpha@ 0 1 0 1 2 7434
@dv@ 0 @db.integed@ @//remote/alpha@ @//depot/alpha@ 0 1 0 1 3 7434

This is expected behaviour for the '-xx' command: it will try to remove data that, as far as can be determined, shouldn't be there.
If you want this connection between the files in remote and local depots to remain, recreate the remote depot spec. If the details are not known, check your spec depot (//spec/depot/...).
If not, don't replay the jnl.fix file, or remove these entries from the jnl.fix file before replaying it.
Finally, consider obliterating the 'local' file revisions and re-running the '-xx'; this is a fairly heavy-handed solution, as it will remove file data.


(note) -xx checks the db.integed/db.rev pair twice, as explained here:
p4d "-xx" checks db.integed/db.rev twice.
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255