On 08.02.2012 23:08, Paul Burba wrote:
> On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann<eqfox_at_web.de> wrote:
>> On 07.02.2012 00:41, Greg Stein wrote:
>> On Mon, Feb 6, 2012 at 18:15, Paul Burba<ptburba_at_gmail.com> wrote:
>>>> Hi All,
>>>>
>>>> There has long been a desire for Subversion to support some form of
>>>> inherited properties. Recently, while discussing a potential solution
>>>> for server dictated configurations (see
>>>> http://svn.haxx.se/dev/archive-2012-01/0032.shtml), the idea of using
>>>> inheritable properties as an alternative approach was raised. To that
>>>> end I put together an inherited properties design wiki, see
>>>> http://wiki.apache.org/subversion/InheritedProperties
>>>>
>>>> Many of you have already seen this wiki and weighed in on the server
>>>> dictated config thread, but in the event you haven't please check it
>>>> out. I'd like to move this forward or return to the original server
>>>> dictated config, so any questions, concerns, and/or suggestions are
>>>> greatly appreciated.
>>
>> Sure, here we go ;)
> Hi Stefan, Thanks for the feedback, responses below...
>
>> I think the most problematic part of your proposal is backward
>> compatibility as Daniel already pointed out. On a meta level,
>> this may also be taken as a general weakness in your model
>> that it does not interact well a proven, well-established model.
>>
>> Without having thought too much about it, here is some
>> counter proposal that might work better:
>>
>> * by default existing and future props behave as today
> Meaning that "inheritable" properties are just like any regular
> versioned property in 1.7 as regards setting, getting, server-side
> storage, and client-side storage?
Except for the client-side storage, yes. I don't know
how an efficient client-side representation would
look like.
As for the props themselves, I propose to allow for
*any* property to be inheritable but that they must
be marked as such explicitly.
>> * a new svn:inherits property (just this one) controls which props
>> will be propagated to sub-folders and will itself not be propagated
>> * propagation will exclude / ignore a node that has props but no
>> svn:inherits setting
> Do we need to set svn:inherits on every directory? Or just at the
> root of the subtree we want some inherited properties to apply to?
On the root of that sub-tree.
> Could you be specific about what you mean by "propagation".
Propagation = inheritance. It does not imply that
data has to be actually copied in the persistency
layer.
>> This should allow legacy clients to read and write props as today.
> That is no different from what I've proposed that I can see. Do you
> disagree? Perhaps the wiki needs to be clarified.
Not much, I haven't been as explicit here as I should
have. I see inherited props as a server-side feature
(with or w/o client support). The server will report inherited
props for all nodes in the respective sub-tree as if they
had been set explicitly on each node.
Newer clients will also receive a boolean flag "inherited"
for each prop that tells them whether the value has been
set explicitly by some user or whether the server just
filled it in. Possibly, we may even give the node (+rev?)
from where the setting has been taken.
A difference from your proposal is that except for this
flag, the client sees the same data as today - props
on each node. If paths get switched etc., the props
retain this behavior: you may receive different values
for those props, inherited from different nodes.
This is different from what TSVN offers today but also
eliminates a shortcoming of TSVN's implementation
today: the root path actually having the prop set no
longer needs to be present in the working copy.
>> Once they modify / write props, they won't add svn:inherits (unless
>> explicitly added by the user).
> "They" refers to legacy clients? New clients that understand
> svn:inherits? Something else entirely?
Legacy clients. New clients understand that some
props should rather be changed at their origin and
should somehow present that information in the UI.
>> Now the props are active locally
> When (or what) does "Now" refer to. What are locally active props?
After begin changed / set explicitly within the w/c by
some legacy or newer client.
>> but won't be propagated within the sub-tree. Instead the inherited
>> props from parents will still be visible within the sub-tree.
>>
>> Now, what could prop inheritance look like? The thing is that
>> we should have the option to specify file-type specific settings /
>> props high up in the repo tree. Suggested format for svn:inherit
>>
>> * N lines, each containing a single rule
>> * a rule adding / replacing properties to be passed down takes the
>> following form of
>> add propName [propValue [regex] ]
> What does propValue control? Is an inheritable property potentially
> inheritable only if it has a certain value?
No. But I had the impression that many props that I
would want to set globally (using inheritance) don't
apply to folders but only to files. Thus, they don't
belong to the declaring node itself.
To model that, I had to add the regex part plus the
ability to specify different values for different regex(es)
or even to specify a value at all.
Also, you may specify the property entirely within
svn:inherits - no need to also list it in the "ordinary"
props.
>> - regex controls what files / folders it will be applied to
> So an inheritable property might not be inheritable by all children?
I would say: inheritable to all children but will only
applied to some of them.
>> - if propValue is not given, propName must refer to some
>> existing prop on this directory
>> - takes affect at the current node
>> * a rule to stop propagation *in the subtree* might look like this
>> remove propName
>> * a rule to exclude a specific setting for only this node
>> ignore propName
>> * multiple rules for the same propName are allowed and will be
>> applied in order of declaration
>>
>> Local prop settings
> "Local prop settings": Do you mean properties explicitly set on a path
> or local prop changes?
Explicitly set on a path.
>> will never be modified nor overwritten by
>> inherited props. To propagate a different value, just need to put
>> an "add" rule in svn:inherits on that node.
> Sorry for all the questions, I'm simply having a tough time following
> you :-\ Maybe you could describe how your approach would work in a
> simple case like this:
>
> Let's say we have a new property svn:ignores, which is similar to
> svn:ignore but we want to to be inheritable across an entire subtree,
> not just for the immediate children of the directory it is set on.
> Say each top-level project in the ASF repository wants it's own
> particular value of svn:ignores, but that within each project the
> value for this property is consistent. Looking at just
> https://svn.apache.org/repos/asf/subversion what would we set to
> accomplish this?
>
Some escape chars for newline are necessary.
Let's assume it is ";" with ";;" being parsed as
a single ";" char.
$>svn proplist ^/subversion
svn:inherits
svn:ignores (from svn:inherits)
$>svn propget svn:inherits ^/subversion
add svn:ignore *.o;*.la;*.user
$>
I like the idea of inherited props very much and just
wanted to present my shot at it. There may be many
things wrong with it since I haven't put too much thought
into it.
-- Stefan^2.
Received on 2012-02-12 16:14:52 CET