浓缩 Mercurial 修订历史
我们有 2,700 多个修订，在使用 TortoiseHg 进行合并、推送或其他任何操作时，加载 Mercurial 需要 30-45 秒。我想知道除了直接创建一个新的存储库来清理修订历史记录之外，是否还有其他方法。比如说，砍掉修订版 2,400 左右的文件。
We have 2,700+ revisions and it takes a good 30-45 seconds to load Mercurial when doing a merge, push or anything else with TortoiseHg. I'm wondering if there's a way other than straight up creating a new repository to clean up the revision history. Say, cut off files under revision 2,400 or so.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不是您问题的答案，但是：
也许在设置中将“日志批量大小”减少到 100（默认为 500）会有所帮助。
我们的 2300+ 转 repo 在 2-3 秒内加载（在我的 15k rpm SAS 磁盘上，但不用介意），所以我不认为你的问题是很多转，真的。那里有更大的回购协议。 :)
请注意，Mercurial 核心和 TortoiseHg 开发人员都热衷于寻找性能错误，因此可能值得在邮件列表上寻求帮助。
Not an answer to your question, but:
Maybe reducing "log batch size" to 100 (default is 500) in the settings helps.
Our 2300+ rev repo loads in 2-3 secs (off my 15k rpm SAS-disk, but never mind that), so I don't think your problem is many revs, really. There are much bigger repos out there. :)
Note that both Mercurial core and TortoiseHg developers are keen on finding performance bugs, so it might be worthwhile to ask on the mail-lists for assistance.
您可以使用 histedit 扩展将多个变更集压缩为一个。对一系列修订执行 histedit 命令将生成一个如下所示的文本文档（来自 histedit 文档）：
将上面列表中的某个变更集的
pick更改为fold会将其折叠到之前的变更集中。它将使您有机会解决失败的合并并输入新的提交消息。警告：
使用 histedit 将修改存储库历史记录，包括哈希 ID，这将导致问题，除非您在进行更改后使用新的存储库克隆重新启动每个开发人员。另外，您可能需要将 histedit-ing 限制为具有单个父级的变更集（即：非合并变更集）。
You can use the histedit extension to compress several changesets into one. Executing the histedit command on a range of revisions will spawn a text document that looks like this (from the histedit documentation):
Changing
picktofoldfor a certain changeset in the list above will fold it into the previous changeset. It will give you an opportunity to resolve failed merges and enter a new commit message as well.WARNING:
Using histedit will modify the repository history, including hash IDs, which will cause problems unless you re-start each developer with a new repository clone after the changes have been made. Also, you would probably need to limit your histedit-ing to changesets with a single parent (ie: non-merge changesets).