如何查找Mercurial存储库的大小？

Question

因此，例如，如果有一个mercurial仓库https://code.google.com/p/potentiallyLarge，有没有一种命令可以让我在克隆之前找出它的大小？类似于

hg size https://code.google.com/p/potentiallyLarge

此外，针对Subversion仓库是否有相应的命令可供使用？

- shafty

---

我对SVN的答案非常感兴趣，因为我正在考虑使用Mercurial（hgsubversion）通过互联网克隆一个大小超过10GB、具有>10000个修订版本的SVN仓库（由svn list -R确定）。 - Tim Delaney

@TimDelaney 如果您的情况是这样，最好使用 svnsync 然后从本地克隆该存储库。只是猜测。 - Ry4an Brase

@Ry4an 我考虑过这样做（然后将URL更改为上游SVN）。缺点是会使存储空间翻倍（至少是暂时的）。此外，我不知道是否会在总数据传输量上获得任何优势。我正在为本地开发人员设置一个Hg仓库，具有双向同步功能。已确定并测试了工作流程，以允许每个人像使用Hg一样正常工作（分支、合并等），并带有一些钩子来防止工作流程意外中断（不要将合并到SVN分支...）。只是最初的克隆会很麻烦-我应该获取所有内容还是只获取子集？ - Tim Delaney

我不使用hgsubversion，但我想象它的克隆会获取所有内容。相比克隆，svnsync的优点在于它是可恢复的，如果大型初始克隆失败，你就会卡住。 - Ry4an Brase

不，这不是问题——你可以拉取到某个特定的版本。当然，如果单个版本太大，那就是一个问题，这时候最好拉取整个历史记录（如果你只拉取HEAD，那就像从头开始做SVN checkout……）。 - Tim Delaney

Answer 1

磁盘使用的大小与克隆时使用的带宽不同。一些托管网站（例如Bitbucket）显示磁盘上的大小，以便您在克隆之前知道需要多少空间。但我发现Google Code没有显示，所以这里对您没有帮助。

Mercurial的wire protocol没有公开任何可以告诉您存储库有多大的命令。当您进行普通克隆时，客户端不知道将接收多少数据，它只会接收到一系列数据流。在接收到更改日志后，客户端知道要期望多少个清单和文件日志，但它不知道它们的大小。

实际上，服务器很难计算克隆将使用多少数据：网络带宽使用的比磁盘空间少，因为使用的压缩方式不同（bzip2 vs gzip）。但是，如果您在克隆时使用--uncompressed（Google Code不支持），则有一个技巧，请参见下文。

唯一了解克隆使用带宽的方法是制作一个克隆。如果您已经有一个克隆，可以使用hg bundle来模拟克隆：

$ hg bundle --all my-bundle.hg

捆绑包的大小将告诉您存储库中有多少数据。

一个技巧：如果Google Code支持hg clone --uncompressed，那么您可以使用它来了解远程存储库的大小！当您使用--uncompressed时，客户端会要求服务器按原样发送.hg/目录的内容 - 而不是使用bzip2重新压缩它。方便的是，服务器通过告诉客户端存储库的大小来启动流。因此，您可以开始这样的克隆，然后在客户端打印出告诉您存储库大小的行后中止它（使用Control-C）。

- Martin Geisler

Answer 2

更新： 我下面的回答是错误的，但我会保留它，因为MG提供了一些很好的信息。看起来正确的答案是“不行”。

这不是一个很好的方法，但是是一种解决方法。一个hg clone URL实际上只是hg init; hg pull URL。而命令hg incoming告诉你如果你执行pull会得到什么，所以你可以这样做：

hg init theproject
cd theproject
hg incoming --stat URL_TO_THE_PROJECT

如果您执行以下操作，您可以很好地猜测将拉取多少数据：

hg pull URL_TO_THE_PROJECT

我不确定hg incoming的网络效率，但我认为它不会从所有变更集中下载所有内容，尽管我可能对此有所误解。 它提供了一个--bundle选项，可以将所有从incoming下载的内容保存到文件中，以后可以从该文件中拉取以避免重复下载。

- Ry4an Brase

---

由于客户端无法说“请给我这个或那个变更集的更新日志”，所以传入的命令将下载所有内容。 - Martin Geisler

糟糕，我本来希望它只下载“头文件”，而不是真正的“增量文件”。 - Ry4an Brase

是的，那是你从输出中期望的...但不幸的是今天它不能做到。 - Martin Geisler