[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 08:53:30 CET

John Peacock wrote:

> Ben Collins-Sussman wrote:
>
>> Well, users have been asking for server-settings that can be
>> broadcast to clients for quite a while now.. I guess we've ignored
>> the request long enough to the point that other projects have started
>> improvising workaround solutions. :-/
>
>
> 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.

> The portion of the WC code dealing with the admin files is, by
> design, very focused on only the current directory. Hence referencing
> a parent's data is not easy (I'm not even sure I know enough to know
> whether it is even possible). And if you have only checked out a
> subtree, a round-trip to the server is necessary, of course.
>
> What would be much more workable would be for the RA layer to present
> virtual properties to the WC attached to the applicable directory.

Exactly.

> Then the WC code only needs to examine the current container for any
> inherited properties. When the client checks out a given directory,
> the server would calculate the inherited properties applicable to that
> directory and include that with any other properties set on the
> directory. This would mean that the proposed inherited properties
> would need an additional attribute, so you could tell from the client
> code whether this iprop was inherited from higher in the directory
> tree, or was the actual iprop itself.

-- 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 08:53:42 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.