如何从Mercurial repo中删除大型文件

另见

在不知道自己在做什么的情况下，我启用了largefiles扩展名，提交了一个文件并将其推送到了Kill。现在我知道了我的错误，我需要永久地恢复这种改变

在这个问题上，我听从了苏的指导；我可以在本地删除大文件，但这不会影响窑中的远程repo。我曾尝试在Kill服务器上打开KilnRepositories中的repo，并对largefiles文件夹（以及从requires文件中删除“largefiles”），但在几次推/拉之后，文件夹和requires行又回来了

有没有办法让它永久化？（设置要求只读也不起作用）。

注意：这至少适用于（Windows）OrtoiseHG 2.4（Mercurial 2.2.1）->2.7.1（Mercurial 2.5.2）。我不会为未来或旧版本发言

在浏览了各种可用的mercurial扩展之后，我得出结论，一旦使用largefiles扩展提交了文件，通常不可能将存储库“转换回”

首先，两个理由解释了为什么你不想在回购协议中使用大文件：和

一旦文件作为大文件提交，要将其删除，必须从repo中删除对“.hglf”路径的所有引用。A不够，因为其提交内容将引用文件的路径，包括“.hglf”文件夹。一旦mercurial看到这一点，它将把“大文件”写回/.hg/requires文件，并且repo再次被锁定。同样，hg忘记并移除

选项1：如果您的repo处于隔离状态（您可以在所有本地和远程位置对repo进行端到端控制，并且没有其他人从该repo分支），则可以使用mq扩展和变更集。如果你及时发现了错误，这可能是唯一可行的选择

选项2：如果有问题的变更集（大文件提交）存在于草稿提交（或者可以强制返回草稿）上，则可以使用hg qpop将提交导入mq。这优于剥离，因为它保留了从提取的变更集向前提交的历史记录。在现实生活中，这通常是不可能的，因为您可能已经执行了合并并从公共阶段分支推/拉。然而，如果很快被抓住，mq可以提供一种挽救回购的方法

选项3：如果有问题的变更集只在一个地方被引用（原始提交），并且没有人试图撤销/删除/忘记变更集（从而创建多个引用），则可以使用hg，将违规后的第一个子变更集与违规的父变更集折叠。这样，攻击性变更集就变成了一个新的头，然后可以用mq strip剥离掉。在尝试导入到mq失败的情况下，这可以起作用

选项4：如果上述任何一项都不起作用，您可以使用或，将所有非违规变更集导出为修补程序（小心以正确的顺序导出），然后hg更新到违规之前的第一个sane变更集，mq剥离所有正向变更集的repo，然后按顺序重新应用导出的修补程序

选项5：（我最终做了什么）。在本地克隆repo，这样您就有两个副本：克隆到保存，克隆到销毁。在clone_to_keep中，更新到攻击前的第一个sane变更集。Mq剥离所有正向变更集。如果留下多个头部，则向下合并。在克隆到销毁中，更新到提示。在windows资源管理器中，将/clone_to_destroy中除.hg和.hglf文件夹之外的所有内容复制到/clone_to_keep文件夹。在Ortoise内部，将克隆中的所有更改提交给作为单个更改集保留的。出于历史目的，以只读状态保留一个要销毁的克隆的远程实例，并销毁所有其他实例

备选案文6：核备选案文。如果所有其他方法都失败了，并且如果您不关心回购协议与外部系统（bug跟踪、CI等）的集成，那么您可以遵循上述方法并使用hg扩展。这将创建受感染的回购协议的新副本，删除对违规变更集的所有引用；但是，它通过迭代整个repo中的每个变更集并将其作为新变更集提交给新的repo来实现。这将创建一个与任何现有分支repo不兼容的repo——所有变更集id都不会对齐。除非您没有分行回购，否则此选项可能永远不会起作用

在所有情况下，您都必须进行修复并手动重新应用到每个不同的存储库实例（复制repo文件夹、克隆，无论您选择何种方法）

最后，事实证明，启用大文件是一个极其昂贵的错误。修复它非常耗时，而且最终具有破坏性。我不建议允许大文件进入你的回购协议