Myria <myriac...@gmail.com> writes: > I just found out that the file causing the error from the large commit > is not the large file - it's one of the smaller files, about 55 KB. > If I commit that single smaller file from the large commit, it errors > the same way as the original 227185 would. This is exactly like the > original problem with committing the pixel shader.
If I understand correctly you are committing a single file using a file:// URL and getting the error. If so then you may be able to produce a much smaller testcase, see later. > I managed to get the db/transactions/227184-4vb2.txn directory by > breakpointing kernel32!DeleteFileW in TortoiseSVN (so I could get the > contents before TortoiseSVN deleted them at failure). I don't know > how they're useful, though. > > The only way I know how to proceed is to wait until the source code to > TortoiseSVN is available so that I can debug it in Visual Studio. Is > there something else I can do? Are you able to share your repository, either in public or privately with me? How big is the repository now it has fewer revisions? The file:// commit does not have any cache from previous commits, unlike svnsync or apache, so the error must involve data read explicitly during the failed commit. That means the ancestors of the file being committed, the parent directories, and possibly some other file (not an ancestor) referenced by SHA1 in the rep-cache. If you want to debug it yourself then as well as the transaction directory db/transactions/227184-4vb2.txn/ there is also the protorev file db/txn-protorevs/227184-4vb2.rev which contains the new content of the committed files. When the content is sent by the client it gets written as a delta to the txn-protorev file: DELTA SVN.... ENDREP Since the file being committed matched a SHA1 in the rep-cache the commit process will attempt to remove this delta but will first verify that the fulltext obtained by expanding the delta in the protorev file matches the fulltext in the repository, see get_shared_rep() in subversion/libsvn_fs_fs/transaction.c. /* Compare the two representations. * Note that the stream comparison might also produce MD5 checksum * errors or other failures in case of SHA1 collisions. */ SVN_ERR(svn_fs_fs__get_contents_from_file(&contents, fs, rep, file, offset, scratch_pool)); SVN_ERR(svn_fs_fs__get_contents(&old_contents, fs, &old_rep_norm, FALSE, scratch_pool)); err = svn_stream_contents_same2(&same, contents, old_contents, scratch_pool); Normally they compare equal and the protorev file is truncated to remove the delta, but in your case they do not match and the commit fails. As far as producing a smaller testcase: it may be possible to trim out all the files and directories in other parts of the repository. For example if the repository path to the parent directory of the commit is /project/branch/foo/bar then you can use svndumpfilter include /project/branch/foo/bar in an svnadmin dump ... | svndumpfilter ... | svnadmin load pipeline to produce a smaller repository and this smaller repository may reproduce the error. Dump and load tend to go faster with a larger than default -M parameter. There are some reasons why this may not work: - it may be necessary to expand the included tree to cope with copies. - the rep-cache might refer to a totally different file that happens to have the same SHA1/content, in which case the included tree may need to include this file as well. - the reduced repository will have the same files but the directories will be different/smaller and their content may be necessary to trigger the bug - the reduced repository will contain less data meaning smaller file offsets and the larger offsets may be necessary to trigger the bug To determine whether the rep-cache SHA1 refers to a different file you first need the repository form of the file being committed, i.e. with svn:keywords and svn:eol-style detranslated. Then calculate the SHA1 and lookup the hash in the rep-cache: sqlite3 db/rep-cache.db "select revision from rep_cache where hash='xxxxxxx'" This tells you which revision is involved, then you look in the revision file db/revs/nnn/nnnnn to find the hash and determine the file path. Thank you for persisting with the investigation! -- Philip