Inherited properties document

I started to write up a notes/inherited-properties document last July
(and I think I even posted an early version to the list). Here is is
again with some modification in my thinking. Perhaps this can be the
start of a wider discussion of how/whether Subversion could support
inherited properties.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Some preliminary notes on handling inherited properties (henceforth iprop):

1) An iprop can only be stored in a directory entry (since files cannot
"contain" other top level objects);

2) An iprop may not be a unique key (i.e. a file can contain a conventional
property by the same name and the file property always wins in a collision,
or an iprop may exist at multiple points in a given path and the last one
[longest subpath] is the winner);

3) An iprop is a revisioned object, just like ordinary properties (so that
the historical value can be obtained at any point in the future);

4) An iprop is inherited based only on repository tree location (by trivially
splitting the path into elements and applying each in turn from the
shortest to longest subpath);

5a) A copy/tag of a path will not include any iprop(s) from a higher level
unless explicitely requested (this has consequences for tags); OR

5b) A copy/tag of a path will get a copy of any inherited higher level
iprop(s) at the point of copy (this has consequences for copies);

6) Editing an iprop affects the actual node containing the iprop, no matter
where it is in the tree (modulo ACL's);

7) Adding an iprop affects only the node referenced (possibly overloading a
higher level node) [should adding an iprop with a target of a file
automatically apply the iprop to the containing directory?];

8) Deleting an iprop will only succeed when the target is the actual node
containing the iprop (i.e. no bubble-up);

9) From the point of view of the client, the iprop is returned as an
ordinary property for each applicable file under a directory containing an
iprop (only the server "knows" whether an iprop is actually associated with
a specific directory or is inherited from a higher level directory);

10) iprop's share the same limitations as conventional properties.

IMPLEMENTATION CONSIDERATIONS:

A) When the server is gathering the properties for a given directory node, it
must do so from the top down, possibly overloading existing values for a given
key while traversing the tree [can this still be handled as recursive operation
then?];

B) A large iprop stored close to the root path may cause noticible WC
storage (since each directory under that path would gain a copy of
the iprop value) [the user is allowed to shoot themselves in the foot by
having a 2k copyright iprop];

C) This scheme doesn't support multivalue iprop's inherited from multiple
locations in the tree [is that a significant limitation?];

D) The client code doesn't know anything special about iprop's (other than
all files inherit any iprops from their containing directory);

E) Copying a file to another directory does not include copying any
currently effective iprop, but copying a directory might (see 5 a&b above)
[is there a use-case for upgrading an iprop to a prop on copying a file
(either as default or new option)?];

F) Setting an iprop close to the root path would require all directories
and files lower in the tree to be marked as updated (this has implications
for mixed revision WC's);

G) iprop inheritance is based on the _repository_ path not the possibly
significantly shorter _working copy_ path;

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 16:50:37 2005