我一直在考虑对文件系统进行版本控制。这是一个杀手级功能，我研究过 Wayback、ext3cow、zfs、fuse 解决方案，或者只是 cvs/svn/git 覆盖。
我认为 ext3cow 是满足我需求的模型。透明、高效，但我可以不使用额外ls abc@timestamp功能。只要我能以某种方式获得文件的自动化、透明版本控制即可。
它可以是瞬时的，也可以是基于 10 秒、30 秒、1 分钟、5 分钟、15 分钟等间隔的快照。它可以有效地处理给定目录中数千个各种大小的文件，大多数文件都很小，但有些文件高达 100m 到 1gb。
由于我在使用 Linux，因此 ZFS 不是一个真正的选择（并且不想通过 fuse 使用它，因为我已经有一个想要版本控制的 ext3 设置，而不是新的东西）。
有什么解决方案？
答案1
如果您使用 LVM 包装文件系统，则可以使用底层逻辑卷层创建快照卷。这是一个非常简单的过程，对于标准的“快照”操作（例如备份和撤消rm -fr错误）而言，它出奇地有效。
答案2
经过 8 年搜索我发现虚拟网络文件系统经过马可·R. 米兰体育报（与之前同名的项目不同，约翰·马登[哪一个做不同的事情]）。这虚拟网络文件系统用途SVN 版本在读/写操作中透明地：
我没有创建一个可以自行进行版本控制的文件系统，而是使用了现有的版本控制工具 subversion，并使其使用透明化。优点是，如果您了解 subversion，则此文件系统不需要您学习新工具
它是用 Python 编写的并使用 FUSE：
现在，通过调用附加的脚本来启动版本控制文件系统：
python svnfs.py -o svnroot=/home/marco/svnfiles /home/marco/myfiles
一旦一切正常，您应该能够获得两个目录的列表并看到内容是相同的。
现在，如果您在任一目录中创建（几乎）任何文件，它也会显示在另一侧。最大的区别是，如果您在 myfiles 目录中创建文件，它将自动置于版本控制之下（反之则不然）。
在示例中虚拟网络文件系统使用单独的目录来存放存储库。虽然我还没有测试过。但就我的需求而言，我希望将存储库放在我的工作目录中。
我还发现参考 Reiser44 年前的版本控制功能：
参见 Reiser 4。文件是目录。
例如：
diff -u main.C main.C/r/123或者访问属性
cat main.C/p/svn-eolstyle
echo "foobar" > main.C/p/my-property
似乎最好遵循该模型，因为主要的文件系统已经采用了该路线。
-保罗·奎尔纳
但我也没有检查过。
两年前我进一步寻找，找到了项目拳头用于生成可堆叠文件系统并联系教授。埃雷兹·扎多克的石溪大学该项目的顾问/导师是谁版本文件系统很久以前。引用：
http://www.fsl.cs.sunysb.edu/docs/versionfs-fast04/
http://www.fsl.cs.sunysb.edu/docs/versionfs-msthesis/versionfs.pdf
允许用户轻松高效地管理自己的版本。Versionfs 提供此功能，对于典型的用户类工作负载，开销不超过 4%。Versionfs 允许用户分别通过保留策略和存储策略选择保留哪些版本以及如何存储它们。用户可以选择最符合其个人需求的空间和性能之间的权衡：完整副本、压缩副本或块增量。虽然用户可以控制他们的版本，但管理员可以强制执行最小值和最大值，并为用户提供合理的默认值。
此外，通过使用 libversionfs，未经修改的应用程序可以检查、操作和恢复版本。用户只需运行熟悉的工具即可访问以前的文件版本，而不必学习单独的命令，也不必让系统管理员重新挂载文件系统。如果没有 libversionfs，以前的版本对用户来说就完全隐藏了。
最后，Versionfs 超越了过去系统所采用的简单写入时复制：我们实现了更改时复制。虽然我们最初预计新旧页面之间的比较会过于昂贵，但我们发现系统时间的增加被与写入未更改块相关的 I/O 和 CPU 时间的减少所抵消。当使用更昂贵的存储策略（例如压缩）时，更改时复制就更有用了。
我觉得这很有趣，但联系了参与该项目的人后，他们发现源代码的位置无人知晓。教授本人在邮件中表示：
Versionfs 的代码现在已经很老了，而且只在内核 2.4 中工作。如果你仍然想要一个可堆叠的版本控制 f/s，那么你就必须从头开始编写它 — 可能基于 wrapfs（请参阅 wrapfs.filesystems.org/）。
因此，这里没有可行的项目，尽管可堆叠文件系统的概念对我来说似乎非常好。有人想基于此启动项目吗？包装文件，请通知我:)
答案3
您可以检查吉特夫斯。它是一个基于 git 的 FUSE 文件系统，非常稳定并且非常容易使用。
基本上，它是 git 上的覆盖。每当您更新文件或目录时，它都会创建一个包含该更改的提交（知道批量提交，这样您在解压存档时就不会得到 100 个提交）。还知道同步您的远程并使用“始终接受我的”策略合并冲突。
当你挂载它时，它会给你带来两个目录：当前的和历史。
├── current │ ├── test1.md │ ├── test2.md │ ├── test3.md -> current/test2.md │ ├── test4.md │ └── test_directory └── history ├── 2014-11-23 │ ├── 20-00-21-d71d1579a7 │ │ └── testing.md │ └── 20-42-32-7d09611d83 │ ├── test2.md │ └── testing.md ├── 2014-12-08 │ ├── 16-38-30-6d6e71fe47 │ │ ├── test2.md │ │ └── test1.md
更多信息可在此处找到页。
答案4
尝试快照-- 我自己没有用过它，但是在查看文件级重复数据删除系统时偶然发现了它。