[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: Wed, 8 Feb 2012 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
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!

> - "# New reserved Subversion properties may be introduced that are
>  inheritable by definition, but such properties are not required to use
>  any special namespace, beyond the normal "svn:" prefix."
>  This implies a drawback: we add in 1.9 an svn:silver property and
>  declare it inheritable, then a 1.8 server won't recognize it as such.

Ah, true. We'll need to go back to the original plan to have a
separate namespace for Subversion reserved inheritable properties.

> - "# 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.

>  [[[
>  % $svn rm -q A
>  % $svn ci -q -m r2
>  % $svn mkdir -q A
>  % $svn ci -q -m r3
>  % $svn mkdir -q A/D
>  % $svn ci -q -m r4
>  % cd A
>  % $svn up -r1 D
>  Updating 'D':
>  D    D
>  A    D
>  A    D/gamma
>  ...
>  Updated to revision 1.
>  %
>  ]]]
> - "Whenever an update occurs the cache(s) will be refreshed."
>  Suppose svn:keywords were inheritable and an update changed the cached
>  svn:keywords value in the parent of the wcroot.  Would it be easy to
>  rewrite all files to the new keywords they now inherit?
>  (I'm using svn:keywords as an illustration/example.)
>  Not a wc-ng expert, but would having a CONSTRAINT to the effect of
>  "Any (LOCAL_RELPATH, OP_DEPTH) tuple that appears in INHERITABLE_PROPS
>  must also appear (as a tuple) in NODES" be better than two FOREIGN KEY
>  constraints?

Possibly yes, I'm not a wc-ng guru either, so feel ill-equipped to
judge the merits of either approach. I fully plan to harass some
wc-ng experts for help in this area, but not until we have more basic
questions settled.

> And two minor points:
> - "A target with no explicit mergeinfo might still inherit a property
>  from a parent:"
>  How does mergeinfo factor in?  (Typo?)

Fixed that, I meant "explicit inherited property".

> - Nitpick: svn_proplist_receiver2_t's docstring should use 'const char *'
>  for the types of hash keys.


> Cheers,
> Daniel
Received on 2012-02-08 23:09:30 CET

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