You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Fuhrmann <st...@alice-dsl.de> on 2011/02/10 02:25:14 UTC
Integrating further changes from the performance branch
Hi there,
Those among you following the commits will have noticed
that I opened 5 new branches each containing a cherry-
picked patch set from the performance branch (details below).
These branches can be merged independent of each other and
an integration branch will be merged to /trunk on the 19th
or 20th if
* there was no feedback to it at all (= silent acceptance), or
* it received positive feedback (= +1 on merge), or
* issues found have been resolved
So, an easy way to prevent a particular branch to be merged
is a simple "needs more discussion / review" post.
-- Stefan^2.
List of integration branches:
-----------------------------
integrate-string-improvement
- relatively simple change that mainly speeds up ra_svn clients
integrate-compression-level
- new, independent feature that allows ra_svn to saturate
1Gb network connections and reduces CPU load on the server
integrate-io-improvements
- changes were already discussed when svn_io_file_read_full2()
got introduced on the performance branch
integrate-stream-api-extensions
- straight-forward extension to the svn_stream_t API
- code not used right now
- is required for efficient stream_readline implementation
(would be a follow-up merge)
integrate-cache-item-serialization
- certainly the most critical change as it affects all items
currently cache-able in FSFS
- affects FSFS only
- prerequisite to O(N) instead of O(N^2) directory handling
(would be a follow-up merge)
- prerequisite to delta caching speeding up 'verify' and 'dump'
(would be a follow-up merge)
Re: Integrating further changes from the performance branch
Posted by Stefan Fuhrmann <eq...@web.de>.
On 11.02.2011 11:10, Ivan Zhakov wrote:
> On Fri, Feb 11, 2011 at 03:51, Stefan Fuhrmann<eq...@web.de> wrote:
>> On 10.02.2011 22:15, Ivan Zhakov wrote:
>>> On Thu, Feb 10, 2011 at 03:25, Stefan Fuhrmann
>>> <st...@alice-dsl.de> wrote:
>>>> Hi there,
>>>>
>>>> Those among you following the commits will have noticed
>>>> that I opened 5 new branches each containing a cherry-
>>>> picked patch set from the performance branch (details below).
>>>>
>>>> These branches can be merged independent of each other and
>>>> an integration branch will be merged to /trunk on the 19th
>>>> or 20th if
>>>>
>>>> * there was no feedback to it at all (= silent acceptance), or
>>>> * it received positive feedback (= +1 on merge), or
>>>> * issues found have been resolved
>>>>
>>>> So, an easy way to prevent a particular branch to be merged
>>>> is a simple "needs more discussion / review" post.
>>> I reviewed some of branches. See my comments below.
>>>
>> Thank you very much!
>>>> -- Stefan^2.
>>>>
>>>>
>>>> List of integration branches:
>>>> -----------------------------
>>>>
>>>> integrate-string-improvement
>>>> - relatively simple change that mainly speeds up ra_svn clients
>>> This branch merges with many conflicts. And after it seems to merge
>>> changes to zlib code...
>> That is weird. It should be just one version changing 3
>> files (none of which is a zlib change -- only reducing
>> the string copying overhead when de-compressing using zlib).
>>
>> It merges just fine against HEAD -- for me at least using
>> near-head SVN as well as 1.5.4. Maybe, it fails for 1.6.x
>> as per http://subversion.tigris.org/issues/show_bug.cgi?id=3657.
>>
> I've tried again and still get text-conflicts when merging using
> Subversion 1.6.15:
>> svn merge --reintegrate "^/subversion/branches/integrate-string-improvements" --non-interactive
> --- Merging differences between repository URLs into '.':
> U subversion\libsvn_subr\svn_string.c
> CU subversion\include\svn_string.h
> U subversion\libsvn_delta\svndiff.c
> U .
> Summary of conflicts:
> Text conflicts: 1
>
I decided to not merge the change for 1.7.
It is a client-side optimization that will only
become relevant once you go beyond 1Gb
network connections.
If someone would show up and do a review
of the patch, I may change my decision.
-- Stefan^2.
Re: Integrating further changes from the performance branch
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Feb 11, 2011 at 11:10 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Fri, Feb 11, 2011 at 03:51, Stefan Fuhrmann <eq...@web.de> wrote:
>> On 10.02.2011 22:15, Ivan Zhakov wrote:
>>>
>>> On Thu, Feb 10, 2011 at 03:25, Stefan Fuhrmann
>>> <st...@alice-dsl.de> wrote:
>>>>
>>>> Hi there,
>>>>
>>>> Those among you following the commits will have noticed
>>>> that I opened 5 new branches each containing a cherry-
>>>> picked patch set from the performance branch (details below).
>>>>
>>>> These branches can be merged independent of each other and
>>>> an integration branch will be merged to /trunk on the 19th
>>>> or 20th if
>>>>
>>>> * there was no feedback to it at all (= silent acceptance), or
>>>> * it received positive feedback (= +1 on merge), or
>>>> * issues found have been resolved
>>>>
>>>> So, an easy way to prevent a particular branch to be merged
>>>> is a simple "needs more discussion / review" post.
>>>
>>> I reviewed some of branches. See my comments below.
>>>
>> Thank you very much!
>>>>
>>>> -- Stefan^2.
>>>>
>>>>
>>>> List of integration branches:
>>>> -----------------------------
>>>>
>>>> integrate-string-improvement
>>>> - relatively simple change that mainly speeds up ra_svn clients
>>>
>>> This branch merges with many conflicts. And after it seems to merge
>>> changes to zlib code...
>>
>> That is weird. It should be just one version changing 3
>> files (none of which is a zlib change -- only reducing
>> the string copying overhead when de-compressing using zlib).
>>
>> It merges just fine against HEAD -- for me at least using
>> near-head SVN as well as 1.5.4. Maybe, it fails for 1.6.x
>> as per http://subversion.tigris.org/issues/show_bug.cgi?id=3657.
>>
> I've tried again and still get text-conflicts when merging using
> Subversion 1.6.15:
>> svn merge --reintegrate "^/subversion/branches/integrate-string-improvements" --non-interactive
> --- Merging differences between repository URLs into '.':
> U subversion\libsvn_subr\svn_string.c
> CU subversion\include\svn_string.h
> U subversion\libsvn_delta\svndiff.c
> U .
> Summary of conflicts:
> Text conflicts: 1
I tried this also yesterday, and got the same conflict with a 1.6
client. But it's a bogus text conflict, because of
http://subversion.tigris.org/issues/show_bug.cgi?id=3657. It happens
because there is both a text and a property modification (explicit
mergeinfo) on the same file. That bug is fixed on trunk. If you do the
reintegrate with a trunk client (in a 1.7 wc of course), there is no
conflict.
So AFAICS, there is no merge-conflict problem with this branch
(haven't reviewed the code though).
Cheers,
--
Johan
Re: Integrating further changes from the performance branch
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Feb 11, 2011 at 03:51, Stefan Fuhrmann <eq...@web.de> wrote:
> On 10.02.2011 22:15, Ivan Zhakov wrote:
>>
>> On Thu, Feb 10, 2011 at 03:25, Stefan Fuhrmann
>> <st...@alice-dsl.de> wrote:
>>>
>>> Hi there,
>>>
>>> Those among you following the commits will have noticed
>>> that I opened 5 new branches each containing a cherry-
>>> picked patch set from the performance branch (details below).
>>>
>>> These branches can be merged independent of each other and
>>> an integration branch will be merged to /trunk on the 19th
>>> or 20th if
>>>
>>> * there was no feedback to it at all (= silent acceptance), or
>>> * it received positive feedback (= +1 on merge), or
>>> * issues found have been resolved
>>>
>>> So, an easy way to prevent a particular branch to be merged
>>> is a simple "needs more discussion / review" post.
>>
>> I reviewed some of branches. See my comments below.
>>
> Thank you very much!
>>>
>>> -- Stefan^2.
>>>
>>>
>>> List of integration branches:
>>> -----------------------------
>>>
>>> integrate-string-improvement
>>> - relatively simple change that mainly speeds up ra_svn clients
>>
>> This branch merges with many conflicts. And after it seems to merge
>> changes to zlib code...
>
> That is weird. It should be just one version changing 3
> files (none of which is a zlib change -- only reducing
> the string copying overhead when de-compressing using zlib).
>
> It merges just fine against HEAD -- for me at least using
> near-head SVN as well as 1.5.4. Maybe, it fails for 1.6.x
> as per http://subversion.tigris.org/issues/show_bug.cgi?id=3657.
>
I've tried again and still get text-conflicts when merging using
Subversion 1.6.15:
> svn merge --reintegrate "^/subversion/branches/integrate-string-improvements" --non-interactive
--- Merging differences between repository URLs into '.':
U subversion\libsvn_subr\svn_string.c
CU subversion\include\svn_string.h
U subversion\libsvn_delta\svndiff.c
U .
Summary of conflicts:
Text conflicts: 1
>> - it would be great to have similar option to configure compression
>> level in mod_dav_svn for high-load servers used in local area
>> networks. Optionally we can add Apache environment variable to be able
>> configure compression level based on client IP address.
>
> I tried that a couple of days ago but I didn't change
> mod_dav_svn's behavior. I possibly did something wrong
> but maybe, the compression is not used for export /
> checkout the same way as it is used within svnserve.
>
> Therefore, I reverted the change. However, it should be
> a simple change (once it works) that can be done directly
> on /trunk. The setting will probably first be global.
>
Agreed, this can be implemented on trunk after merging your branch.
--
Ivan Zhakov
VisualSVN Team
Re: Integrating further changes from the performance branch
Posted by Stefan Fuhrmann <eq...@web.de>.
On 10.02.2011 22:15, Ivan Zhakov wrote:
> On Thu, Feb 10, 2011 at 03:25, Stefan Fuhrmann
> <st...@alice-dsl.de> wrote:
>> Hi there,
>>
>> Those among you following the commits will have noticed
>> that I opened 5 new branches each containing a cherry-
>> picked patch set from the performance branch (details below).
>>
>> These branches can be merged independent of each other and
>> an integration branch will be merged to /trunk on the 19th
>> or 20th if
>>
>> * there was no feedback to it at all (= silent acceptance), or
>> * it received positive feedback (= +1 on merge), or
>> * issues found have been resolved
>>
>> So, an easy way to prevent a particular branch to be merged
>> is a simple "needs more discussion / review" post.
> I reviewed some of branches. See my comments below.
>
Thank you very much!
>> -- Stefan^2.
>>
>>
>> List of integration branches:
>> -----------------------------
>>
>> integrate-string-improvement
>> - relatively simple change that mainly speeds up ra_svn clients
> This branch merges with many conflicts. And after it seems to merge
> changes to zlib code...
That is weird. It should be just one version changing 3
files (none of which is a zlib change -- only reducing
the string copying overhead when de-compressing using zlib).
It merges just fine against HEAD -- for me at least using
near-head SVN as well as 1.5.4. Maybe, it fails for 1.6.x
as per http://subversion.tigris.org/issues/show_bug.cgi?id=3657.
>> integrate-compression-level
>> - new, independent feature that allows ra_svn to saturate
>> 1Gb network connections and reduces CPU load on the server
> - cosmetics: invalid indentation of comment to function
> svn_txdelta_to_svndiff2() in file subversion/include/svn_delta.h
Keen eyes! Thanks for spotting that one.
Fixed in 1069655.
> - it would be great to have similar option to configure compression
> level in mod_dav_svn for high-load servers used in local area
> networks. Optionally we can add Apache environment variable to be able
> configure compression level based on client IP address.
I tried that a couple of days ago but I didn't change
mod_dav_svn's behavior. I possibly did something wrong
but maybe, the compression is not used for export /
checkout the same way as it is used within svnserve.
Therefore, I reverted the change. However, it should be
a simple change (once it works) that can be done directly
on /trunk. The setting will probably first be global.
>> integrate-io-improvements
>> - changes were already discussed when svn_io_file_read_full2()
>> got introduced on the performance branch
> Looks fine. I'm +1 to merge.
-- Stefan^2.
Re: Integrating further changes from the performance branch
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Feb 10, 2011 at 03:25, Stefan Fuhrmann
<st...@alice-dsl.de> wrote:
> Hi there,
>
> Those among you following the commits will have noticed
> that I opened 5 new branches each containing a cherry-
> picked patch set from the performance branch (details below).
>
> These branches can be merged independent of each other and
> an integration branch will be merged to /trunk on the 19th
> or 20th if
>
> * there was no feedback to it at all (= silent acceptance), or
> * it received positive feedback (= +1 on merge), or
> * issues found have been resolved
>
> So, an easy way to prevent a particular branch to be merged
> is a simple "needs more discussion / review" post.
I reviewed some of branches. See my comments below.
> -- Stefan^2.
>
>
> List of integration branches:
> -----------------------------
>
> integrate-string-improvement
> - relatively simple change that mainly speeds up ra_svn clients
>
This branch merges with many conflicts. And after it seems to merge
changes to zlib code...
> integrate-compression-level
> - new, independent feature that allows ra_svn to saturate
> 1Gb network connections and reduces CPU load on the server
- cosmetics: invalid indentation of comment to function
svn_txdelta_to_svndiff2() in file subversion/include/svn_delta.h
- it would be great to have similar option to configure compression
level in mod_dav_svn for high-load servers used in local area
networks. Optionally we can add Apache environment variable to be able
configure compression level based on client IP address.
> integrate-io-improvements
> - changes were already discussed when svn_io_file_read_full2()
> got introduced on the performance branch
Looks fine. I'm +1 to merge.
--
Ivan Zhakov