[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: Tue, 7 Feb 2012 02:20:11 +0200

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.

- 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?

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

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

  [[[
  % $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.)

- INHERITABLE_PROPS schema

  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?

And two minor points:

- "A target with no explicit mergeinfo might still inherit a property
  from a parent:"

  How does mergeinfo factor in? (Typo?)

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

Cheers,

Daniel
Received on 2012-02-07 01:21:11 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.