hg convert - partial conversions?

Jesse Glick jesse.glick at sun.com
Wed Feb 13 18:23:40 CST 2008


Brian Wallis wrote:
> a 'dumb' conversion of the whole thing ends up with 3.7G repository

That's definitely way too much, but see if excluding binaries and 
branches helps. In my case, a "dumb" convert could not even complete - 
Python seems to have run out of address space trying to parse cvsup 
output - but a convert of the slimmed-down history ran fine in a couple 
of hours and only added maybe 110Mb to the .hg repo size compared to 
about 500Mb for an import of a trunk snapshot. (The compressed repo 
produced by 'hg bundle' was only around 130Mb, quite good I think.)

> it contains way too many binary files

This will indeed kill repo size. There is no good solution with Hg at 
the moment if your project requires a lot of large versioned binary 
files. I am using a custom Hg extension to store big binaries externally 
(mentioned on this list in the past), which sort of works but is far 
from ideal.

> a lot of which are not marked as binary causing other issues

For Windows users you mean? I also found that usage of -kb in the 
repository I converted was very erratic. (Some binary files unmarked, 
some text files marked, some files marked with more exotic expansion 
keywords...) Fortunately Hg treats everything as binary by default, and 
the win32text extension's "clever" en/decoders simply do CRLF 
translation on any file not containing NUL, which I found to work 
perfectly in practice. BTW the prepcvs.rb I pointed you to autodetects 
binary files based on NUL, skipping over them, and automatically 
normalizes line endings in the remaining text files. It ignores any KW 
expansion mode set in the RCS file, since these are often wrong anyway.

-- 
jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net
selenic.com/mercurial http://google.com/search?q=e%5E%28pi*i%29%2B1



More information about the Mercurial mailing list