Could be a change like that - hard to tell.

I would suggest recognizing it and raising a warning. A stop may be appropriate since without that file the import really is just a partial one.

Here's what I found: A couple ",v" files show up in both the ATTIC as well as the repository. Based on my understanding this is not a valid situation. They should be in one or the other - not both, correct?

I think this is the source of the problem I'm seeing.

Let me know if you want to pursue this.

Unfortunately the developer doesn't know what he did to cause this.

You make a good point in the implications of ignoring this version. Perhaps best is to flag it and stop the conversion until it's corrected.

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.

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}

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

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

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.

Ah - I see you were handling this for initial branches but not sub-branches. That's why my test case didn't exhibit the problem but the "real" data did.

Thanks for finding and fixing this.

Unfortunately, no. I tried to recreate it but couldn't get the exact behavior. Here are the steps I tried:

mkdir /tmp/cvsroot
export CVSROOT=/tmp/cvsroot
mkdir /tmp/cvstest
cd /tmp/cvstest
cvs init
cvs checkout
cvs tag TMPLABEL
cvs tag -r TMPLABEL -b newbranch
cvs update -r newbranch
echo just testing > trouble.c
cvs add trouble.c
cvs ci -r newbranch trouble.c
cvs log trouble.c

Why wouldn't 1.12.2.2 also be BRANCH since the branch wouldn't have existed before that? Perhaps this is just semantics and the effect would be the same.

Email sent with an example file. As I wrote initially, I think the CVS version should simply be ignored and shouldn't be reflected in the Perforce history.