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

Re: Fwd: Effects of importing over 18000 items into repository as one commit transaction

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-01-11 16:48:36 CET

On 1/11/06, Julian Foad <julianfoad@btopenworld.com> wrote:

> That document mentions the problem of O(N) behaviour for copy operations, in
> section 3 of each "chapter". It doesn't mention such a problem for any other
> situation. Do you want to patch it to warn of O(N) behaviour in other or all
> cases?

I'm talking about the section on revision properties:


   Users are allowed to attach arbitrary, unversioned properties to
   revisions. Additionally, most revisions also have "standard"
   revision props (revprops), such as svn:author, svn:date, and
   svn:log. Access to revprops may be restricted, based on
   readability of changed-paths.

     * If a revision contains nothing but unreadable changed-paths,
       then all revprops are unreadable and unwritable.

     * If a revision has a mixture of readable/unreadable
       changed-paths, then all revprops are unreadable, except for
       svn:author and svn:date. All revprops are unwritable.

The problem here is that 'svn log' is all about fetching revprops:
author, date, log message.

In order to decide which revprops are okay to display, all of the
changed-paths in a given revision have to be examined. This isn't
something that can be optimized away with clever uses of trees,
red-black elimination, etc. What must be determined is whether

    * all the changed-paths are readable
    * some of the changed-paths are readable
    * none of the changed-paths are readable.

And that's just an O(N) search (where N == number of changed-paths in
the revision), no matter what you do. There's nothing predictable
about the changed-path list. If one of the changed-paths just happens
to be a child of another, it's still not useful to us; we can't make
any assumptions about the ACLs set up by the server process, or
whether there's inheritance or not. Our authz_read() callback
operates on single paths, and that's it.

So yeah, this is a case where security trades off for performance.
The tradeoff can be reversed by disabling path-based authorization
features completely. I don't see any other options...

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 11 16:51:02 2006

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.