內容使用的兩條信息都是唯一標識：通過哈希查找SVN內容在SVN倉庫
我正在尋找一種方法來恢復該信息來自固定長度的消息（比如8或16字節）。僅通過存儲版本號來從我們的固定長度消息中識別存儲庫中的內容是不夠的。路徑是可變長度的，並且不適合消息。
不過，我在想，如果SVN路徑+修訂對可以通過哈希來訪問，如Git是如何做的。有沒有一種機制已經內置到svn中？
就足夠如果單獨的路徑是通過哈希訪問，然後我可以在固定長度的消息獨立存儲的版本號。
我將不得不保持使用的路徑和他們的哈希外部數據庫，還是SVN提供了一個快速的方式列出跨越，我可以點播查詢所有修訂現存的所有路徑？
編輯：這幾乎是同樣的問題，但尚無定論：SVN: translation between path and node ids?
SVN沒有存儲文件，它存儲的文件系統。因此，修訂版用於訪問文件系統的正確修訂版，然後使用部分路徑訪問相關文件。
內部SVN版本的inode，用自己各自的節點ID。但是，這種「直接訪問inode」的訪問通常是不受支持的，因爲inode缺乏通常必需的某些信息（如文件名，所有者，組，權限等）。另一方面，Git存儲文件，因此找到比文件名更好的文件id（對於文件的多個修訂可能保持不變），所以Git使用文件內容的散列。以文件爲導向，使用其id（哈希）來拉文件並不罕見。
不幸的是，有沒有通過哈希拉文件系統的等效，因爲散列的投入就必須根據inode的內容在每個版本的inode的基礎。這意味着一種散列樹內容的方式，這是可能的。這樣的系統將提供對特定歷史版本的inode的快速訪問。
也許它沒有這樣做這種方式的主要原因是，該inode的快速客戶端訪問是沒有多少SVN關心的。 SVN服務器已經具有指針和數據結構來訪問服務器端的inode，並且它具有客戶端傳輸的遠程存儲庫文件系統的知識。這允許SVN將文件系統中的差異傳輸到客戶端（而不是文件系統的完整副本）。如果不需要一致地提取完整的文件系統，快速路徑訪問完整的文件系統並不是優先考慮的事情。