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

时间:2013-01-22 00:37:21

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

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

所以我的问题是

  1. 我可以删除.hg下的largefiles目录而不损坏repo吗?
  2. 如果我这样做,即使丢失了一些大型数据文件,我是否可以查看旧代码?
  3. 我应该从该回购邮件的所有克隆中删除这些文件,以避免再次使用来自其他克隆的大文件来污染所有回购邮件吗?

2 个答案:

答案 0 :(得分:5)

关于你的第一个问题,我做了一个实验:

  1. 使用大文件创建了一个仓库。
  2. hg update null
  3. 已删除.hg\largefiles
  4. hg update
  5. 大文件回来了!事实证明,至少在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
    

    然后,我从[extensions], largefiles=移除了.hg\hgrc以停用该扩展程序。此时,存储库工作正常,但仍然有.hglf目录,其中包含变更集中的哈希,用于存放大文件。所以第二个问题的答案是肯定的,你可以查看旧代码。

    对于第三个问题,要消除所有大型文件和哈希值的痕迹,请使用以下命令创建一个文件:

    exclude .hglf
    

    并运行:

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

    然后,您的用户必须克隆这个新的,已修改的存储库,因为convert会修改更改集,而新数据库将与旧数据库无关。

答案 1 :(得分: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>

您需要与您的团队协调,以便:

  1. 每个人都将最新的更改推送到largefile master repo
  2. 永久禁用对主仓库的访问(以避免意外推送)
  3. 每个人都从largefiles
  4. 中删除$HOME/.hgrc个扩展名
  5. 从提供对主存储库的访问权限的用户的largefiles中删除hgrc扩展名(hgrc的位置取决于主存储库是服务器,SSH或HTTP的方式) 。这将使某人不可能意外地将一个大文件添加到新仓库的克隆中并推送它!
  6. 执行主回购转换为普通回购
  7. 决定新主仓库的名称/路径更改(如果有)
  8. 启用对新的普通主仓库的访问
  9. 每个人都克隆新的普通仓库
  10. 请注意lfconvert仅在启用largefiles扩展名时可用。我建议在第3点之后将其从$HOME/.hgrc中删除,并使用--config extensions.largefiles=选项在单个命令上启用它,如上例所示。

    另请注意,转换为普通仓库将允许使用最近的fsmonitor extension,它使用内核inotify机制(或MacOSX上的等效机制)来显着加速某些操作,如hg status。例如,对于我拥有的大型存储库,hg status从10秒到0.5秒: - )