On 08.02.2012 23:08, Paul Burba wrote:
On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann<eq...@web.de> wrote:
On 07.02.2012 00:41, Greg Stein wrote:
On Mon, Feb 6, 2012 at 18:15, Paul Burba<ptbu...@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.
