[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: Branko Čibej <brane_at_apache.org>
Date: Tue, 28 Feb 2012 00:33:05 +0100

On 28.02.2012 00:20, Paul Burba wrote:
> 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?

I merely agree that true inheritance, as opposed to faked-on-write
inheritance, is going to be a problem any way you look at it. And it's
not a complete redesign of the backends, "just" the representation of
directories, that would improve not only inherited properties but solve
quite a few performance (and size) issues, IMO.

> This wouldn't
> be something I could tempt you to assist with is it?

I'm afraid temptation isn't the issue ... lack of time is. Besides, my
boss reads this list and it'd look funny if I produced more code here
than at $JOB. :-P

-- Brane
Received on 2012-02-28 00:33:14 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.