CVS2P4 Troubleshooting

Info & Tags

Article #:
289
Created:
05/01/07
Modified:
02/27/08

Common Problems and Solutions for CVS Conversions

  1. $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.

    Solution

    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.

  2. "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 may 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.

    Solution

    The fix for CVS archive files damaged by an 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.

  3. 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.

    Solution

    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 will 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.

  4. Broken RCS Files from CVS

    CVS repositories, particularly old or large CVS repositories, often have corrupted archive files. For example, some repositories may 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.

    Solution

    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 will 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!" will need to be double-checked to see if this is the cause and ignored if so. Contact Perforce Technical Support for more information.

  5. Additional RCS Tokens from CVSNT/etc

    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.

    6. Solution

    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.

  6. 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

    Solution

    Run the converter as root via su or sudo.

  7. 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
/var/tmp/cvs2p4/cvs2p4-3.0b6/test_conv_dir/lines
    9d8
< 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

    Solution

    The above errors indicate that a non-standard character set is being used, which will cause Perl to treat strings somewhat differently, resulting in the aforementioned issues.  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 could cause problems.