On Tue, Jan 24, 2012 at 1:57 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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.
I'm not proposing anything like that...
> We need to
> provide a way to set properties; we need to provide a way to get them (as
> efficiently as possible).
Agreed. Just the basics, that is all I am suggesting.
> 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
Ah, here is where I suspect we have a disconnect. You say users can
choose "to interpret their own custom properties as inheritable".
This seemingly implies that there is no real difference between
"normal" user properties and "inheritable" user properties; it's all
in how we chose to interpret them. Is this what you are saying?
Because if it is, I think this is a mistake, as I've explained
elsethread. I'll take another stab at explaining my objection:
1) First, the obvious: Inheritable properties set on a path should be
inherited by all the paths underneath it (assuming none of those
subtrees have the same property set).
2) If we accept that #1 is a worthy goal, then it follows that we only
need set an inheritable property on the common root of all paths we
want that property to apply to. Take two likely use cases:
a) A repository administrator has a property they want to set on the
whole repository, they should be able to simply set it on the root of
the repository and be done with it.
b) Given a repository like the ASF's, there are scores of projects rooted
just below the repository root. Each project is largely managed by
different groups that likely have different needs. These different needs
likely mean that different inheritable properties apply to
different projects.
Like 'a' above, the project owners should be able to set the inheritable
properties that apply to their project on the root path of their project and
be done with it.
Seem reasonable so far?
3) To make #2 feasible, inheritable properties should behave like
svn:mergeinfo, they should always be inheritable from a parent path,
even if you only have access to the child path. For example, say we
have a repository structured like so:
/
/projX
/projX/trunk
...
/projX/branches
/projX/branches/1.0
...
/projX/branches/1.1
...
User "Regular_Joe" has rw access to /projX/trunk' and
'/projX/branches', but no access to the repos root or '/projX' proper.
However, '/' has numerous repository-wide inheritable properties set
on it and '/projX' likewise has several project-wide inheritable
properties.
We face two choices:
a) Either "Regular_Joe" can know the property values of the
inheritable properties on '/' and '/projX', despite not having any
access to those paths (did I already mention that this is how
svn:mergeinfo has behaved since 1.5? :-)
*OR*
b) "Regular_Joe" can't know the property values inherited from paths
he doesn't have access to. This means that whoever sets up
inheritable properties must take the repository's authz settings into
account if they want to be sure the property really applies to all the
paths they want it to apply to. I hope I don't need to go into detail
as to why this would be both cumbersome and mistake prone to setup and
maintain.
4) Ok, let's assume for a moment that '3a' is the right approach, if
we have access to a path we can know what properties that path
inherits regardless of our access to the path's parents. But if we
don't differentiate between 'normal' and 'inheritable' properties,
then we can know the value of *any* property on an otherwise
unreadable parent path. This is a serious security regression no?
But if inheritable properties were substantively different from
'normal' props and thus had to be explicitly created as inheritable,
with the understanding that all child paths could access the property,
then existing properties won't suddenly become inheritable and new
'normal' properties wouldn't be inheritable either. Only properties
for which it made sense to be inheritable would be so.
Make sense?
>, and performing the requisite
> calculations for merging such properties using equally custom code around
> our rather sufficient APIs.
+1
> Later, if sufficient user-generated demand -- based on real-world usage
> scenarios -- for consistent handling/merging of properties which are, by
> convention, deemed inheritable arise, we can explore adding public APIs to
> consistify this handling/merging. But please, let's not overdesign this for
> the sake of "what if".
I've tried not to. See
http://wiki.apache.org/subversion/InheritedProperties for what I'm
envisioning.
Paul
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Received on 2012-01-26 22:56:21 CET