On 01/21/2012 09:05 AM, Ivan Zhakov wrote:
> On Thu, Jan 19, 2012 at 03:23, Paul Burba <ptburba_at_gmail.com> wrote:
>> Yeah, I've been thinking about this. As you say, the solution for our
>> "own" inheritable properties is simple. Since Subversion already
>> reserves properties beginning with "svn:" for its own use we could
>> just extend it and say anything beginning with "svn:inheritable:" is
>> inheritable.
>>
> Another option is make caller to know how to handle properties. I.e.
> introduce call like svn_get_inhertiable_prop(wc_path, propname)
> returning chain of configured properties with repos_path starting from
> given wc_path. For example call to
> svn_get_inheritable_prop("wcroot/foo/bar", "property") return:
> /repos/project/trunk/foo -> value1
> /repos/project/trunk -> value2
> /repos/ -> value3
>
> Then caller may implement any logic to merge them. At implementation
> level we can store all properties and WC root (and for each switched
> root).
I must have blanked out through the sequence of emails that got us from
"let's solve a couple of oft-reported user issues regarding auto-props and
ignores" to "let's implement custom inherited properties". But in general,
I'm with Ivan here.
Subversion's behavior is unaffected by user-defined properties, so we have
zero obligation to implement any sort of advanced handling APIs that may or
may not ever be used in conjunction with those properties. We need to
provide a way to set properties; we need to provide a way to get them (as
efficiently as possible). The users can then do whatever they want with the
results, choosing to interpret their own custom properties as inheritable or
not based on criteria that is likewise custom, and performing the requisite
calculations for merging such properties using equally custom code around
our rather sufficient APIs.
Later, if sufficient user-generated demand arises -- based on real-world
usage scenarios -- for consistent handling/merging of properties which are,
by convention, deemed inheritable, *then* we can explore adding public APIs
and such to consistify this handling/merging. But please, let's not
overdesign this for the sake of "what if".
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-01-24 19:59:50 CET