Brian Harring wrote:
1) We need a thin manifest -> thick manifest converter.  Thin
manifests are used for git- they store just DIST entries.  Thick (also
known as 'full'), are what cvs/rsync users are familiar with- it holds
checksums for all content.

carebear is the current person volunteering to sort this
(help may be appreciated, talk to him/her/it).

heh :)

I'll read up, spend some time on IRC, and see what I can do to help here.


replay it into git via tailor;


Never knew about that tool... not sure about the wisdom of adding an extra moving part just to keep the lights on for those few hours... Given the "2G of history" issue Diego mentioned, which if I understand correctly, effectively means that the future gentoo git can never rebase its commit history, why chance it?

In my last experience with cvs->git (at the time I was building a rsync (binutils cvs)->git mirror for a client), the most difficult thing about cvs->git was trying to scrub the identity data.

I don't remember the exact issue, but somehow, git had identity uniqueness constraints that cvs happily ignored, or something like that. I never thought to try using svn as an intermediate -- but I like that idea a lot and wish I had thought of it when I needed to.

Anyhow, wrong ml for this, I'll subscribe to -scm.

-gmt

Reply via email to