I'm seeing some other strange artifacts:

• The directory specified in com.p4convert.cvs.tmpDir in the cfg file ends up with a copy of the CVS repo.
• The directory where I'm running 'java' ends up with a ",d" directory.

I also have a single CVS file (file,v) where the conversion fails. I could send it to you if you'd like.

The default depot name is called 'import' and should appear in a directory 'p4_root'.

com.p4convert.p4.depotPath (name of depot 'import')
com.p4convert.p4.root (output directory for jnl.0 and depot files)
com.p4convert.cvs.tmpDir (tmp location of processed RCS files)
com.p4convert.cvs.cvsroot (CVS source)

If you have further issues with the config please post your config file.

Please email me the RCS and I will try it out.

Attaching my config file. I've got each of those configured - not sure what's up.

Looks like it should end up in /tmp/p4depot_cvs_convert/depot/

The default should have been something like...
/projects/engcm_icm_scratch/CVS_CONVERSION/usb30phy/p4_root/import/

Not sure /tmp is a good location if there are tools that might clean it up.

Agreed. It should be going there but all I end up with in that directory is the 'jnl.0' file.

I changed '/tmp' to 'tmp' and re-ran - same issues: no 'depot' directory, ,d directory locally, and root of CVSROOT tree in 'tmp'.

Is there a way I can enable debugging to determine why it's not ending up populating the 'depot' directory?

A few things seem odd.
com.p4convert.core.schema=5.55 (should be more like 5.57)

Perhaps try and regenerate your config file:
java -jar p4convert.jar --type=CVS --default

One more thing do you have a path translation map set? (a local file called 'path.map')

Not sure if it is having an effect, but the p4.root should be terminated with a '/'.
com.p4convert.p4.root=/tmp/p4depot_cvs_convert

Where do you executing the jar? From /projects/engcm_icm_scratch/CVS_CONVERSION/usb30phy/?

I corrected the schema - I had switched to an older version of the utility to see if it was something in this version.

My current directory is /projects/engcm_icm_scratch/CVS_CONVERSION/usb30phy/p4client. I run the jar using this command:

[icmanage@engcm-irva-07:/projects/engcm_icm_scratch/CVS_CONVERSION/usb30phy/p4client] $ java -jar /projects/engcm_icm_scratch/CVS_CONVERSION/p4convert/PUBLIC.Main.12441/p4convert.jar -c usb30_phy_convert.cfg

I do have the following path.map file in my current directory when running the conversion.

[icmanage@engcm-irva-07:/projects/engcm_icm_scratch/CVS_CONVERSION/usb30phy/p4client] $ cat path.map
branch_1.1.1/.usb30_phy/([^/])/(.), //depot/icm/proj/USB30phy/main/rtl/{1}/{2}
branch_1.1.1/.usb30_phy/(.), //depot/icm/proj/USB30phy/main/rtl/{1}
([^/])/.usb30_phy/([^/])/(.), //depot/icm/proj/USB30phy/{1}/rtl/{2}/{3}
([^/])/.usb30_phy/(.), //depot/icm/proj/USB30phy/{1}/rtl/{2}

Should the ",d" and "tmp" directories be left around? Am I running the 'jar' in an unconventional manner that might be causing this issue?

Reproduced it, now I get a ',d' directory.

If the left hand side of the path.map has no match then you get the ',d' directory. The left hand CVS side is a relative path and does not start with a '/'. How about...

branch_1.1.1/.usb30_phy/([^/])/(.), //depot/icm/proj/USB30phy/main/rtl/{1}/{2}
branch_1.1.1/.usb30_phy/(.), //depot/icm/proj/USB30phy/main/rtl/{1}
(.)/.usb30_phy/([^/])/(.), //depot/icm/proj/USB30phy/{1}/rtl/{2}/{3}
(.)/.usb30_phy/(.), //depot/icm/proj/USB30phy/{1}/rtl/{2}

and add a catch all to the end...

(.*), //depot/other/{1}

Paul - thanks for your patience! It turns out the structure of the CVS directory had changed and I missed it. Once I artificially added back in the missing directory level the utility worked again.

Thanks for walking me through debugging this. Keeping the "catch-all" at the end is a good idea. Definitely should recommend that in the documentation.

I will be investigating the strange CVS file and will let you know how CVS handles it. Perhaps your parser can eventually be adjusted.

It was an UNDOC feature as there might have been side effects with labels and it had not been tested in production. If your experience has generally been good perhaps it is time to document it.

It's working great for me! Definitely should be kept as a supported feature.