Re: svn commit: r10907 - branches/1.1.x

[kf...@collab.net]

lundblad@tigris.org writes:
> +Status of 1.1.1:
> +================
> +
> +Candidate changes:
> +
> +  * r10788, r10796, r10904
> +    Fix performance regression in character encoding translations.  Most
> +    noticable on Win32, but impacts other platforms as well.
> +    Justification:
> +      Slow "svn status" annoys people, especially TSVN users.
> +    Notes:
> +      Proposed during 1.1.0 preparation, but it is too late and complicated
> +      to put in 1.1.0 at this stage.
> +    Votes:
> +      +1: lundblad

Doesn't r10904 change an API by adding a pool (svn_utf_initialize)?

If so, then it can't happen in a patch release.  It could appear in
1.1.0 (since svn_utf_initialize itself is new in 1.1).  Or it could
appear in 1.2.0, but it would have to be named 'svn_utf_initialize2'.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r10907 - branches/1.1.x

[Max Bowsher <ma...@ukf.net>]

kfogel@collab.net wrote:
> "Max Bowsher" <ma...@ukf.net> writes:
>>> Doesn't r10904 change an API by adding a pool (svn_utf_initialize)?
>>>
>>> If so, then it can't happen in a patch release.
>>
>> That change is catching up with the new signature *already* in place
>> on the 1.1.x branch as of r10877.
>>
>> So, all is ok.
>
> Thanks.
>
> Is there some reason we did things in that order, instead of the more
> usual trunk-first order?

Once the function signature had been decided on, the 2 changes were 
essentially independent, to the point of being handled by different people! 
The branch change was the application of a patch from an issue, not the 
merge of a trunk revision.

The branch change was quite simple ( a placeholder ), whilst the trunk 
change was quite a bit more complex. Therefore they happened in the order 
they did.


Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r10907 - branches/1.1.x

[kf...@collab.net]

"Max Bowsher" <ma...@ukf.net> writes:
> > Doesn't r10904 change an API by adding a pool (svn_utf_initialize)?
> >
> > If so, then it can't happen in a patch release.
> 
> That change is catching up with the new signature *already* in place
> on the 1.1.x branch as of r10877.
> 
> So, all is ok.

Thanks.

Is there some reason we did things in that order, instead of the more
usual trunk-first order?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r10907 - branches/1.1.x

[Max Bowsher <ma...@ukf.net>]

kfogel@collab.net wrote:
> lundblad@tigris.org writes:
>> +Status of 1.1.1:
>> +================
>> +
>> +Candidate changes:
>> +
>> +  * r10788, r10796, r10904
>> +    Fix performance regression in character encoding translations.  Most
>> +    noticable on Win32, but impacts other platforms as well.
>> +    Justification:
>> +      Slow "svn status" annoys people, especially TSVN users.
>> +    Notes:
>> +      Proposed during 1.1.0 preparation, but it is too late and 
>> complicated
>> +      to put in 1.1.0 at this stage.
>> +    Votes:
>> +      +1: lundblad
>
> Doesn't r10904 change an API by adding a pool (svn_utf_initialize)?
>
> If so, then it can't happen in a patch release.

That change is catching up with the new signature *already* in place on the 
1.1.x branch as of r10877.

So, all is ok.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org