过去,我一直在使用mercurial中的largefiles扩展来保存数据以及我一直在处理的代码。我认为这是一个错误,我想删除“largefiles”目录(8GB)。我们的网络用户目录限制为10 GB,我需要空间。我很久没有使用任何大文件了。当他们永远离开时,我不会想念他们。
所以我的问题是
答案 0 :(得分:5)
关于你的第一个问题,我做了一个实验:
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
然后,我从[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>
您需要与您的团队协调,以便:
largefiles
$HOME/.hgrc
个扩展名
largefiles
中删除hgrc
扩展名(hgrc
的位置取决于主存储库是服务器,SSH或HTTP的方式) 。这将使某人不可能意外地将一个大文件添加到新仓库的克隆中并推送它!请注意lfconvert
仅在启用largefiles
扩展名时可用。我建议在第3点之后将其从$HOME/.hgrc
中删除,并使用--config extensions.largefiles=
选项在单个命令上启用它,如上例所示。
另请注意,转换为普通仓库将允许使用最近的fsmonitor
extension,它使用内核inotify机制(或MacOSX上的等效机制)来显着加速某些操作,如hg status
。例如,对于我拥有的大型存储库,hg status
从10秒到0.5秒: - )