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

Re: [RFC] Inheritable Properties

From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 27 Feb 2012 18:20:15 -0500

On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej <brane_at_apache.org> wrote:
> On 16.02.2012 16:46, C. Michael Pilato wrote:
>> On 02/16/2012 05:50 AM, Branko Čibej wrote:
>>> On 15.02.2012 21:18, Greg Stein wrote:
>>>> And thinking on that: how does the client do inheritance in a
>>>> mixed-revision working copy? D_at_10 inherits props from P, but the
>>>> client has P_at_5. If there are changes in P_at_7, then the inherited
>>>> properties a likely wrong for D_at_10.
>>> Reading this thread really makes me wonder a bit... How can anyone even
>>> contemplate implementing inheritable properties on the client side? A
>>> server-side implementation of (strictly versioned!) inheritable props
>>> would not require any new logic on the client, and it's the only way to
>>> make such a thing work without expecting weird behaviour with different
>>> client versions. I'd have thought that the mergeinfo saga would have
>>> been enough of a reality check.
>>>
>>> Regarding upwards searches and "bounded reads" ... anyone who believes
>>> reading a datastore is cheap should try to write a fast, data-intensive
>>> GAE application. :)
>>>
>>> IOW, I completely agree with Bill Tutt's assesment and Greg's arguments.
>>> Please try to understand the issues before assuming things.
>> Perhaps if those boasting of said understanding would invest the energy to
>> take this conversation a bit farther than merely "that won't work", and
>> maybe explore the "but this might..." space a little more deeply and
>> publicly, the ambient level of understanding all 'round would increase, and
>> gosh, we might even see some real progress on this feature.
>
> Hasn't it all been spelled out yet? We know that (a) lookups are
> expensive, (b) tree walks are expensive, (c) RPCs are expensive.
> Therefore, any design should try to minimize all three. I already posted
> a suggestion about how to speed up lookups by reducing the number of
> tree walks; and if we follow that design and the hint about ACL
> inheritance in NTFS (namely, populate the subutree with explicit values
> or at least single-indirection pointers to explicit values instead of
> calculating the inheritance tree at every lookup), we'll also reduce the
> number of datastore accesses (~~ RPCs ~~ I/O operations), thus reducing
> the cost of /every/ FS implementation.

Hi Brane,

So it's safe to say that barring a redesign of the backends you
believe that inheritable properties are a non-starter? This wouldn't
be something I could tempt you to assist with is it?

Paul

> So I shot my mouth off a bit but we've known for /years/ where the
> bottlenecks are in the FS design -- as exemplifed by the fact that we
> dared not turn on directory deltification until recently because it
> hosed performance. As Greg points out, caching is just papering over
> poor design. The current design is what it is for lots of reasons, so
> I'm not pointing fingers here; but there's nothing wrong with
> recognizing its faults and fixing them.
>
> -- Brane
Received on 2012-02-28 00:20:49 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.