Re: Call for testing: cvs2bzr
John Arbash Meinel <[email protected]>
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.devel |
|---|---|
| Message-ID | <4A8D5975.6060801__19255.088028922$1250796180$gmane$org@arbash-meinel.com> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Clatworthy wrote: > Greg Ward wrote: >> On Wed, Aug 19, 2009 at 12:30 AM, Ian >> Clatworthy<[email protected]> wrote: >>> That's pretty well it. We *could* handle a separate blobs file but it's >>> nicer w.r.t. memory consumption for us to go the inline blob path ala >>> hg. Unlike hg though, bzr has no limitations w.r.t. merge parent count. >> But keep in mind that inline blobs make the dump file much much >> larger. That'll be troublesome for large conversions. I implemented >> a rather vile hack in hg-fastimport to make it handle separate blobs: >> write each blob to .hg/blobs/<blobmark>. Then rm -rf .hg/blobs at the >> end of conversion. It's slow and doubles the disk space overhead, but >> at least it doesn't suck up RAM. And it's still less disk space than >> inline blobs. > > bzr fast-import will handle blobs being defined once and reused over and > over again. The trouble is that it doesn't know which ones get reused > unless it does two passes, so it acts conservatively and keeps all of > them in memory. Fine for small imports but lousy for large ones. Reusing > mark idrefs or using inline blobs solves the problem implicitly. Note that you could just track sha1 => (file_id, revision_id) and then go to the target repository to extract the text you need in the future. That would allow you to only store a mapping in memory, rather than actual content. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqNWXUACgkQJdeBCYSNAAP/4wCdFmIFHRxGCLmLY6H842LDbrWP fOAAn2HemKZRJmdE8Cb2+DsPaxEqA9fj =/VUs -----END PGP SIGNATURE----- ------------------------------------------------------ http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2385631 To unsubscribe from this discussion, e-mail: [[email protected]].