Question

数据集是6766个文件夹中的97984个文件，共有2,57 GB。其中很多都是二进制文件。

对我而言，这听起来并不多。可能有50个文件的每日数据变化率为数百KB。但我害怕颠覆会变得非常缓慢。

无论如何它永远不会快，最后一次在v1.2推荐将它分成多个存储库。不，我不喜欢这个。

有没有办法告诉Subversion或任何其他免费的开源版本控制来信任文件修改时间/文件大小来检测文件更改而不是比较所有文件？有了这个并将数据放在一个快速的现代SSD上，它应该快速运行，比如说，完成提交的时间少于6秒（比从Windows资源管理器属性对话框中获取摘要多3倍）。

Answer 1

我认为最好的方法就是亲自尝试。 Mercurial可以正常工作，因为如果没有更改mtime，它就不会比较文件内容。

以下是时间安排（不在ssd上）：

Data size - 2.3Gb (84000 files in 6000 directories, random textual data)
Checkout time (hg update from the null rev to tip) - 1m5s
status time (after changing 1800 files ~35MB) - 3s
commit time (after the same change) - 11s

如果要在提交期间避免完整的树扫描，可以尝试inotify extension（使用“tip”版本，其中应修复所有已知的错误。）

你需要知道克隆这样一个repo对你的用户来说可能会很痛苦，因为他们必须传输大量的数据。

编辑：我错过了（隐含）你在Windows上运行它的事实，因此inotify将无法工作（希望它将来会被移植到Windows，但现在情况并非如此）。

编辑2：添加时间

Answer 2

有没有办法告诉我颠覆或任何其他免费开放源版本控制来信任文件修改时间/文件大小来检测文件更改，而不是比较所有文件。

我认为颠覆已经做到了这一点。在libsvn_wc questions.c（rev39196）中查看这段代码：

  if (! force_comparison)
    {
      svn_filesize_t translated_size;
      apr_time_t last_mod_time;

      /* We're allowed to use a heuristic to determine whether files may
         have changed.  The heuristic has these steps:


         1. Compare the working file's size
            with the size cached in the entries file
         2. If they differ, do a full file compare
         3. Compare the working file's timestamp
            with the timestamp cached in the entries file
         4. If they differ, do a full file compare
         5. Otherwise, return indicating an unchanged file.

我对调用此函数的几个地方进行了采样，force_comparison参数始终为FALSE。我只花了几分钟看。

Answer 3

我刚刚在我的机器上做了一个基准测试，看看它是什么样的：

Data size - 2.3Gb (84000 files in 6000 directories, random textual data)
Checkout time 14m
Changed 500 files (14M of data changes)
Commit time 50seconds

为了了解手动比较所有这些文件需要多长时间，我还针对该数据的2次导出（版本1与版本2）运行差异。

Diff time: 55m

我不确定ssd会不会像你希望的那样减少提交时间，但是我使用普通的单个sata磁盘来获得50秒和55分钟的比较。

对我来说，这些时间强烈建议默认情况下svn会检查文件的内容。

这是svn 1.6。

我可以将Subversion用于多千兆字节的数据集吗？

3 个答案: