[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mod_dav_svn enhancement idea

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2005-05-08 18:31:01 CEST

John Belmonte wrote:
> Ben Collins-Sussman wrote:
>>On May 7, 2005, at 9:49 PM, Michael Sinz wrote:
>>>BTW - I really wish svn log --limit existed in the 1.1.x - it would
>>>be a life-saver for those larger repositories.
>>Not possible to backport to 1.1.x, because
>> * patch releases are bugfixes only, not for adding new features, and
>> * it involves an API change, which guarantees that it must be in a
>>minor release.
>>Those 'larger repositories' will just have to upgrade to svn 1.2 next
>>week. :-)
> Except that the current implementation of --limit in 1.2 doesn't seem to
> provide any better performance than doing a full log and filtering the
> result (see http://subversion.tigris.org/issues/show_bug.cgi?id=2290).
> This is a shame-- I would really like to use this for interfaces to log
> that are simple and efficient (e.g. dynamically generate the RSS feed of
> changes on a path by sending "svn log --limit 10 --xml TARGET" through
> an appropriate XSLT).

Well, it's not sending all the data over the wire (if you're talking to
a 1.2.x server anyway), but yes, it is doing more server-side work than
is truly needed in that it's still calling svn_repos_history2 with the
original revision range (i.e. 0:HEAD if no range is specified by the
user). This means it has to go through all the revisions to see if the
path in question was modified, which is kind of slow. This could be
changed to make multiple calls to svn_repos_history2, starting with more
recent ranges and moving backwards in time until you have enough to
satisfy the limit argument, but nobody has done that yet. It would be a
server-side change only, clients would still work fine, and it wouldn't
require any changes in APIs, so there's no reason this couldn't be in a
forthcoming 1.2.x release if someone got motivated enough to fix it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 18:32:20 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.