如何从 mercurial 存储库中安全地禁用/删除 largefiles 目录？答案

【问题标题】：How do I safely disable/remove the largefiles directory from a mercurial repository?如何从 mercurial 存储库中安全地禁用/删除 largefiles 目录？
【发布时间】：2013-01-22 00:37:21
【问题描述】：

过去，我一直在使用 mercurial 中的 largefiles 扩展来保存数据以及我一直在处理的代码。我认为这是一个错误，我想删除“大文件”目录（8GB）。我们的网络用户目录限制为 10 GB，我需要空间。我已经很长时间没有使用任何大文件了。当他们永远离开时，我不会想念他们。

所以我的问题是

我能否在不损坏 repo 的情况下删除 .hg 下的 largefiles 目录？
如果我这样做了，即使丢失了一些大型数据文件，我是否能够检查旧代码？
我是否应该从该 repo 的所有克隆中删除这些文件，以避免再次使用来自另一个克隆的大文件污染所有 repo？

【问题讨论】：

标签： version-control mercurial large-files mercurial-extension

【解决方案1】：

对于你的第一个问题，我做了一个实验：

创建了一个包含大文件的存储库。
hg update null
已删除.hg\largefiles
hg update

大文件回来了！事实证明，至少在 Windows 上，大文件也缓存在 %UserProfile%\AppData\Local\largefiles 中。由于这是我唯一的大文件数据库，它只包含我的一个大文件，所以我也删除了它。这个缓存包含来自多个本地启用大文件的数据库的大文件，所以你必须小心这个。如果拥有两个副本似乎很浪费，那么如果本地数据库与%UserProfile% 位于同一驱动器上，那么它们是硬链接的。我的系统中有两个驱动器，事实证明，如果数据库位于不同的驱动器上，它仍会复制到 AppData 位置，但没有硬链接，因此您的磁盘使用量会增加一倍。

删除大文件的所有副本后，hg update 给出：

1 files updated, 0 files merged, 0 files removed, 0 files unresolved
getting changed largefiles
largefile.dat: can't get file locally
(no default or default-push path set in hgrc)
0 largefiles updated, 0 removed

然后我从.hg\hgrc 中删除了[extensions], largefiles= 以禁用扩展。此时存储库工作正常，但仍然有 .hglf 目录在过去有大文件的变更集中带有散列。所以第二个问题的答案是肯定的，你可以查看旧代码。

对于您的第三个问题，要消除大文件和散列的所有痕迹，请创建一个文件：

exclude .hglf

然后运行：

hg convert --filemap <file> <srcrepo> <destrepo>

然后，您的用户将不得不克隆这个新的、已修改的存储库，因为 convert 会修改变更集，并且新数据库将与旧数据库无关。

【讨论】：

感谢您提供清晰详细的回复！实际上，largefiles 目录立即返回，但为空（一旦我删除了用户缓存）。然后，当我禁用 .hg/hgrc 中的扩展名时，下次我键入 hg st 时，会发生这种情况：abort: unknown repository format: requires features 'largefiles' (upgrade Mercurial)!。一旦我启用了 largefiles 扩展，它就会再次工作。所以我现在无法理解你的第二点。
你确定.hg\largefiles在禁用扩展后仍然被删除了吗？
嗨，是的，我做到了。但我现在知道问题出在哪里了。还有一个名为.hg/requires 的文件，其中包含一行largefiles。我只是删除了那行，现在一切正常。也许您使用了不同版本的 mercurial 并且没有此文件。无论如何，非常感谢您在这里的帮助！
谢谢马克。我删除了最后几个变更集，因为我的错误是最近才出现的——而且——阅读 cmets 是值得的————Stephan 的 .hg/requires 方法也对我有用。作为奖励，在浏览器中从 KilnHg 中剥离变更集也可以无缝运行。 TortoiseHg 3.2（以及因此 Hg 3.2）在本地 repo 的 Strip 命令中有一个选项“不要修改工作副本” - 勾选它。哦，你是在一个 repo 的副本上做的，对吧？

【解决方案2】：

将普通存储库转换为大文件的同一命令 lfconvert 也可用于其他方向：

$ hg --config extensions.largefiles= help lfconvert
hg lfconvert SOURCE DEST [FILE ...]

convert a normal repository to a largefiles repository

Convert repository SOURCE to a new repository DEST, identical to SOURCE
except that certain files will be converted as largefiles [...]

Use --to-normal to convert largefiles back to normal files; after this,
the DEST repository can be used without largefiles at all.

所以下面的命令可以解决问题：

$ hg --config extensions.largefiles= lfconvert --to-normal <LARGEFILE_REPO> <PLAIN_REPO>

您需要与您的团队协调，以便：

每个人都将他们的最新更改推送到大文件主存储库
对主存储库的访问被永久禁用（以避免意外推送）
每个人都从他们的$HOME/.hgrc 中删除了largefiles 扩展名
从提供主存储库访问权限的用户的hgrc 中删除largefiles 扩展（hgrc 的位置取决于主存储库是服务器、SSH 还是 HTTP）。这将使某人不可能不小心将大文件添加到新仓库的克隆中并推送它！
将主存储库转换为普通存储库
决定新主存储库的名称/路径更改（如果有）
允许访问新的普通主存储库
每个人都克隆新的普通仓库

请注意，lfconvert 仅在启用 largefiles 扩展时可用。我的建议是，按照第 3 点，将其从 $HOME/.hgrc 中删除，并在带有 --config extensions.largefiles= 选项的单个命令上启用它，如上例所示。

另请注意，转换为普通 repo 将启用最近的 fsmonitor extension，它使用内核 inotify 机制（或 MacOSX 上的等效机制）显着加速某些操作，如 @987654335 @。例如，对于我拥有的一个巨大的存储库，hg status 从 10 秒变为 0.5 秒 :-)

【讨论】：