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