Branko Čibej wrote:
> John Peacock wrote:
>
>> Inherited properties would solve this specific problem quite nicely.
>> Of course now that I have spent a little time spelunking in the WC
>> code, I'm not sure how practical that is going to be without a rewrite.
>
>
> The fact that a propertz is inherited is something the _server_ should
> worry about, not the WC. As far as the WC is concerned, there should be
> almost no difference between an inherited property and any other property.
True, except to the extent that the WC code should at least know about
properties that a _file_ has inherited from it's containing _directory_. For
efficient storage of information in the WC, it would behoove us to at least
smarten up the WC code to go that far. We wouldn't want the inherited
properties to get stored for every single file in the WC, just the [much
smaller] set of directories which have been checked out. For compatibility with
downrev clients, however, the server could actually be smart enough to push the
properties down to the file level (as actual properties now), but I don't think
we would want this to be the default behavior.
However, this just gave me an idea: store the property in the repository on a
directory as an svn:iprop and when the server adds it to some other subdirectory
it reports it as an svn:vprop (virtual property). Then the client code can
treat both of those as equivalent for purposes of container inheritance, yet
only the former is editable.
I'm trying not to require a new table in the repository (harder), so long as the
table scan for inherited properties is quick and to the point...
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 14 13:18:14 2005