[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tsvn:logwidth in svn repository (Re: svn commit: r12696 - trunk/subversion/po)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-01-14 13:26:30 CET

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
prop value?

> 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
> point...

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...)

-- Brane

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:27:44 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.