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

Re: mergeinfo API cleanup: questions

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 18 Feb 2008 12:56:27 -0600

David Glasser wrote:
> On Feb 18, 2008 10:38 AM, Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu> wrote:
>> Hyrum K. Wright wrote:
>>> David Glasser wrote:
>>> ...
>>>> * svn_rangelist_count_revs, svn_rangelist_to_revs, and
>>>> svn_range_compact are never used outside of the test suite. Do we
>>>> need them? I guess the first two might hypothetically be useful to
>>>> other clients. What about svn_range_compact?
>>> The first two were originally were part of 'log -g'. Their usefulness
>>> may return before I'm finished with 'log -g', so I would wait until that
>>> point to remove them.
>> I've moved svn_rangelist_to_revs() to be a private function in
>> libsvn_repos. It may still get cut, and I'd like to keep it out of the
>> public API. svn_rangelist_count_revs() can be safely removed.
> Cool.
> btw, Hyrum and I talked about this on IRC the other day, but: I'm a
> little worried that any codepath that uses svn_rangelist_to_revs (or
> the new private version) is a potential DOS risk. If somebody can
> check in a mergeinfo prop (or otherwise get svn_rangelist_to_revs
> applied a string) containing "1-1000000000", any call to that function
> will make the server slowly allocate a large amount of memory...

True. I'm in the middle of a new rangelist-based algorithm to replace
the need for rangelist_to_revs(), but if somebody else wants to take a
look at it sooner, I'd have no objections. The current implementation
is there because it was easier to conceptualize and implement, and so
that folks can test the functionality of 'log -g' while I work on the
rangelist-based approach.


Received on 2008-02-18 19:56:38 CET

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.