Perforce Public Knowledge Base - CVS2P4 Troubleshooting and Special Considerations
Downloads Blog Company Integrations Careers Contact Try Free
Menu Search
Reset Search



CVS2P4 Troubleshooting and Special Considerations

« Go Back


WARNING: This article refers to a deprecated CVS conversion utility cvs2p4

This article is being preserved for historical purposes.

Common Problems and Solutions for CVS Conversions

  • $P4_DEPOT and $DEPOT

In the config file, it is important that the depot name used for the $P4_DEPOT variable be identical (including matching case) to the depot name used in the $DEPOT environment variable. If the two variable values differ, a depot will be created with one name but all the metadata records will reference the other. If the values differ by only case then case-sensitive Perforce servers will use the wrong path.


If the Perforce depot name is incorrect, then the fix is easy: simply add a depot with the correct depot name using the p4 depot command. However, if the metadata is incorrect, the fix will require a journal patch from Perforce Support to change all the incorrect file paths to the preferred naming convention. To save time and effort, use matching values for these two variables to begin with.If the Perforce depot name is incorrect, then the fix is easy: simply add a depot with the correct depot name using the p4 depot command. However, if the metadata is incorrect, the fix will require a journal patch from Perforce Support to change all the incorrect file paths to the preferred naming convention. To save time and effort, use matching values for these two variables to begin with.
  • p4 snap and Obliterating CVS2P4 Converted Data

    Even though Perforce is capable of reading extended RCS numerical branches used by CVS, it is not capable of rewriting them. During a p4 obliterate operation, Perforce archive files might be rebuilt. As a result, the process of removing data during an obliterate or snap could corrupt Perforce archive files that originally came from CVS.


    The fix for CVS archive files damaged by a p4 obliterate is to manually restore the original CVS archive files to the IMPORT location. To prevent damage to these files, make the imported CVS archive files immutable and read-only to the Perforce Server.
  • Perforce Proxy Fails With CVS2P4 Data

    The Perforce librarian code (which handles reading and writing RCS-format archive files) does not perfectly handle extended RCS branch information that is embedded in RCS files generated by other SCM systems such as CVS. Since the Perforce Server and the Perforce Proxy share RCS handling code, this problem manifests itself when the Proxy tries to cache CVS2P4 converted data. Perforce is able to read the deep revision numbers but is not able to write them, which prevents the Perforce Proxy from writing these files to its cache.


    If the Perforce Proxy is pre-populated with archive files converted with CVS2P4, there is no need to write extended RCS information and the above problem does not occur. Note that the Proxy archive can be pre-populated at any time. Pre-populating the Proxy cache is the only solution, and the additional Proxy flag -k must be used forever.
  • Broken RCS Files from CVS

    CVS repositories, particularly old or large CVS repositories, often have corrupted archive files. For example, some repositories might have:
    • Files in the CVS Attic and also outside of it
    • Headers that reference non-existent body revisions
    • Non-standard or even illegal RCS keywords
    • Multiple revisions in the body for the same RCS header revision
    • Author tokens with spaces in them
    All of these problems can generate errors, either during processing by the converter, or in subsequent processing by the Perforce server.


    One solution for corrupt CVS archives is to simply remove them prior to running the converter. Otherwise, for corruption that was only detected after the conversion, you can use the p4 verify command to identify potentially corrupted source revisions. Such revisions often show up as numerous "MISSING!" entries in the results of a p4 verify, due to CVS2P4's extensive use of lazy copies for converted CVS branches. Each "MISSING!" needs to be double-checked to see if this is the cause and ignored if so. Contact Perforce Technical Support for more information.
  • Additional RCS Tokens from CVSNT

    Some CVS versions have developed their own extensions to CVS which include rudimentary merge tracking, commit identifiers, and so on. A list of these tokens includes but is not limited to:
    • mergepoint1
    • deltatype
    • permissions
    • commitid
    • kopt
    • filename
    • comment
    These are non-standard tokens and both the Perforce Server and the CVS2P4 scripts will have problems parsing them. Some of them are even illegal by the strict RCS standard.


    All non-standard or special tokens must be manually removed from the RCS files prior to conversion and especially prior to use in a Perforce server. There are currently no support-supplied scripts to assist in pruning the RCS files in this manner.
  • Conversion Failures Regarding Permissions

    On occasion there are those machines that have just the right combination of permissions and user rights that prevent the CVS2P4 converter from running correctly. Symptoms look like this:
    rm: Unable to remove directory /usr/local/perforce/data/depot: File exists
    rm: Unable to remove directory /usr/local/perforce/data: File exists


    Run the converter as root via su or sudo.
  • Corrupt Journal Produced

    During the conversion process, if you attempt to import one of the converted journals, you might see errors such as:
    Perforce server error:
    Journal file 'dbmeta' replay failed at line 8!
    Word too big for a number!
    When running the test script, you might also encounter errors of the following form:
    runtest> diff /var/tmp/cvs2p4/cvs2p4-3.0b6/test/lines.good
    < shemp
    runtest: *** "diff /var/tmp/cvs2p4/cvs2p4-3.0b6/test/lines.good /var/tmp/cvs2p4/cvs2p4-3.0b6/test_conv_dir/lines" exited with signal 0 status 1
    runtest: *** genmetadata bad results
    runtest> rm -f /var/tmp/cvs2p4/cvs2p4-3.0b6/test/,v
    runtest> rm -f /var/tmp/cvs2p4/cvs2p4-3.0b6/test/xy,v
    runtest> rm -f /var/tmp/cvs2p4/cvs2p4-3.0b6/test/bad��dab,v


    The above errors suggest that a non-standard character set is being used, which will cause Perl to treat strings somewhat differently, resulting in broken RCS file parsing. Check the value of the LANG variable:
    echo $LANG
    If the $LANG variable is set, make sure that it is set to a standard character set. For example, in the United States, the $LANG variable should either be unset or set to "en_US". Any $LANG value that ends in .utf8 indicates a unicode character set and this may cause problems.
    In the worst case, if all the above fails, set your LANG to C like so:
    locale C
    export LC_ALL=C
    export LANG=C
    This effectively means "do not translate" and should be the final solution to this problem. If the issue persists, the source is much less likely to be a locale problem.
  • NOTE: If your error persists, one of the more likely culprits is that your rlog binary is not, after all, patched. Please try rebuilding your rlog binary and making sure it sits in cvs2p4/bin/rlog.

    Solution #2

    The dbmeta error also happens sometimes because older versions of CVS2P4 scripts used to try to parse the RCS files directly. However, sometimes broken RCS files (such as those created with CVSNT) would make this tricky. Newer versions of the script use RCS' own rlog command to help parse the RCS files and will usually overcome these sorts of problems in the source data.

    Therefore, the answer is to talk to support and have them help you use the absolute latest versions of the converter available, which are either in the original author's own CVS2P4 branch in the public depot in:
    Or in the fault-tolerant version in Marc Tooley's guest branch in:
    Note that these two branches, while they contain the latest bugfixes, do require some compilation to run, and therefore exists the need for support's assistance when using either one of them.
  • Locked Files in CVS

    CVS files can be locked by users, which prevents them from being imported cleanly. If a file fails to import, look for a line like this in the RCS file:

    		<username>:<version number>; strict;


    Use 'rcs unlock' to unlock the file.
  • Text files converted to Binary+D

    Occasionally text files that contain CRLF line endings will be converted to binary+D rather than type text.


    The dochanges Perl script is looking for '[ob]' and it is likely that the files being converted to binary+D have 'o' in their keyword expansion.  Normal text files should have "kv" rather than o.  One way to resolve this is to run:
    cvs admin -kkv filename
    This will set the correct format for the file and the conversion can be run again.

    The second option is to retype the file to type text after the conversion, by using the p4 retype command:
    p4 retype -t text //depot/file/name
Related Links



Was this article helpful?



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

Characters Remaining: 255