subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Trivial Update of "InheritedProperties" by CMichaelPilato
Date Fri, 10 Feb 2012 15:20:26 GMT
Dear Wiki user,

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

The "InheritedProperties" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/InheritedProperties?action=diff&rev1=29&rev2=30

Comment:
Header formatting tweaks only.

- = INHERITED PROPERTIES : BACKGROUND =
+ = Inherited Properties =
+ == Background ==
- == What's This? ==
+ === What's This? ===
  Some ideas on how we might implement simple inherited properties.
  
- == What Are Inherited Properties? ==
+ === What Are Inherited Properties? ===
  Inherited properties are versioned properties that apply not only to the path the property
is explicitly set on, but also to all of that path's path-wise descendants (at the same revision)
which do not explicitly have the same property set.
  
- == What's Driving This? ==
+ === What's Driving This? ===
  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 Server Dictated Configuration
(see http://wiki.apache.org/subversion/ServerDictatedConfiguration and http://svn.haxx.se/dev/archive-2012-01/0032.shtml).
 That proposal made use of a new mechanism by which server dictated configurations (notably
auto-props and global-ignores) would be communicated from the server to the client.  In the
feedback on the proposal several people pointed out that versioned properties provide a possible
alternative solution (and that the TortoiseSVN project was already using pseduo-inheritable
properties to address some of the same problems -- see http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-propertypage.html).
Despite its origins in the server defined configuration work, this wiki describes only a generic
inheritable properties design (''though my the ultimate goal is to use these inheritable properties
to implement the server dictated configuration feature -- pburba'').
  
- == What This Design Is and What It Isn't ==
+ === What This Design Is and What It Isn't ===
  This design provides the bare minimum to support the basics of inherited properties:
  
   * A way to identify properties that are inheritable vs. those that are not.
@@ -19, +20 @@

  
  That's it, it's really just a small extension of our existing versioned property capabilities.
 If your own personal vision of inherited properties includes something outside of these three
bullets (e.g. merging inherited properties), then that is outside of this design's scope (at
least initially).
  
- == How Is This Design Different? ==
+ === How Is This Design Different? ===
  It's not really.  A lot of the ideas here come from the dev list, #svn-dev, and conversations
with other devs.  The difference, if there is any, is that this design aims to be as simple
as possible and steer clear of complications which have thwarted inheritable properties in
the past. If there is more than one reasonable behavior to choose from, it usually goes with
the one that is simpler to explain/understand/implement/maintain.  ''This means that not everyone
will be happy, it may not cover every use-case, but I hope it covers most of them -- pburba.''
  
- == Inheritable Properties Today ==
+ === Inheritable Properties Today ===
  Subversion has supported merge-tracking using the svn:mergeinfo property since the 1.5 release.
 The svn:mergeinfo property is inheritable in some merge-sensitive contexts, notably 'svn
merge', 'svn log -g', and 'svn mergeinfo'. For example, say we have this simple branch structure
at r700 in our repository:
  
  {{{
@@ -44, +45 @@

  
  >
  }}}
- = INHERITED PROPERTIES : DESIGN =
+ == Design ==
- == Differentiating Inheritable Vs. 'Normal' Properties ==
+ === Differentiating Inheritable Vs. 'Normal' Properties ===
  Inheritable properties will be identified by a prefix on the property name.
  
   1. Custom user properties will use the "svn:inheritable:" prefix.
@@ -53, +54 @@

   1. Valid property names for both custom user and Subversion reserved inheritable properties
are as per any other other versioned property (i.e. text only).
   1. Valid property values for both custom user and Subversion reserved inheritable properties
are as per any other Subversion reserved property (i.e. text only and stored internally as
UTF-8).  This means that binary property values are not supported even in the case of custom
user properties.
  
- == Inheritance Rules ==
+ === Inheritance Rules ===
  Inheritance will be more flexible than the current svn:mergeinfo inheritance model.  For
