On Mon, Jan 16, 2012 at 8:28 PM, Hyrum K Wright
<hyrum.wright_at_wandisco.com> wrote:
> On Mon, Jan 16, 2012 at 5:51 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> ...
>> On Thu, Jan 5, 2012 at 4:52 PM, Hyrum K Wright
>> <hyrum.wright_at_wandisco.com> wrote:
>>> 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.
>>
>> Maybe we can make a special case for inheritable properties, simply
>> state that by definition, if you set an inheritable property on a
>> path, then users, even those who don't have access to the path, but do
>> have access to the path's children, can inherit the property.
>>
>> For example if a user has access to foo/bar/baz, then that user can
>> inherit properties from foo, even if he doesn't have access to foo
>> itself. All the repository has to tell the client is, "Path
>> foo/bar/baz inherted property NAME=VAL", it doesn't even need to say
>> where it came from.
>>
>> If we don't make this exception then it seems to me that inheritable
>> properties are dead in the water, at least as far as being a useful
>> solution to "server" dictated auto-props and global-ignores.
>
> After having gone through the wc-ng experience, alarm bells start
> ringing every time somebody says "we can make a special case for ...".
Hi Hyrum,
I might have needlessly muddied the waters when I said "special case".
To be clear, I meant that *all* inheritable properties (not just
"svn:auto-props" and "svn:global-ignores") would behave this way in
the *general* case.
The "special case" is not about "svn:auto-props" and
"svn:global-ignores" in particular, but rather that we can know some
information (i.e. the inherited property value) about a path-wise
ancestor we don't have access to.
> Please, please, please consider if that's really needed, of if a more
> generalizable solution is appropriate.
Well if "that" is the ability of a path (which we have read access to)
to know the inherited value of a property from the path's (path-wise)
ancestor (which we have no access to), then yes, I think it is really
needed. Why? Because without this behavior inheritable properties
are crippled from the start.
Let's forget about auto-props and global-ignores for a minute and take
a really simple generic use-case for inheritable properties:
We want the inheritable property svn:inheritable-foo to apply to our
entire repository. Ok, let's set it on the root of the repository.
<Sit back smugly, thinking, "Ha! That was easy!">
Five minutes later: "Oops, we have fine grained path-based access set
up, not all users have access to the repository root so they won't
inherit this property." We'll need to determine the subtrees within
the repository that each unique user access configuration can read and
then set svn:inheritable-foo on the roots of those subtrees. And we
need to make sure we keep this in sync with any changes the access
rules. This is an administrative nightmare!
> (And maybe what we're talking
> about here is a generalized solution for inheritable props. :) )
Sorry, I should have clearly stated from the get-go: I am talking
about a *generalized* solution for inheritable properties, I'm just
doing it with an eye to how it can be used to implement repository
dictated autoprops/ignores. The latter is what I want to solve. The
wiki proposed a solution and several people pointed out that the
feature could be implemented with properties, so I'm investigating
that option.
> Another thing to note is that there have been some rumblings about
> authz improvements, along the lines of an additional permission to say
> "you can know about this directory". I know C-Mike has been thinking
> about this off-and-on since the 3242 debacle, and something like
> inheritable props my fit in that model, though I'd had to make the
> feature dependency tree another level deeper.
Even if that was implemented today it's still an administrative
nightmare, albeit a lesser one. In the example above we'd need to
give the new special permission to the repository root. But the
moment we start setting inheritable properties on subtrees, we'd also
need to be sure that those subtrees have the special permission if all
users with access under that subtree don't have access to the root of
the subtree.
To condense to its essential core what I am proposing, it's this simple rule:
"If a user has read access to a path, then that path can inherit
inheritable properties from its path-wise ancestors, regardless of the
user's permissions to those ancestors"
>>> 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.
>>
>> We could chose to make things simple and follow the svn:mergeinfo
>> model of inheritance:
>>
>> a) If a path has an explicit given property then it doesn't inherit
>> that property; the explicit value is the complete value.
>>
>> b) If a path doesn't explicitly have a given property then it inherits
>> that property from its nearest parent with the property explicitly set
>> on it.
>>
>> No merging of inherited with explicit properties, so no conflicts,
>> just keep it simple.
>
> What if there are multiple applicable paths?
But there aren't! A path doesn't inherit from it's children, only its
ancestors, and it only inherits from its nearest ancestor with the
property in question...(before you punch your monitor read on :-)
> Consider a commit in which two files are committed and they each have
> different svn:inherit:log-message properties at equal levels of
> priority. If either file was committed separately, the result would
> be clear, but together it creates ambiguity. I don't know the answer
> to this question, and I maybe it's as simple as "pick one" or "cat all
> the values together." I'm just saying that while the result doesn't
> have to be sensical, it should at least be defined.
A valid question but it is outside the scope of generic inheritable properties.
Yes, if someone implements log templates and the use inheritable
properties to do it, then they will need to define the behavior in
such a case. But generic inheritable properties are only about
individual paths:
Given Path Z:
1) Does path Z have svn:some-inheritable-prop explicitly set on it? If
yes, then we know the value.
2) If not, does path Z inherit svn:some-inheritable-prop from one of
its path-wise ancestors, if yes then we know the value, if not then Z
doesn't have this property.
Your example reminds me of merge tracking when our merge target has
explicit mergeinfo on the root of the target, but also on subtrees.
It's clear what the mergeinfo property values are on the root and the
subtrees, but how to interpret this catalog of mergeinfo when deciding
*what* to merge is the job of the merge logic. In the same way, how
to handle differing svn:inherit:log-message property values is the job
of the commit logic -- all inherited properties tell us is what props
exist on a single path.
>> Essentially the same approach for svn:auto-props and
>> svn:global-ignores, we do the same thing the current hierarchy of
>> configuration does today: There is no merging of lower priority
>> configuration, it's simply a matter of choosing the option value from
>> the highest priority level the option is specified.
>>
>> Which would be, from highest to lowest priority:
>>
>> Command-line options*
>> Explicit/inherited svn:auto-props/svn:global-ignores
>> Per-user runtime configuration (${HOME}/.subversion/*)
>> The per-user Registry values (Windows Only)
>> Per-machine runtime configuration (/etc/subversion/*)
>> The system-wide Registry values (Windows Only)
>>
>> * Yes Johan, your arguments for making CL options have the highest
>> priority did sway me :-)
> ...
>
> One other thought: if we are going to implement these as properties,
> and we're going to store them as properties, and we're going to
> transmit them (through the editor) as properties, let's please make
> sure they *are* properties. In working on Ev2 recently, I discovered
> the fact that one of the ways we remove stale lock tokens on the
> client is by deleting a non-existant property. For reasons I won't go
> into here, this violation of property semantics is essentially
> implementation-dependent, and causes all kinds of headaches when the
> implementation changes. Let's not make the same mistake with
> inheritable properties.
You can be sure if we go down this road I'll be pestering you for the
reasons you won't go into here :-)
> -Hyrum
>
> PS - Thanks for all the work on this issue / sorry I'm just chiming in
> the from the peanut gallery. :/
I welcome the chimes!
Paul
Received on 2012-01-17 17:36:49 CET