SVN等VCS如何存储文件？
当我学习 Git 时，我了解到其他 VCS 系统（例如 SVN）通常存储对文件基本版本的更改。因此，作为一个逻辑推论，如果我想查看文件 A 的版本 4，SVN 将在交付我想要的版本之前使用提交的所有更改集即时修补基本版本文件，直到版本 4？
下面的图片可能会有所帮助。 
简而言之，只有基础版本文件是静态存储的，其他都静态存储版本是使用基本文件和必要的更改集动态生成的。
正确的？
谢谢。
As I am learning Git, I get to know that the other VCS systems like SVN usually store changes to a base version of files. So, as a logical deduction, if I want to check out the version 4 of the file A, the SVN will patch the base version file on-the-fly with all the change sets commited until version 4 before delivering the verion I want?
The following picture may be helpful.
In short, only the base version file is stored statically, all the other versions are dynamically generated with base file and necessary change sets.
right?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
来自 Subversion 设计文档：
重要的一点是，最新版本是基础版本，（反向）差异是从该版本向后存储的。
http://svn.apache .org/repos/asf/subversion/trunk/notes/subversion-design.html#server.fs.struct
您还可以查看该链接以了解提交如何存储在存储库中。
From Subversion Design doc:
Important point is that, the latest revision is the base and (reverse) diffs are stored from that backwards.
http://svn.apache.org/repos/asf/subversion/trunk/notes/subversion-design.html#server.fs.struct
You can also look at the link to see how the commit gets stored in the repository.
有很多关于 Subversion 如何存储其文件的文档，但事实是您确实不应该知道。否则，您可能会想在存储库管理员背后进行这些更改。
存储库后端的结构是一个热点问题。一些团体表示，这应该被充分记录并充分理解，以防出现问题，并且用户可以修复它们。其他人则表示，永远不应该触及该结构，最大的问题通常来自于最终用户，他们认为自己知道自己在做什么，搞乱了存储库，并毁掉了一切。
Subversion 存储库实际上有两种格式。其中一种使用 FSFS 文件格式（现在大多数人使用的格式），但最初 Subversion 使用 Berkeley DB (BDB) 来存储文件。 （它仍然可以，但您现在必须指定它）。未来，Subversion 可能会改用 SQLite 或 MySQL 作为其存储库后端。
这将允许 Subversion 开发人员将执行代码从存储库结构中分离出来。这将使添加新功能变得非常容易。例如，有很多人要求废除命令。不幸的是，据 Subversion 开发人员告诉我，在当前的 FSFS 文件结构中根本不可能做到这一点。基于 SQL 的存储库会使这变得更加容易。
There is a lot of documentation about how Subversion stores its files, but the truth is that you really shouldn't know. Otherwise, you might be tempted to make these changes behind the repository manager's back.
The structure of the repository backend is a hot issue. Some groups say that this should be well documented and well understood in case there are problems, and the user can fix them. Others say that the structure should never be touched, and that the biggest issues usually arise from end users who think they know what they're doing, muck up the repository, and destroy everything.
Subversion repositories actually have two formats. One uses the FSFS file format (what most people use now), but originally, Subversion used Berkeley DB (BDB) for storing files. (It still can, but you now must specify it). In the future, Subversion will probably switch to SQLite or MySQL as its repository backend.
This will allow the Subversion developers to separate out the execution code from the repository structure. This will make adding new features much, much easier to do. For example, there has been a lot of hue and cry for an obliterate command. Unfortunately, from what Subversion developers have told me, it's simply impossible to do within the current FSFS file structure. A SQL based repository would have made this much easier.
首先，您无法在 Subversion 中检出单个文件。您可以签出的最小部分是目录，但这不会改变任何内容。
有关 SVN 如何工作以及如何存储内容的最佳文档可以阅读 此处。
First you can't checkout a single file in Subversion. The smallest part you can checkout is a directory, but that will not change anything.
The best documentation about how SVN works and how things are stored can be read here.