Re: cvs2svn conversion directly to git ready for experimentation

[Steffen Prohaska <prohaska@zib.de>]

[-- Attachment #1: Type: text/plain, Size: 4365 bytes --]

Michael,

On Aug 1, 2007, at 2:09 AM, Michael Haggerty wrote:

> I am looking forward to your feedback.  Even better would be if  
> somebody
> wants to join forces on this project.  I would be happy to supply the
> cvs2svn knowledge if you can bring the git experience.

I tried it with revision trunk@3930 of cvs2svn. The results are as  
follows.

some WARNING: problem encoding log message: [...]

cvs2svn Statistics:
------------------
Total CVS Files:              9578
Total CVS Revisions:         66771
Total CVS Branches:         229121
Total CVS Tags:             371259
Total Unique Tags:             112
Total Unique Branches:          79
CVS Repos Size in KB:       210390
Total SVN Commits:           18178
First Revision Date:    Fri Jul 23 10:26:11 1999
Last Revision Date:     Thu Jul 19 17:50:40 2007
------------------
Timings (seconds):
------------------
3295   pass1    CollectRevsPass
    0   pass2    CollateSymbolsPass
3642   pass3    FilterSymbolsPass
    0   pass4    SortRevisionSummaryPass
    1   pass5    SortSymbolSummaryPass
  109   pass6    InitializeChangesetsPass
   56   pass7    BreakRevisionChangesetCyclesPass
   66   pass8    RevisionTopologicalSortPass
   54   pass9    BreakSymbolChangesetCyclesPass
   99   pass10   BreakAllChangesetCyclesPass
   92   pass11   TopologicalSortPass
   46   pass12   CreateRevsPass
    7   pass13   SortSymbolsPass
    2   pass14   IndexSymbolsPass
   70   pass15   OutputPass
7540   total


I checked that CVS head and two other branches match when checked
out from CVS and from the imported git archive. Everything is ok
(ignoring some differences introduced by keyword expansion).
Note, I tried earlier to use cvs2svn to import to svn followed by
git-svnimport to import to git. The repository resulting from
this two step import not even passed this minimal requirement of
matching checkouts from cvs and git.

cvs2svn created a lot of branches that are not present in CVS,
with names identical to CVS tags. Apparently these branches are
used to create a commit matching a certain CVS tag.

I checked one suspicious commit that indicates to me if the root
points of branches are right. Note, git-cvsimport fails this check;
parsecvs and cvs2svn pass the check.

The branching structure looks, ... hmm ..., interesting. cvs2svn
manufactured commits to get the branching points right.
Apparently our CVS has some weired commits like 'unlabeled-1.1.1'
and two other named tags (maybe vendor branches?) that cause
these manufactured commits. In gitk I see long lines running
parallel to the cvs trunk all down to these weired CVS tags. They
are not very useful, altough they might be correct. Note,
parsecvs imports our repository without such basically useless
links.  However, I can't verify if parsecvs gets something wrong.
Other branches are created over a couple of commits mixing in
several branches (maybe again our weired commits already
mentioned). See branching1.png, branching2.png, branching3.png.
[ I have to apologize, our cvs repository contains proprietary
   information, so I can't publish it's history freely. ]

cvs2svn is the first tool besided parsecvs that worked for me,
that is imported the whole repository, passed the basic test of
matching checkouts from cvs and git, and got the one suspicious
commit right that I'm using for verifying the branching points.

[ I have no time to go into the details of all these tests.
   Therefore only a very short summary:
   All tools needed basic cleanup of a few corrupted ,v files and
      ,v files that were duplicated in Attic.
   git-cvsimport fails to create branches at the right commit.
   fromcvs's togit surrendered during the import.
   fromcvs's tohg accepted more of the history, but finally
     surrendered as well.
   parsecvs works for me (crashes on corrupted ,v files).
   cvs2svn followed by git-svnimport create wrong state at the
     tips of branches.
   cvs2svn direct git import works for me (reports corrupted ,v files).
   ]

Right now, I'd prefer the import by parsecvs because of the
simpler history. However, I don't know if I loose history
information by doing so. I'd start by a run of cvs2svn to validate
the overall structure of the CVS repository. Dealing with corruption
in the CVS repository seems to be superior in cvs2svn. It reports
errors when parsecvs just crashes.


	Steffen



[-- Attachment #2.1: branching1.png --]
[-- Type: application/applefile, Size: 74 bytes --]

[-- Attachment #2.2: branching1.png --]
[-- Type: image/png, Size: 3389 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]



[-- Attachment #4.1: branching2.png --]
[-- Type: application/applefile, Size: 74 bytes --]

[-- Attachment #4.2: branching2.png --]
[-- Type: image/png, Size: 1653 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1 bytes --]



[-- Attachment #6.1: branching3.png --]
[-- Type: application/applefile, Size: 74 bytes --]

[-- Attachment #6.2: branching3.png --]
[-- Type: image/png, Size: 2807 bytes --]

[-- Attachment #7: Type: text/plain, Size: 4 bytes --]