git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0

Hello all,

Back in June I had done a test convert of our CVS repo using git 1.5.5.1 and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a week to finish!). Recently I wanted to try again with the latest versions of git and cvs2svn.

When I get to the final stage (running git fast-import to build the converted repo), I get the following output: cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git fast-import fatal: Unsupported command: '. fast-import: dumping crash report to .git/fast_import_crash_19097

The crash is 18MB and I'd rather not post it, but the only bits that
seem somewhat interesting are:
fast-import crash report:
    fast-import process: 19097
    parent process     : 19095
    at Mon Jan 19 11:44:42 2009

fatal: Unsupported command: '.

Most Recent Commands Before Crash
---------------------------------
(...)
  reset refs/tags/T_9772
  from :1000007127
  reset refs/heads/TAG.FIXUP
  
  commit refs/heads/TAG.FIXUP
  mark :1000007128
  committer cvs2svn <cvs2svn> 1002043747 +0000
  data 88
* '.

Has anyone got any ideas how to resolve this?

Thanks,

--

Kelly F. Hickel Senior Product Architect MQSoftware, Inc. 952-345-8677 Office 952-345-8721 Fax kfh@mqsoftware.com www.mqsoftware.com Certified IBM SOA Specialty Your Full Service Provider for IBM WebSphere Learn more at www.mqsoftware.com

That's a typo. The June conversion used git 1.5.5.1 and cvs2svn 2.1.1 (not 2.2.0 as previously stated).

Sorry for the confusion.

-Kelly

(Sorry for the mangled quotes)

and 

is 

end 

to 

I found the section in question, it is: -- snip -- commit refs/heads/TAG.FIXUP mark :1000007128 committer cvs2svn <cvs2svn> 1002043747 +0000 data 88 This commit was manufactured by cvs2svn to create tag 'T_BU_Problem_9xxx_Merge_3-21-2000'. merge :1000007126 M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h -- snap --

By my count, 88 is the ending single quote character, leaving the '.' to be interpreted as a command.

Looks like I should go post this on the cvs2svn list.....

Thanks!

-- Kelly F. Hickel Senior Product Architect MQSoftware, Inc. 952-345-8677 Office 952-345-8721 Fax kfh@mqsoftware.com www.mqsoftware.com Certified IBM SOA Specialty Your Full Service Provider for IBM WebSphere Learn more at www.mqsoftware.com

Hi,

On Thu, 22 Jan 2009, Kelly F. Hickel wrote:

Great!

Indeed. I think that Michael will find the culprit very soon, with this detailed report.

BTW for future reference, please Cc: the people you are responding to. The Git mailing list is a high volume list, and people will miss you answers otherwise.

Thanks, Dscho

Kelly F. Hickel wrote:

Yes, that would be helpful. Please include enough information and data to enable me to reproduce your problem, because it is very mysterious.

The lines in question are (in Python)

    self.f.write('data %d\n' % (len(log_msg),))
    self.f.write('%s\n' % (log_msg,))

where self.f is a file that was opened in binary mode, and log_msg is an 8-bit or unicode string. Since the log message is being output to a binary file, f.write() should squeal if the string includes any non-ascii characters (I just verified this with Python 2.2, 2.4, and 2.5). Nevertheless, I suspect that your problem is caused by some kind of character encoding problem, perhaps dependent on platform or Python version.

You might also try the trunk version of cvs2svn; there have been a lot of changes to cvs2git since release 2.1.1--even a new command that is actually called cvs2git! (though for now you still need to use an options file to start conversions).

Michael

------------------------------------------------------ http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=1044191

To unsubscribe from this discussion, e-mail: [users-unsubscribe@cvs2svn.tigris.org].

Hi,

On Tue, 20 Jan 2009, Kelly F. Hickel wrote:

That is strange. The command "data 88" should read the next 88 bytes and not stop at the line starting with '.

Just to test, I successfully imported this:

-- snip -- commit refs/heads/testing/test mark :1 committer cvs2svn <cvs2svn> 1002043747 +0000 data 3 '.

-- snap --

So I guess the problem lies much earlier: I could imagine that there is _another_ "data" command that has a bogus length and just happens to end after the line "data 88".

Maybe that helps?

I could also imagine that the '. actually is the end of an example inside a blob, that literally looks like a fast-import script, but actually is not meant for _this_ fast-import run.

Ciao, Dscho

On Tue, 20 Jan 2009, Kelly F. Hickel wrote:

Can you find that part of the input? I wouldn't be too surprised if something were giving the wrong length in a data command, causing it to either eat another data command and end up in the data or to use not-quite-all of the data and end up near the end of the data.

	-Daniel
*This .sig left intentionally blank*