[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: Daniel Shahaf <danielsh_at_elego.de>
Date: Thu, 9 Feb 2012 00:22:15 +0200

[snipping the parts I concur with]

Paul Burba wrote on Wed, Feb 08, 2012 at 17:08:57 -0500:
> On Mon, Feb 6, 2012 at 7:20 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
> >> Hi All,
> >>
> >> There has long been a desire for Subversion to support some form of
> >> inherited properties.  Recently, while discussing a potential solution
> >> for server dictated configurations (see
> >> http://svn.haxx.se/dev/archive-2012-01/0032.shtml), the idea of using
> >> inheritable properties as an alternative approach was raised.  To that
> >> end I put together an inherited properties design wiki, see
> >> http://wiki.apache.org/subversion/InheritedProperties
> >>
> >> Many of you have already seen this wiki and weighed in on the server
> >> dictated config thread, but in the event you haven't please check it
> >
> > I'm in that camp --- the threads were too long for me so I only followed
> > them with one eye.  Now that you called this RFC I reviewed the wiki
> > proposal and made some comments below.
> >
> >> out.  I'd like to move this forward or return to the original server
> >> dictated config, so any questions, concerns, and/or suggestions are
> >> greatly appreciated.
> >>
> >> Thanks,
> >>
> >> Paul
> >
> > - There's no mention on the wiki of _how_ inherited properties can help
> >  with server-dictated config.  I realize it's probably somewhere in my
> >  mailbox, but a pointer would be useful.
>
> We've kicked around some ideas on the server dictated config thread
> (http://svn.haxx.se/dev/archive-2012-01/0405.shtml). I've avoided
> anything concrete mainly because if we can't agree on how to implement
> *generic* inheritable properties (which is what this proposal is
> about) then what's the point of describing a particular application?
> And that is what this proposal is about: Generic inheritable

Agreed; but I looked in ServerDictatedConfiguration too for an
inherited-props-based solution, and found none. Hence my question.

> properties. How to differentiate them from regular versioned
> properties, how to set them, and how to retrieve them.
>
> > - How does all this interact with 1.7-and-older clients?  For example,
> >  if svn:inheritable:foo is set on ^/trunk and a 1.7 client propgets
> >  this property on a descendant of ^/trunk that doesn't have that
> >  property set, I presume that client would be told that that property
> >  doesn't exist on the descendant?
>
> Correct. You'll need a 1.8+ client and server to get the full benefit.
> Not much different than merge tracking and svn:mergeinfo. If anybody
> has any suggestions as to how a 1.7 client could suddenly recognize
> inheritable properties, then I'm all ears!
>

First hunch: let's not open this rabbit hole. True, if someone does
just 'propget' then we could do a server-side emulation.. but if that
'propget' is part of someone's reimplementation of libsvn_wc, we should
probably not do any server-side overlays --- or trying to use that wc to
change those props will, most likely, not end in the user-intended
results.

> > - "# Unlike svn:mergeinfo and like tsvn:auto-props, inheritance across
> >  mixed-revision boundaries in the working copy is allowed."
> >
> >  Does this hold even if the nodes on either side of the mixed-revision
> >  boundary are not related?  Like, for example, A/ and A/D/ at the end
> >  of the following example? ---
>
> As the proposal is currently written, yes, it would hold. So yes, A/D
> in the WC below might inherit a different property value than ^/A/D_at_1.
> Is this ideal? Hardly. But is it a serious problem? I'm not sure
> it is. We can't commit any changes to A/D without updating. If we
> copy D it will inherit properties from its new parent regardless.
>

Fair points. But it still seems a bit odd for a node to inherit props
from a completely unrelated parent node.

But I think you and Julian have this can of worms wide open, so I'll
wait on the sidelines a bit on this issue.

>

Cheers,

Daniel
Received on 2012-02-08 23:22:58 CET

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