(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
>>> 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.
Received on 2010-11-22 20:21:32 CET