(replying just to the /trunk issue for now; haven't digested the remainder of your mails yet)
Stefan Fuhrmann wrote on Mon, Nov 22, 2010 at 02:23:49 +0100: > On 31.10.2010 16:09, Daniel Shahaf wrote: >> stef...@apache.org wrote on Sun, Oct 31, 2010 at 13:40:12 -0000: >>> URL: http://svn.apache.org/viewvc?rev=1029340&view=rev >>> Log: >>> Fix handling of cached revision root IDs. Issue discussed here: >>> http://svn.haxx.se/dev/archive-2010-10/0497.shtml >>> >>> The /trunk code caches them for a single session (i.e. server >>> request) only and assumes that the respective revision files >>> won't get packed while the request is being processed. >>> >> In other words, if there is a long-running request, and packing is run while >> the >> request is in progress, there is a window where that request will >> mis-compute the offsets? >> > Basically, during long-running requests, no files in the respective > repository must get packed. For instance, svn_fs_fs__path_rev_absolute > may return the non-packed path to open_pack_or_rev_file but shortly > thereafter, that might no longer be valid and open_pack_or_rev_file > would fail (on trunk). > Well, let's fix the bug on trunk then. If I remember correctly, you fixed it on the branch already, and the fix for trunk involved moving the retry code from svn_fs_fs__path_rev_absolute() to open_pack_or_rev_file()? > According to my understanding, there will be a file lock that prevents > a pack as long as the request is running. See svn_fs_fs__with_write_lock(). It's used by commit finalizations, revprop edits, and pack operations (non-exhaustive list). That lock is not used by readers (in fact, readers are never blocked on any lock); therefore, a pack might run at the same time as a read-only request (say, 'svn log'). The whole "If rev file is EEXIST, let's retry using the pack file" dance is to to make that 'svn log' succeed nonetheless.
