Return-Path: 
 <commits-return-23047-apmail-subversion-commits-archive=subversion.apache.org@subversion.apache.org>
X-Original-To: apmail-subversion-commits-archive@minotaur.apache.org
Delivered-To: apmail-subversion-commits-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 49546D5BA
	for <apmail-subversion-commits-archive@minotaur.apache.org>;
 Tue, 11 Sep 2012 14:37:54 +0000 (UTC)
Received: (qmail 70237 invoked by uid 500); 11 Sep 2012 14:37:54 -0000
Delivered-To: apmail-subversion-commits-archive@subversion.apache.org
Received: (qmail 70138 invoked by uid 500); 11 Sep 2012 14:37:54 -0000
Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@subversion.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@subversion.apache.org>
List-Post: <mailto:commits@subversion.apache.org>
List-Id: <commits.subversion.apache.org>
Reply-To: dev@subversion.apache.org
Delivered-To: mailing list commits@subversion.apache.org
Received: (qmail 70130 invoked by uid 99); 11 Sep 2012 14:37:54 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2012 14:37:54 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.131] (HELO eos.apache.org) (140.211.11.131)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2012 14:37:50 +0000
Received: from eos.apache.org (localhost [127.0.0.1])
	by eos.apache.org (Postfix) with ESMTP id 4598CDED
	for <commits@subversion.apache.org>; Tue, 11 Sep 2012 14:37:29 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache subversion Wiki <commits@subversion.apache.org>
To: Apache subversion Wiki <commits@subversion.apache.org>
Date: Tue, 11 Sep 2012 14:37:29 -0000
Message-ID: <20120911143729.6913.28334@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Trivial_Update_of_=22InheritedProperties?=
 =?utf-8?q?=22_by_pburba?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" fo=
r change notification.

The "InheritedProperties" page has been changed by pburba:
http://wiki.apache.org/subversion/InheritedProperties?action=3Ddiff&rev1=3D=
35&rev2=3D36

Comment:
Tweak wording re 'what is property inheritance' to align better with the ac=
tual API changes.

  =3D Property Inheritance =3D
- =

  <<TableOfContents>>
  =

  =3D=3D Background =3D=3D
@@ -9, +8 @@

  Some ideas on how we might make versioned properties inheritable.
  =

  =3D=3D=3D What Is Property Inheritance? =3D=3D=3D
- Property inheritance is a mechanism by which a versioned property set on =
a given path applies also to that path's path-wise descendants.
+ Property inheritance provides a mechanism to find the versioned propertie=
s set on the path-wise parents of a given path.  Conversely it can be viewe=
d as a mechanism by which a versioned property set on a given path also app=
lies to that path's children.
  =

  =3D=3D=3D What's Driving This? =3D=3D=3D
  Desire for some form of inherited properties has existed almost from the =
dawn of Subversion.  This latest effort is in response to a recent proposal=
 regarding [[ServerDictatedConfiguration|Server Dictated Configuration]] (s=
ee http://svn.haxx.se/dev/archive-2012-01/0032.shtml).  That proposal made =
use of a new mechanism by which server dictated configurations (notably aut=
o-props and global-ignores) would be communicated from the server to the cl=
ient.  In the feedback on the proposal several people pointed out that vers=
ioned properties provide a possible alternative solution (and that the Tort=
oiseSVN project was already using pseudo-inheritable properties to address =
some of the same problems -- see http://tortoisesvn.net/docs/nightly/Tortoi=
seSVN_en/tsvn-dug-propertypage.html). Despite its origins in the server def=
ined configuration work, this wiki describes only a generic inheritable pro=
perties design (''though my the ultimate goal is to use these inheritable p=
roperties to implement the server dictated configuration feature -- pburba'=
').
@@ -94, +93 @@

  A child path that inherits a property from its parent may not have ready =
access to that parent in the working copy (e.g. the root of the working cop=
y is a subtree of the parent path).  To ensure that traditionally disconnec=
ted operations (i.e. those that require no access to the repository, like '=
svn add') remain disconnected, we will maintain a cache of properties inher=
ited by the root of the working copy. Whenever a new working copy is checke=
d out, any properties inherited by the root of the working copy will be cac=
hed in the working copy.  If a subtree within a working copy is switched, a=
 separate cache will be created for the root of that subtree.  Whenever an =
update occurs the cache(s) will be refreshed.
  =

  The cache will be stored in a new wc-ng table:
- ||||||||||<tablewidth=3D"978px" tableheight=3D"324px"style=3D"font-weight=
:bold;               ;text-align:center">TABLE: INHERITABLE_PROPS ||
+ ||||||||||<tablewidth=3D"978px" tableheight=3D"324px"style=3D"font-weight=
:bold;                ;text-align:center">TABLE: INHERITABLE_PROPS ||
  ||<style=3D"font-weight:bold;">Name ||<style=3D"font-weight:bold;">Data T=
ype ||<style=3D"font-weight:bold;">Primary Key ||<style=3D"font-weight:bold=
;">Foreign Key ||<style=3D"font-weight:bold;">Notes ||
  ||wc_id ||integer ||Yes ||References NODES.WC_ID || ||
  ||local_relpath ||text ||Yes ||References NODES.LOCAL_RELPATH || ||