You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Elias Wulcan <El...@apptus.com> on 2014/09/23 09:35:23 UTC
log-report with conflicting revision range and limit
Hello,
I'm trying to figure out why a client is extremely slow fetching subversion history. Here's an excerpt from its TCP traffic with the repository.
REPORT /products/ecom/!svn/bc/16411/x/branches/z HTTP/1.1
Host: a.b.local
Authorization: Basic XXXXXXXXX
User-Agent: SVN/1.8.10 (x64-microsoft-windows) serf/1.3.7
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked
151
<S:log-report xmlns:S="svn:"><S:start-revision>16411</S:start-revision><S:end-revision>1</S:end-revision><S:limit>12</S:limit><S:discover-changed-paths></S:discover-changed-paths><S:include-merged-revisions></S:include-merged-revisions><S:revprop>svn:author</S:revprop><S:revprop>svn:date</S:revprop><S:revprop>svn:log</S:revprop><S:path
48
></S:path><S:encode-binary-props></S:encode-binary-props></S:log-report>
0
Even though there is an S:limit element in the request the repository responds with what seems like an endless stream of S:log-item elements. Is the use of S:limit combined with a much larger revision range through S:start-revision end S:end-revision allowed? Is it something else in the request that I am missing that causes the limit to be broken? Is the client misbehaving? Is the server misbehaving?
Best Regards
Elias Elmqvist Wulcan
Re: log-report with conflicting revision range and limit
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> The most interesting tag in here is
> '><S:include-merged-revisions></S:include-merged-revisions>'
>
> The limit and range are applied on the revisions retrieved, and then
> *all merged revisions* are included. In some cases this can be a very
> large range of merged revisions.
In addition the server is 1.6.11 and that doesn't have the issue 3650
fixes in later 1.6.x to reduce excessive duplicate output.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
RE: log-report with conflicting revision range and limit
Posted by Elias Wulcan <El...@apptus.com>.
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
>
> The most interesting tag in here is '><S:include-merged-revisions></S:include-merged-revisions>'
>
> The limit and range are applied on the revisions retrieved, and then *all merged revisions* are included. In some cases this can be a very large range of merged revisions.
>
> Bert
Thank you very much!
RE: log-report with conflicting revision range and limit
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: dinsdag 23 september 2014 10:04
> To: Elias Wulcan
> Cc: users@subversion.apache.org
> Subject: Re: log-report with conflicting revision range and limit
>
> On Tue, Sep 23, 2014 at 9:35 AM, Elias Wulcan <El...@apptus.com>
> wrote:
> > Hello,
> >
> >
> >
> > I’m trying to figure out why a client is extremely slow fetching subversion
> > history. Here’s an excerpt from its TCP traffic with the repository.
> >
> >
> >
> > REPORT /products/ecom/!svn/bc/16411/x/branches/z HTTP/1.1
> >
> > Host: a.b.local
> >
> > Authorization: Basic XXXXXXXXX
> >
> > User-Agent: SVN/1.8.10 (x64-microsoft-windows) serf/1.3.7
> >
> > Content-Type: text/xml
> >
> > Accept-Encoding: gzip
> >
> > DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
> >
> > DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
> >
> > DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
> >
> > Transfer-Encoding: chunked
> >
> >
> >
> > 151
> >
> > <S:log-report
> > xmlns:S="svn:"><S:start-revision>16411</S:start-revision><S:end-
> revision>1</S:end-revision><S:limit>12</S:limit><S:discover-changed-
> paths></S:discover-changed-paths><S:include-merged-
> revisions></S:include-merged-
> revisions><S:revprop>svn:author</S:revprop><S:revprop>svn:date</S:revp
> rop><S:revprop>svn:log</S:revprop><S:path
> >
> > 48
The most interesting tag in here is '><S:include-merged-revisions></S:include-merged-revisions>'
The limit and range are applied on the revisions retrieved, and then *all merged revisions* are included. In some cases this can be a very large range of merged revisions.
Bert
Re: log-report with conflicting revision range and limit
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Sep 23, 2014 at 11:05 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Stefan Sperling <st...@elego.de> writes:
>
>> Support for limiting log requests in mod_dav_svn was
>> introduced 10 years ago (r851229).
>
> Yes, mod_dav_svn 1.1.x has the reported behaviour: the server does not
> support limit and sends the whole log, the client restricts the output.
>
There was also this recent issue, related to get-location-segments:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201312.mbox/%3C871u1bmnbi.fsf@ntlworld.com%3E
http://subversion.tigris.org/issues/show_bug.cgi?id=4458
This was fixed in 1.8.8 client, so that's not the issue here.
--
Johan
Re: log-report with conflicting revision range and limit
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> Support for limiting log requests in mod_dav_svn was
> introduced 10 years ago (r851229).
Yes, mod_dav_svn 1.1.x has the reported behaviour: the server does not
support limit and sends the whole log, the client restricts the output.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: log-report with conflicting revision range and limit
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Sep 23, 2014 at 5:23 AM, Elias Wulcan <El...@apptus.com> wrote:
> On Tue, Sep 23, 2014 at 10:12AM +0200, Stefan Sperling wrote:
>> On Tue, Sep 23, 2014 at 10:03:30AM +0200, Johan Corveleyn wrote:
>> > What server version?
>>
>> I'd like to know that bit of information, too.
>
> The repository is running mod_dav_svn 1.6.11
Time to update, for more reasons than this thread can gracefully cover.
RE: log-report with conflicting revision range and limit
Posted by Elias Wulcan <El...@apptus.com>.
On Tue, Sep 23, 2014 at 10:12AM +0200, Stefan Sperling wrote:
> On Tue, Sep 23, 2014 at 10:03:30AM +0200, Johan Corveleyn wrote:
> > What server version?
>
> I'd like to know that bit of information, too.
The repository is running mod_dav_svn 1.6.11
Re: log-report with conflicting revision range and limit
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 23, 2014 at 10:03:30AM +0200, Johan Corveleyn wrote:
> > Even though there is an S:limit element in the request the repository
> > responds with what seems like an endless stream of S:log-item elements. Is
> > the use of S:limit combined with a much larger revision range through
> > S:start-revision end S:end-revision allowed? Is it something else in the
> > request that I am missing that causes the limit to be broken? Is the client
> > misbehaving? Is the server misbehaving?
> >
>
> What server version?
I'd like to know that bit of information, too.
> Older server versions do not have support for 'limit'-ed log requests
> (I think it was introduced in server version 1.5). So if a client
> talks to an older server, the server will send everything, and the
> client filters it out on the client side.
Support for limiting log requests in mod_dav_svn was
introduced 10 years ago (r851229).
Perhaps you were thinking of --depth? That doesn't apply to log, however.
Re: log-report with conflicting revision range and limit
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Sep 23, 2014 at 9:35 AM, Elias Wulcan <El...@apptus.com> wrote:
> Hello,
>
>
>
> I’m trying to figure out why a client is extremely slow fetching subversion
> history. Here’s an excerpt from its TCP traffic with the repository.
>
>
>
> REPORT /products/ecom/!svn/bc/16411/x/branches/z HTTP/1.1
>
> Host: a.b.local
>
> Authorization: Basic XXXXXXXXX
>
> User-Agent: SVN/1.8.10 (x64-microsoft-windows) serf/1.3.7
>
> Content-Type: text/xml
>
> Accept-Encoding: gzip
>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
>
> Transfer-Encoding: chunked
>
>
>
> 151
>
> <S:log-report
> xmlns:S="svn:"><S:start-revision>16411</S:start-revision><S:end-revision>1</S:end-revision><S:limit>12</S:limit><S:discover-changed-paths></S:discover-changed-paths><S:include-merged-revisions></S:include-merged-revisions><S:revprop>svn:author</S:revprop><S:revprop>svn:date</S:revprop><S:revprop>svn:log</S:revprop><S:path
>
> 48
>
>></S:path><S:encode-binary-props></S:encode-binary-props></S:log-report>
>
> 0
>
>
>
>
>
> Even though there is an S:limit element in the request the repository
> responds with what seems like an endless stream of S:log-item elements. Is
> the use of S:limit combined with a much larger revision range through
> S:start-revision end S:end-revision allowed? Is it something else in the
> request that I am missing that causes the limit to be broken? Is the client
> misbehaving? Is the server misbehaving?
>
What server version?
Older server versions do not have support for 'limit'-ed log requests
(I think it was introduced in server version 1.5). So if a client
talks to an older server, the server will send everything, and the
client filters it out on the client side.
--
Johan