通过哈希查找svn内容

时间:2011-09-27 19:15:49

标签: git svn hash path

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

  • 存储库路径
  • 修订号

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

但是,我想知道是否可以通过哈希访问svn路径+修订对,就像Git一样。是否有一种机制已经内置到svn中?

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

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


修改:这几乎是同一个问题,但尚无定论:SVN: translation between path and node ids?

1 个答案:

答案 0 :(得分:3)

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

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

另一方面,Git存储文件,因此找到比文件名更好的文件ID是有意义的(对于文件的多个修订版可能保持相同),因此Git使用文件内容的散列。面向文件,使用其id(哈希)拉取文件并不罕见。

不幸的是,没有相当于通过散列拉动文件系统,因为散列的输入必须基于inode基础上每个版本的inode的内容。这意味着一种散列树内容的方法,这是可能的。这样的系统可以快速访问inode的特定历史版本。

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