git - 通过哈希查找 svn 内容

Question

svn 存储库中的内容使用两条信息进行唯一标识:

• 存储库路径
• 修订号

我正在寻找一种方法来从固定长度的消息(比如 8 或 16 字节)中恢复该信息。仅通过存储修订号来从我们的固定长度消息中识别存储库中的内容是不够的。路径是可变长度的，无法放入消息中。

但是，我想知道 svn 路径+修订对是否可以通过散列访问，就像 Git 那样。 svn 中是否已经内置了这种机制？

如果单独的路径可以通过哈希访问就足够了，然后我可以将修订号独立地存储在固定长度的消息中。

我是否必须保留已用路径及其哈希值的外部数据库，或者 SVN 是否提供了一种快速方法来列出我可以按需查询的所有修订中的所有现存路径？

---

编辑:这实际上是同一个问题，但没有定论:SVN: translation between path and node ids?

Answer 1

SVN 不存储文件，它存储文件系统。因此，修订用于访问文件系统的正确修订，然后部分路径用于访问相关文件。

内部 SVN 修订 inode，具有各自的节点 ID。但是，通常不支持这种“直接到 inode”访问，因为 inode 缺少通常必需的某些信息(如文件名、所有者、组、权限等)。

另一方面，Git 存储文件，因此找到比文件名更好的文件 ID 是有意义的(文件的多个修订版可能保持相同)，因此 Git 使用文件内容的哈希值。作为面向文件的，使用文件的 id(散列)来提取文件并不少见。

不幸的是，没有通过散列提取文件系统的等价物，因为散列的输入必须基于每个版本的 inode 基础上的 inode 内容。这将意味着一种散列树内容的方法，这是可能的。这样的系统将提供对 inode 的特定历史版本的快速访问。

可能没有这样做的主要原因是客户端对 inode 的快速访问在 SVN 中并不是一个很重要的问题。 SVN 服务器已经有了访问服务器端 inode 的指针和数据结构，并且它知道客户端传输的远程存储库的文件系统。这允许 SVN 将文件系统中的差异传输到客户端(而不是文件系统的完整副本)。无需始终如一地 pull 完整文件系统，快速路径访问完整文件系统 pull 不是优先事项。