缩小汞回购规模（特别是清单）
[英]Shrinking Mercurial repo size (manifests in particular)
问题描述
We're currently undergoing an attempt to migrate our mercurial (in this case an ancient version of Kiln) to BitBucket and we immediately ran in issues with size (if you don't know, BitBucket imposes a rather generous 2gb repo limit - that we happened to blow by). 
我们目前正在尝试将Merurial（在这种情况下为Kiln的较早版本）迁移到BitBucket，我们立即遇到大小问题（如果您不知道，BitBucket施加了相当大的2gb回购限制-我们碰巧碰到了）。
Anyways, I've cleaned up the sins of the past: 无论如何，我已经清理了过去的罪过：
- using convert with filemaps (removing binaries/static files that should never been in the repo) 使用带有文件映射的转换（删除不应在存储库中的二进制文件/静态文件）
- creating separate repos for other things that shouldn't have been in the main repo 为不应在主仓库中的其他事物创建单独的仓库
- attempting to use generaldelta to reduce size (as per https://www.mercurial-scm.org/wiki/ScaleMercurial ) 尝试使用generaldelta减小大小（根据https://www.mercurial-scm.org/wiki/ScaleMercurial ）
- using branchmaps to try to consolidate old branches and their associated changesets 使用分支图尝试合并旧分支及其关联的变更集
Even with these steps, I still have a very large manifest file, despite the "data" stored for the repo shrinking down to a "manageable" size (~600mb), my manifest file is nearly 700mb. 即使经过这些步骤，我仍然有一个非常大的清单文件，尽管为回购存储的“数据”缩小到“可管理”的大小（〜600mb），但清单文件却接近700mb。
Some additional information: in general, we practice branch-per-feature and have two-branch track out to environments: 一些其他信息：通常，我们按功能进行分支，并且对环境有两个分支的跟踪：
- a release branch (deployed to staging and then to prod) 发布分支（部署到暂存然后部署）
- default branch (originally off of release, all features are first merged here and then to release. this branch dies and is reborn every two weeks) 默认分支（最初不发布，所有功能都先合并到此处，然后发布。此分支死掉，每两周重生一次）
One difference in this workflow is that default itself never is merged in to release (a la gitflow/hgflow). 此工作流程的一个不同之处在于，默认值本身永远不会合并到版本中（la gitflow / hgflow）。 Does this uni-directional flow into default cause issues? 这种单向流入默认值会导致问题吗？
We "only" have 120 open branch heads, so it seems like that's manageable? 我们“只有” 120个开放的分支机构，这似乎是可以管理的吗？
I'm obviously missing some step here (or else the repo is just completely hosed). 我显然在这里缺少一些步骤（否则，回购协议就完全被取消了）。
1 个解决方案
解决方案1
0 已采纳 2015-12-01 16:22:29
Just for future reference, I followed Tim's suggestion above. 仅供以后参考，我遵循上述Tim的建议。 My full script ended up looking like this: 我的完整脚本最终看起来像这样：
hg --config format.generaldelta=1 clone --pull oldrepo oldrepo-generaldelta
hg --config format.generaldelta=1 clone --pull oldrepo-generaldata oldrepo-generaldelta2
hg convert --filemap filemap.txt oldrepo-generaldelta2 newrepo
As Tim mentioned in his linked answer - our manifests went from about 700mb down to about 40mb with the second clone. 正如Tim在他的链接答案中提到的那样-第二个克隆的清单从大约700mb下降到了40mb。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.