在不知道我在做什么的情况下，我启用了largefiles扩展，提交了一个文件并将其推送到了窑中。现在我知道我的方式的错误，我需要永久地恢复这种改变。
我遵循SO的指导;我可以在本地删除大文件，但这不会影响窑中的远程回购。我试过在Kiln服务器上打开KilnRepositories中的repo并修改largefiles文件夹（以及从requires文件中删除'largefiles'），但是几次推/拉后文件夹和require的行返回。
有没有办法让这个永久？ （设置要求readonly也不起作用。）
答案 0 :(得分：12)
注意：至少（对于Windows）TortoiseHg 2.4（Mercurial 2.2.1） - > 2.7.1（Mercurial 2.5.2）。我不会代表未来版本或旧版本。
在查看了可用的各种mercurial扩展之后，我得出结论，一旦使用largefiles扩展提交文件，通常无法将存储库“返回”。
首先，为什么你不希望在你的回购中使用大型文件的两个理由：one和two。
一旦文件被提交为大文件，要删除它，必须从repo中删除对“.hglf”路径的所有引用。 backout是不够的，因为它的提交内容将引用文件的路径，包括'.hglf'文件夹。一旦mercurial看到这个，它会将'largefiles'写回/.hg/requires文件，并且repo再次被大文件锁定。同样用hg忘记并删除。
选项1：如果您的仓库处于孤立状态（您在其所有本地和远程位置都拥有对仓库的端到端控制权并且没有其他人从此仓库分支），则可以使用mq扩展名和strip变更集。如果你及时发现错误，这可能只是一个可行的选择。
选项2：如果违规变更集（大文件提交）存在于草稿的提交phase上（或者可以强制退回到草稿中），则可以将提交导入到mq和unapply the changeset使用hg qpop。这优于剥离，因为它从提取的变更集中保留了提交历史记录。在现实生活中，这通常是不可能的，因为您可能已经执行了合并并从公共阶段分支推送/拉出。但是，如果抓住很快，mq可以提供一种方法来挽救回购。
选项3：如果在一个且只有一个地方（原始提交）引用了违规变更集，并且没有人试图退出/删除/忘记变换集（从而创建多个引用），则可以使用hg rebase，用攻击的父变换集折叠攻击后的第一个子变更集。在这样做的过程中，进攻性的变化组成了一个新的头部，然后可以用mq条剥离。这可以在导入到mq的尝试失败的情况下起作用。
选项4：如果以上都不起作用，您可以使用transplant或graft将所有非违规变更集导出为补丁（小心按正确顺序导出它们），然后hg更新到攻击前的第一个合理的变更集，mq去除所有前进变更集的回购，然后按顺序重新应用导出的补丁。
选项5 :(我最终做了什么）。在本地克隆repo，以便有两个副本：clone_to_keep，clone_to_destroy。在clone_to_keep中，在攻击之前更新到第一个合理的变更集。 Mq剥离所有前向变更集。如果留下多个头，则向下合并。在clone_to_destroy中，更新到提示。在Windows资源管理器中，将/ clone_to_destroy中的所有内容（.hg和.hglf文件夹除外）复制到/ clone_to_keep文件夹中。在Tortoise内部，将clone_to_keep中的所有更改作为单个变更集提交。为历史目的保留一个只读状态的clone_to_destroy远程实例，并销毁所有其他实例。
备选案文6：核选择。如果所有其他方法都失败了，如果您不关心将repo与外部系统集成（错误跟踪，CI等），则可以按照前面提到的SO post使用hg convert扩展名。这将创建受感染仓库的新副本，删除对违规变更集的所有引用;但是，它通过迭代整个仓库中的每个变更集并将其作为新变更集提交给新仓库来实现。这会创建一个与任何现有分支回购不兼容的仓库 - 任何变更集ID都不会排成一行。除非您没有分支回购，否则此选项可能永远不会有效。
在所有情况下，您必须采取修复并手动重新应用到每个不同的存储库实例（复制repo文件夹，克隆，无论您喜欢哪种方法）。
最后，事实证明，启用大文件是一个非常昂贵的错误。这很费时间并且最终具有破坏性。我不建议允许大型文件进入你的回购。