我的问题比标题中声明的更笼统。
我知道源版本控制仅存储有关差异的信息。据我了解，维基百科也是如此，github也是如此。
但他们都有能力显示具有特定修订的整个文件。他们是否将其从第一个版本逐步恢复到特定版本？
还有一个问题。如果他们只存储差异，他们如何在带有上下文的 ui 中显示它们（更改前后的小文本）。
编辑： github存储整个快照而不是增量
问问题
2029 次
3 回答
6
我知道源版本控制仅存储有关差异的信息。
正如关于存储内容而不是差异的 Git 设计决策问题所说明的那样，这并不是Git 所做的。
不过，它确实具有“打包”格式，可以使用 LibXDiff 库中的二进制增量以增量形式存储对象。但这主要用于网络传输。
请参阅“ git 二进制差异算法（增量存储）是否标准化？ ”。
这就是为什么 git在您获取时会“解析 delta ”。
于 2012-05-28T10:45:48.053 回答
4
要阅读有关存储版本控制数据的不同方式的优缺点的非常有趣的内容，我强烈建议您阅读 Eric Sink 的文章Time and Space Tradeoffs in Version Control Storage。
存储是版本控制系统最困难的挑战之一。对于每个文件，我们必须存储曾经存在的每个版本。版本控制存储库的逻辑大小永远不会缩小。它只是不断增长和增长，每个旧版本都需要保持可用。
那么，存储所有内容的每个版本的最佳方式是什么？
于 2012-05-29T22:23:29.390 回答
3
不幸的是，维基百科……将数据库中的每一个修订都以某种形式的 XML（？）作为文本保存。
看看wikipedia 数据库模式。特别是最近的变化和文字。
因此，他们对“生物学”页面的第一个副本进行了出色的 O(1) 查找。这带来了不幸的副作用，导致维基百科的技术成本从 2010-2011 年的 800 万美元飙升至 2011-2012 年的 1200 万美元。尽管硬盘驱动器（和其他所有东西）变得更便宜，而不是更贵。
保留每个文件的修订控制就这么多。Git 采取了一种可爱的方法。请参阅git 存储模型是否浪费？.
它存储每个文件，类似于上述方法。一旦 repo 占用的空间超过某个限制，它就会进行强力重新打包（有一个选项来设置它的尝试程度 - --window=[N], --depth=[N] ），这可能需要几个小时。它对所述重新打包使用增量和无损压缩的组合（递归增量，然后对您拥有的任何位应用无损压缩）。
其他像 SVN 使用简单的增量压缩。（从记忆中，你不应该相信）。
脚注：增量压缩存储增量更改。无损压缩很像 zip、rar 等。
于 2012-06-12T19:01:49.657 回答