Unable to process file: /projects/engcm_icm_scratch/CVS_CONVERSION/usb30phy/cvsrepo/rtl/usb30_phy_mdio.sv,v
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.perforce.cvs.parser.rcstypes.RcsObject.add(RcsObject.java:36)
at com.perforce.cvs.parser.RcsReader.parsePhrase(RcsReader.java:250)
at com.perforce.cvs.parser.RcsReader.parseRcsDeltas(RcsReader.java:193)
at com.perforce.cvs.parser.RcsReader.<init>(RcsReader.java:87)
at com.perforce.cvs.process.CvsProcessChange.buildBranchList(CvsProcessChange.java:199)
at com.perforce.cvs.process.CvsProcessChange.processChange(CvsProcessChange.java:67)
at com.perforce.common.process.ProcessChange.runSingle(ProcessChange.java:90)
at com.perforce.common.process.ProcessChange.call(ProcessChange.java:53)
at com.perforce.common.process.ProcessChange.call(ProcessChange.java:20)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:504)
at java.lang.Integer.parseInt(Integer.java:527)
at com.perforce.cvs.parser.rcstypes.RcsObjectNum.<init>(RcsObjectNum.java:17)
at com.perforce.cvs.parser.rcstypes.RcsObjectNumList.<init>(RcsObjectNumList.java:12)
... 17 more
I had been thinking of adding a pre-scan option to sanity check the RCS before conversion. Initially to look for high ascii characters in the path/filename and path depth (limitation on Windows Clients). I guess adding this makes sense too.
Failed file attached.
First glance at the file... is '1.5.2.2..1' valid CVS?
1.5.2.2..1
date 2015.02.15.01.14.59; author zluo; state Exp;
branches;
next ;
commitid pBg1G8EVuEgKE2ay;
You have a good point. ;-)
I'll investigate.
Feel free to close this....
I could make the converter more robust. I had thought about substituting the missing number for a 0.
Not sure how it happened? Was the RCS generated by another tool?
I'm really not sure. I'll need to ask the developers how that happened.
Would you be able to ignore the faulty revision but continue processing the file? That might be the best way to go about it.
It might be possible to ignore the revision, but that could end up ignoring all subsequent 1.5.2.2.. revisions and any branches.
Do you have any more information as to how the missing number occurred?
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.
I had been thinking of adding a pre-scan option to sanity check the RCS before conversion. Initially to look for high ascii characters in the path/filename and path depth (limitation on Windows Clients). I guess adding this makes sense too.
That would be a good idea - some sort of sanity check.