» Support » Knowledge Base » Conversions » CVS to Perforce » CVS2P4 Troubleshooting

CVS2P4 Troubleshooting

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.
  

  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.
  
  

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

  Solution

  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.
  

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

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

  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.
  
  

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

• 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/x
  y,v
  runtest> rm -f /var/tmp/cvs2p4/cvs2p4-3.0b6/test/badÿÔdab,v
  

  Solution

  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.
  

  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:

  P4PORT=public.perforce.com:1666
  //guest/richard_geiger/utils/cvs2p4/...

  Or in the fault-tolerant version in Marc Tooley's guest branch in:

  P4PORT=public.perforce.com:1666
  //guest/marc_tooley/util/cvs2p4/...

  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:

  locks
  		<username>:<version number>; strict;
  

  Solution

  Use 'rcs unlock' to unlock the file.