John Peacock wrote:
> 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.
What do you do with switched files whose "true" parents have a different
> 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.
Don't forget compatibility with generic DAV clients.
> 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.
It should still be possible to override the value deeper in the tree,
and -- as before -- don't ignore generic DAV clients.
> 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
You don't need a new table for _versioned_ inherited props, but you do
need one for unversioned inherited props -- i.e., ACLs.
(And please nobody tell me again that I can't talk about ACLs without
posting the ACL design...)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jan 14 13:27:44 2005