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