(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:
>> stefan2_at_apache.org wrote on Sun, Oct 31, 2010 at 13:40:12 -0000:
>>> URL: http://svn.apache.org/viewvc?rev=1029340&view=rev
>>> Fix handling of cached revision root IDs. Issue discussed here:
>>> 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
Received on 2010-11-22 20:21:32 CET