hg提交大文件时候提示255错误的解决方案

客户端出外部版本，通常要保留pdb文件，以利于出现崩溃时，生成的dump文件能够快速定位。通常除了把exe/pdb打包传一份到内部的文件服务器的同时，我也采用hg做本地版本库管理。

版本出了十多次以后的某次，发现提交出错了，TortoiseHg提示error code是255。排查后发现是去除其中最大的一个pdb（数十M大小），其他的可以正常提交。

上网google下，大文件管理是hg的软肋。倒也不至于某些文章说的那样hg官方不支持什么的，事实上，hg从2.0开始(见http://mercurial.selenic.com/wiki/WhatsNew) 就官方已经集成了一个大文件插件，即Largefiles extension 见 http://mercurial.selenic.com/wiki/LargefilesExtension
需要注意到是，虽然包含了此插件，但必须配置开启后才可以通过命令行使用。配置方法见http://mercurial.selenic.com/wiki/UsingExtensions

若是图省事，可以直接进行全局的配置：

修改用户目录 (开始->运行->%USERPROFILE%) 下的mercurial.ini，在文件末添加这两行

[extensions]

largefiles =

比较推荐的做法针对性的经对需要的版本库做这个处理，例如我对外部版本备份启用此插件，而对平时开发用的版本不启用此插件，在.hg下新增hgrc文件（如果不存在的话），在文末新增这两行。

在启用largefiles的情况下（全局启用，或当前路径的版本库独立启用），可以使用命令行把旧有版本库进行转换。

hg lfconvert --size 10 oldrepo newrepo

转换后的库，提交大文件即成功了。

附注：

1. 这个插件会破坏hg这种DVCS原先把完全的版本信息存储在本地的优势。

在启用这个插件前，hg的原始仓库，和clone出来的所有仓库都是平等的，都包含有完整的历次版本内容。而被当成largeFile处理的文件不同，只有原始仓库在.hg\largefiles保留所有大文件的历次版本，而clone出来的仓库，在.hg\largefiles只存有每个largeFile的当前版本（而不是历次版本）。LargeFile的存储，有中心仓库的概念。这点与hg/git等的思想算是背道而驰了，也导致了一些局限性。

详见插件的官方说明：http://mercurial.selenic.com/wiki/LargefilesExtension

一些讨论 http://kiln.stackexchange.com/questions/4846/how-do-i-use-the-mercurial-largefiles-extension
2. 曾经也考虑过直接给版本库转为git来做，git的大文件可以随便提交，当然还有诸如效率更高之类的好处，粗略的记录下吧

a. fast-export http://repo.or.cz/w/fast-export.git，这个的好处是比 HgGit 插件快。

b. fast-export 是unix语法的，要安装cygwin

c. 比较悲剧的问题是，我们的项目中有一个说明文件不幸是中文命名的，转换过来会乱码，cgywin中的git版本较老

下载了新版本git，据称对中文文件名有改善的1.7.10以后的版本，在cgywin中编译，参考：

1. 在Cygwin中编译Git http://zengrong.net/post/1817.htm
2. 上文提到的问题我貌似都没遇到，倒是在configure的时候，提示checking whether the C compiler works... no，

可是我gcc/make/curl等等都装了，研究了好一段时间才知道还得加这个:mpfr (cygmpfr-4.dll)。见 http://wangjunle23.blog.163.com/blog/static/117838171201110853555933/
……我这里configure到时候没提示mpfr这东西，可是加上就能编译了

d. 遗憾的是，hg/git都更新到支持中文文件名的版本了，fast-export还是搞出乱码了。考虑到这里用途只是做备份，git大材小用了，自己在github的项目不至于会弄个中文文件名放着，当时又找到了此插件，就没折腾了。