On 06/15/2010 10:51 PM, Julian Foad wrote:
> Hi devs. Going through the 1.6.x. STATUS file, I am finding some items
> that could do with a better description or justification to make it
> easier to evaluate them. Can anyone provide information on the
> following:
>
>
>
>> * r934599, r934603
>> Fix a concurrency issue in the FSFS rep-cache code. This indirectly
>> concerns issue #3506.
>> Justification:
>> Opening the DB twice (and overwriting the handle) is undesired.
>>
> Why is that undesired? I mean that as a serious practical question -
> obviously it's theoretically redundant but that in itself doesn't
> necessarily matter. What is the user-visible effect of the problem, and
> of the proposed change?
>
>
>> Notes:
>> r934599 updates the svn_atomic__init_once() interface.
>> r934603 is the actual fix.
>> Notes:
>> Depends on the r879966 group, which does not merge cleanly.
>> Branch:
>> ^/subversion/branches/1.6.x-issue3506-init_once
>> (based on ^/subversion/branches/1.6.x-issue3506)
>> Votes:
>> +1: danielsh
>>
>
>
>> * r878590, r878607, r878625, r878626, r878627
>> In trunk we optimized the common case of 'find-and-replace with same uri'
>> of proxied content thanks to issue 3445 "WebDAV proxy code munging user
>> data".
>>
> What is the purpose and effect of the change proposed for back-port?
>
Today with 1.6.11 write through proxy would corrupt the commit if the
url of master and slave(actually path portions of the request) are
different.
We avoid this problem by configuring the the path portions to be the same.
Even if we avoid this we end up parsing the commit body stream to find
and replace the same string with same string(i.e s/\/svn/\/svn/g).
This particular block of fixes is about *avoiding* finding and replace
of same thing with same thing and hence provide better response time.
>
>> r878590 is just a change that adds FIXME marker to code comment. We take it
>> to avoid spurious conflicts with other revisions.
>> r878607 Special cases no-op find and replace.
>> "r878625, r878626, r878627" are follow-up to r878607 and the other long
>> pending Master info leak to the clients.
>> Justification:
>> 1. This group has the most common 'optimization' fix of *not* groking the
>> proxied response to find and replace with same string.
>> 2. Fixes the master information leak via the Location header.
>> 3. Need this to be ported for the other defect to be ported
>> without conflict.
>> Votes:
>> +1: kameshj, cmpilato
>> -0: julianfoad (seem to be multiple changes here for different reasons -
>> at least issue '3445 and an optimization and an information leak;
>> r878607 log msg says it fixes bugs but it's not clear what bugs;
>> don't know how to tell whether justification 1 is significant;
>> justifications don't seem to refer to issue #3445. Please can we
>> separate these changes and clearly describe each one? And update
>> the r878607 log msg.)
>>
> Ah, I already put my concerns here.
>
>
>
>> * r916286, r917512
>> ???
>>
> What is the purpose and effect of the change proposed for back-port?
>
> (It was me who added the question marks, some time ago.)
>
Hope I made it clear now in the STATUS file in my recent commit.
>
>> Notes:
>> This backport depends on the r878590 group only for the conflict free port.
>> Justification:
>> Vague commit error when server has been configured with<Location /svn/>
>> and write through proxy.
>>
> How bad is the old error message? How much better is the new one? An
> example might help. Does the change have any other effect?
>
>
Hope I made it clear now in the STATUS file in my recent commit.
>> Votes:
>> +1: kameshj
>>
>
>
>> * r917523
>> ???
>>
> Ditto.
>
>
Hope I made it clear now in the STATUS file in my recent commit.
>> Notes:
>> This backport depends on the r878590 and r916286 groups only for the
>> conflict free port.
>> Justification:
>> If the configured slave url has the *encodable* characters *write through*
>> is not happening rather commit happens in slave itself.
>>
> Commit happens in the slave? That's certainly and obviously wrong. But
> I don't understand what you mean by "the configured slave url has the
> *encodable* characters".
>
Hope I made it clear now in the STATUS file in my recent commit.
With regards
Kamesh Jayachandran
Received on 2010-06-16 17:39:10 CEST