When the commit process finds a representation in the rep-cache the only sanity check that happens is that the revision must be less than or equal to HEAD. We don't check that the offset is valid:
echo foo > foo svnadmin create repo svn import -mm foo file://`pwd`/repo/A/f sqlite3 repo/db/rep-cache.db "update rep_cache set offset = 4" svn import -mm foo file://`pwd`/repo/A/g or that the checksum at that offset matches: echo foo > foo echo bar > bar svnadmin create repo svn import -mm foo file://`pwd`/repo/A/f sqlite3 repo/db/rep-cache.db "update rep_cache set hash='e242ed3bffccdf271b7fbaf34ed72d089537b42f'" svn import -mm bar file://`pwd`/repo/A/g In both cases corruption in the rep-cache leads to corruption in the revision files but that corruption is not detected by commit process even though subsequent checkouts will fail. Should we do more sanity checking? We are using rep-cache to discard data supplied by the client on the basis that it is already present in the repository. Should we check that the offset really is a representation with the expected checksum? A side issue: "svnadmin verify" doesn't detect the corruption in the second case even though checkout will fail. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
