Inherited Properties Discussion document

Attached please find some preliminary notes documenting my current thinking on
inherited properties (iprops). I'd like to meet some time at OSCON to discuss
this with any interested parties. I'm sure I've missed some obvious
considerations, but I think my ego is strong enough to sustain the inevitable
criticism. ;)

If you are interested, please reply directly to me and I will see about finding
an appropriate time and bar^Wplace...

Thanks

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

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 soley on filesystem 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 bubbleup like editing);

9) From the point of view of the client, the iprop is returned as an
ordinary property for each applicable file and directory (so only the server
is aware that a property has been inherited);

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

IMPLEMENTATION CONSIDERATIONS:

A) When the server is gathering the properties for a given 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 entail noticible WC
storage based on the current implementation of working copies (since each
file and 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 in their top level directory];

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 (although
any code which might use inherited properties more efficiently, like custom
keywords, would require their own patches to implement that);

E) Copying a file 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 Mon Jul 19 03:31:32 2004