a given inheritable property 'svn:inheritable:X':
  
   1. A path may have the svn:inheritable:X' '''explicitly''' set on it (i.e. exactly how
versioned properties work today). ''''' '''''
@@ -86, +87 @@

  
  '''''### TBD: Externals: Do they work like switched subtrees?'''''
  
- == Inherited Properties Cache ==
+ === Inherited Properties Cache ===
  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 copy is a subtree of the parent path).
 To ensure that traditionally disconnected operations (i.e. those that require no access to
the repository, like 'svn add') remain disconnected, we will maintain a cache of properties
inherited by the root of the working copy. Whenever a new working copy is checked out, any
properties inherited by the root of the working copy will be cached 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="978px" tableheight="324px"style="font-weight:bold;         ;text-align:center">TABLE:
INHERITABLE_PROPS ||
+ ||||||||||<tablewidth="978px" tableheight="324px"style="font-weight:bold;           ;text-align:center">TABLE:
INHERITABLE_PROPS ||
  ||<style="font-weight:bold;">Name ||<style="font-weight:bold;">Data Type ||<style="font-weight:bold;">Primary
Key ||<style="font-weight:bold;">Foreign Key ||<style="font-weight:bold;">Notes
||
  ||wc_id ||integer ||Yes ||References NODES.WC_ID || ||
  ||local_relpath ||text ||Yes ||References NODES.LOCAL_RELPATH || ||
@@ -102, +103 @@

  
  
  
- == Authentication ==
+ === Authentication ===
  In exactly the same way that svn:mergeinfo is handled, generic inheritable properties can
be inherited by any path the user has read access to, even if the user has no access to the
parent path the inheritable property is explicitly set on.
  
- == Merging Inherited Properties ==
+ === Merging Inherited Properties ===
  This proposal purposefully avoids any concept of how inherited properties might be merged
together with explicit properties.  In some cases if a path has an inheritable property set
on it, then it might make sense to consider that property's value as the complete and full
value for that path, end of story (e.g. svn:mergeinfo).  On the other hand, it's easy to imagine
use-cases where it might be useful to merge a path's explicit and inherited properties.  However,
both cases depend on the semantics of the particular inherited property. There is no way to
develop a one-size-fits-all approach to merging inheritable properties.  So while the suggested
API changes below support the ability to get a path's explicit and inherited properties, how
to merge these values (if at all) will be handled on a case-by-case basis.
  
- == Subcommand Changes ==
+ === Subcommand Changes ===
  In general inherited properties will be treated like any other versioned property, so most
subcommands will only notice the paths on which explicit properties are set, regardless of
whether these are inheritable or not.  For example, if we have an unmodified working copy
and then make a local change to a parent path's explicit inheritable property:
  
   * 'svn status' won't show any property mods on the parent's children paths.
@@ -232, +233 @@

  
  'nearest' - Shows the target's explicit properties and the nearest path-wise parent for
any properties which are *not* explicitly set on the target.  This would be useful for seeing
inheritable properties which follow a strict override model like svn:mergeinfo.
  }}}
- == API Changes ==
+ === API Changes ===
  Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument apr_hash_t
*'''inherited_prop_hash'''.  Also allow the possibility that the existing apr_hash_t *prop_hash
argument may be null:
  
  {{{#!cplusplus
@@ -586, +587 @@

                        const char *path,
                        apr_pool_t *pool);
  }}}
- == New APIs ==
+ === New APIs ===
  {{{#!cplusplus
  /** Return @c TRUE iff @a prop_name represents the name of a inheritable
   * property.
@@ -596, +597 @@

  svn_boolean_t
  svn_prop_is_inheritable_prop(const char *prop_name);
  }}}
- == Drawbacks ==
+ === Drawbacks ===
  The suggested design above has some known drawbacks and trade-offs:
  
   1. [danielsh] Using the 'svn:inheritable:' namespace precludes a property from being both
inheritable and ${some_future_semantics}, since a property name cannot be simultaneously in
the 'svn:inheritable:' namespace and in the 'svn:{some_future_semantics}:' namespace.

Mime
View raw message