0

I want to migrate CVS repositories into Gitlab. I have multiple modules under a repository and few modules have multiple jars in it. I used the cvs2git tool to migrate this, it's migrated without any issues but I couldn't compile the repository after migration because few jars getting corrupted. Why it's getting corrupted?

While compilation the builds are failing, I just checked the jars which was getting corrupted,

jar -tvf ./<path>/<myjar>.jar
java.util.zip.ZipException: invalid END header (bad central directory offset)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:219)
at java.util.zip.ZipFile.<init>(ZipFile.java:149)
at java.util.zip.ZipFile.<init>(ZipFile.java:120)
at sun.tools.jar.Main.list(Main.java:1115)
at sun.tools.jar.Main.run(Main.java:293)
at sun.tools.jar.Main.main(Main.java:1288)

My jars in CVS as well as in GIT after migration as follows,

GIT

[root@test myrepo]# ls -ltr ./<path>/isorelax-20030108.jar
-rwxr-xr-x 1 root root 192232 Sep 27 16:54 ./<path>/isorelax-20030108.jar
[root@test myrepo]# ls -ltr ./<path>/opt/isorelax-20030108.jar
-rw-r--r-- 1 root root 192232 Sep 27 16:54 ./<path>/opt/isorelax-20030108.jar

CVS

[root@test myrepo]# ls -ltr ./<path>/isorelax-20030108.jar
-rwxr-x--- 1 root root 192743 Jun 10  2015 ./<path>/isorelax-20030108.jar

[root@test myrepo]# ls -ltr ./<path>/opt/isorelax-20030108.jar    
-rw-r----- 1 root root 192602 Jun 30  2015 ./<path>/opt/isorelax-20030108.jar

We are accessing ./opt/isorelax-20030108.jar jar while compiling but getting failed in GIT but CVS builds successfully.

I ran the CVS status on the jars one is showing with -kb but another one is not. 

[root@test myrepo]# cvs status ./<path>/isorelax-20030108.jar

=============================================================
File: isorelax-20030108.jar     Status: Up-to-date

   Working revision:    1.2.1
   Repository revision: 1.2.1 /cvs/myrepo/<path>/isorelax-20030108.jar,v
   Sticky Tag:          TAG_1 (revision: 1.2.1)
   Sticky Date:         (none)
   Sticky Options:      (none)


[root@test myrepo]# cvs status ./<path>/opt/isorelax-20030108.jar

=================================================================
File: isorelax-20030108.jar     Status: Up-to-date

   Working revision:    1.2.3
   Repository revision: 1.2.3 /cvs/myrepo/<path>/opt/isorelax-20030108.jar,v
   Sticky Tag:          TAG_1 (revision: 1.2.3)
   Sticky Date:         (none)
   Sticky Options:      -kb

We are accessing the jars with Sticky Options: -kb, still it's failing...

What was the problem here? Kindly provide your thoughts on this.

SST
  • 2,054
  • 5
  • 35
  • 65
  • Are the jars marked with keyword=binary in the cvs repository? – Mort Oct 04 '19 at 02:02
  • How can I find the jars marked with keyword=binary in CVS repository? – SST Oct 04 '19 at 05:19
  • @Mort If I run the following command returns the following, "file myjar.jar" ------> myjar.jar: Zip archive data, at least v2.0 to extract – SST Oct 04 '19 at 05:44
  • @Mort Kindly confirm that they are pushed as binary, what is the problem here? – SST Oct 04 '19 at 06:14
  • 1
    In the CVS repo, if you type `cvs status myjar.jar` it should indicate that the file is binary with `Sticky Options: -kb`. If it is not, you probably need to set it in CVS and re-import to git. https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Binary-howto.html – Mort Oct 04 '19 at 12:34
  • Thank you @Mort. It's showing the cvs status of the jar. I will check and update you. – SST Oct 09 '19 at 05:54
  • @Mort The jars are present with Sticky Options: -kb. But still why am I getting corrupted jars during migration. Kindly provide your thoughts on this. – SST Oct 10 '19 at 13:07
  • I am out of ideas then. Sorry. I would try some binary comparisons of equivalent versions in `cvs` vs `git` and see what the byte-level differences are then use your programming and cvs and git experience to create a hypothesis from there. – Mort Oct 10 '19 at 13:23
  • @Mort I have updated the question with byte-level differences. Kindly check and provide your thoughts on this. – SST Oct 11 '19 at 10:15
  • `jar`s are essentially zip files, can you confirm that you can uncompress them with a regular decompression tool? If that is the case, it is unlikely a byte-to-byte difference. Based on the error you get, it looks like that some paths have changed during the conversion. can't you re-create your `jar`s from the sources in `git` instead of using the `cvs` ones? – norok2 Oct 11 '19 at 10:29
  • Thanks for your prompt reply @norok2! No, I can't re-create, I just need to migrate from CVS to GITLAB. – SST Oct 11 '19 at 10:38
  • @SST by byte-level differences I mean figure out which exact bytes in the files are different, not the sizes, the exact bytes. Look at them with your computer science mind on and figure out if you see a pattern (e.g. CR->CRLF, or anything else). – Mort Oct 16 '19 at 00:14
  • Ok. I will check and update you. – SST Oct 16 '19 at 06:16
  • @SST did you ever figure this out? – Mort Nov 11 '19 at 19:20
  • @Mort The Jar files are getting corrupted while migration I am not sure, what's happening while migration. :( – SST Nov 12 '19 at 05:53

0 Answers0