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

Re: [RFC] Server Dictated Configuration

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Thu, 5 Jan 2012 15:52:49 -0600

On Thu, Jan 5, 2012 at 3:23 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Jan 5, 2012 at 4:17 PM, Konstantin Kolinko
> <knst.kolinko_at_gmail.com> wrote:
>
>>> The approach TortoiseSVN and some other clients take does work pretty
>>> nicely but I also think they reveal the short comings in using
>>> properties.  For convenience, TortoiseSVN does not force you to set
>>> these properties on every folder and instead will walk to the root of
>>> your WC to find them, but then this also exposes the problem that if
>>> you did not checkout the folder that has those properties you are back
>>> to square one.
>>
>> As I wrote in this very thread two days ago [1], this shortcoming
>> could be solved if the properties for the parent folders were present
>> in the WC.
>>
>> Now that wc has a database it could store those properties.
>
> I think the last time this feature (server-dictated configuration) was
> proposed, this was the approach considered.  Perhaps the new WC format
> makes it more possible than last time, I do not know.  It seems like
> it would be less efficient though.  The approach outlined in the
> proposal, via its usage of the hash and comparing the hash when the
> session is opened makes it easy for the client to know when settings
> have changed.  If we use properties in the manner described, then
> doesn't every RA session have to inspect every folder all the way back
> to the root on every request?
>
> It seems like someone would have to come up with a way to solve this
> problem, or remove the requirement of inheriting properties that are
> not already in the WC.

We've been talking about a general mechanism for inherited properties
for a *long* time. If implemented, such a mechanism could be used for
repos-dictated config through inherited, versioned properties.
Another possible use could be log message templates.

As I recall, there were a few reasons why inherited properties haven't
been implemented. One is the client-side storage and lookup, which
wc-ng has helped with. The other is what to do with non-checked out
parent directories, which you mention above. Another problem is the
various authz issues, similar to the infamous issue 3242 problems we
had with copy and move. And lastly, we haven't yet hammered out the
issues surrounding what to do with potentially conflicting properties
within the tree--though that might have been specific to log message
templates, now that I think about it.

In any case, there could be many uses for inherited properties, but
not all the kinks have been worked out. Though it might be time to
revisit them.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-01-05 22:53:23 CET

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