我已经将少量树克隆到我的本地磁盘中，并且从我有限的笔记本电脑磁盘中占用了太多空间。与非分布式版本控件（如SVN和CVS）不同，当您签出git或Mercurial存储库时，您将获得整个树，包括整个历史记录，并且由于我很少将任何代码提交到这些存储库，但希望保持它们 - 到目前为止，我发现这些分布式版本控制系统浪费了太多的本地磁盘。
到目前为止我几乎没有什么想法可以消除这种浪费：
在本地磁盘上创建一个zfs或btrfs分区（可能是一个循环文件系统，因为我不想让它过于持久），这应该可以更好地利用重复的文件块。这可能需要太多CPU周期才能使其效率低下。
放弃使用版本控制并创建脚本以每天下载包含整个存储库的.zip文件。这将占用太多带宽，我宁愿不这样做。
我的最终解决方案是使用git / hg，就像我们使用SVN和CVS一样 - 在服务器上保存历史记录，在本地保存最新版本，或者在本地保留有限的历史记录，两者都不会破坏其他所有内容我可以看到日志或将文件还原到以前的版本，如果本地不可用，版本控制系统将从远程获取所需的信息。
答案 0 :(得分：2)
使用git，您可以使用--depth选项仅创建浅层副本。
另一方面，你不会以这种方式节省太多空间： http://blogs.gnome.org/simos/2009/04/18/git-clones-vs-shallow-git-clones/
答案 1 :(得分：2)
使用svn，你实际上有2个完整的，未压缩的已检出版本的副本（.svn中的每个文件的完整副本）。对于mercurial，您有1个已检出修订版的完整未压缩副本和一个高度压缩的二进制增量表示（在.hg/store中向下）。在很多情况下（可扩展的文本文件），包含所有内容的hg克隆实际上比单个修订版的svn checkout更小。
我不认为你的块级重复数据删除会有所帮助。 Mercurial和Git都使用非常有效的二进制增量，然后压缩它们的存储中几乎没有冗余信息，并且不会有块对齐。
答案 2 :(得分：2)
从hg clone帮助信息：
To pull only a subset of changesets, specify one or more revisions
identifiers with -r/--rev or branches with -b/--branch. The resulting
clone will contain only the specified changesets and their ancestors.
您应该能够使用HG的修订语法来限制您获得的修订数量，假设您想要的不仅仅是最新版本。使用-r tip来获取提示。
答案 3 :(得分：1)
使用mercurial，您可以要求一个空的工作副本（仅克隆.hg文件夹）：
hg clone -U <source>
有关更多选项，请参阅 hg帮助克隆。
我希望这会有所帮助。
答案 4 :(得分：0)
使用＆＃34; hg share＆＃34;。这将允许您只保留一个共享历史记录和多个修订版本作为工作副本。