To identify the cause of the RCS parse errors, refer to the master Perforce server log file, paying specific attention to the same time-stamp as the replica error.
The master server log shows no errors, and records the expected replication actions (rmt-FileFetch or rmt-Journal commands issued by the "service" user).
To determine the cause of the error, run "p4 pull -l" manually on the replica server:
p4 pull -l
//sa/sa.file 1.524 text error add B74ED347390D35C29923E80F64C9D904 6 524 2012/05/16 11:14:37 2012/05/16 11:14:29 2712 2012/06/20 10:20:05 61 RCS parse error at line 1!
RCS expected desc!
This replicates the logged error and provides a filename. Use this to perform a "p4 verify" against the file archive on the replica:
p4 verify //sa/sa.file
//sa/sa.file#1 - add change 524 (text) B74ED347390D35C29923E80F64C9D904 MISSING!
The 'MISSING!' piece shows this file revision can't be retrieved from the archives. To confirm this isn't a problem with a missing archive on the master server, run the same command against the master server:
p4 verify //sa/sa.file
//sa/sa.file#1 - add change 524 (text) B74ED347390D35C29923E80F64C9D904
Notice that the file is not listed as MISSING, and the MD5 digest is the same value as the verify output on the replica. Examining the RCS file on the master server directly confirms the contents of the archive:
locks ;comment @@;
date 2012.05.16.11.14.37; author p4; state Exp;
This appears to be the correct file contents. Running the same command on the replica, however:
This is not a correctly formatted RCS file -- it's possible it was manually replaced or edited directly, or corrupted. Regardless of the cause, to correct the parse error remove or rename the replica archive file:
mv sa.file,v HIDE.sa.file,v
And then schedule the archive transfer from the master using "p4 verify -t":
p4 verify -t //sa/sa.file
//sa/sa.file#1 - add change 524 (text) B74ED347390D35C29923E80F64C9D904 MISSING! (Transfer scheduled)
The file is then transferred, and the replica archive matches the master archive. You can confirm this by running "p4 verify" against the file on the replica, verifying that no errors are displayed and the digest matches the master server archive.
Note: This is one specific example of an error; the various steps taken here helped identify the cause, but the actual findings may vary. If you have any questions about the issues you have encountered, contact Technical Support for further assistance.