Git设计决定存储内容而不是差异 [英] Git design decision on storing content rather than differences

问题描述

任何人都可以给我一些想法，为什么Git的开发做了一个设计决定来存储文件（斑点）的内容，所以当内容发生变化需要创建一个新斑块？

我相信颠覆存储的是修订而不是内容，所以当内容改变时，它只是跟踪两者之间的差异。不能这样做也是这样吗？什么是存储的内容，而不是修订版的好处？

解决方案

我无法找到一个快速谷歌的答案，但我相信它归结为一个简单的没关系，因为磁盘空间很便宜。

在源代码管理工具中存储修订是非常棘手的。如果您只存储了之前版本与当前版本之间的差异，则最终会出现两个问题：

1. 返回最新版本常见的情况）需要最工作，代码需要通过每一修订组合在一起来组装该修订。


2. 的任何错误（比如说，一个磁盘故障）与一个修订腐化访问每个后
   

我相信大多数现代VCS实际存储最新版本（出于性能原因），如果使用差异，则用于回到时间，不转发。

Could anyone give me some idea to why git developers made a design decision to store contents of files (blobs), so when the content changes a new blob needs to be created?

I believe subversion stores revisions rather than contents, so when the content changes, it simply keeps track of the differences between the two. Couldn't git have done it like this as well? What's the benefit of storing contents rather than revisions?

解决方案

I couldn't find the answer with a quick google, but I believe it boils down to a simple "it doesn't matter 'cause disk space is cheap".

Storing revisions within a source code management tool is tricky. If you only ever store the difference between the previous revision and the current, you end up with two problems:

1. Returning the latest revision (the common case) requires the most work, as the code needs to assemble that revision by combining every revision together.
2. Any error (say, a disk fault) to one revision corrupts access to every later revision.

I believe that most modern VCS actually store the latest revision (for performance reasons) and differences, if used, are used to go back in time, not forwards.

这篇关于Git设计决定存储内容而不是差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！