On Thu, Sep 13, 2012 at 2:59 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Paul Burba wrote:
>> On Thu, Sep 13, 2012 at 10:47 AM, Julian Foad wrote:
>>> parent dir in repo NODE
>>> | | \_____________
>>> | v v
>>> +-wc root dir BASE ACTUAL
>>> | | |
>>> | v v
>>> +-doc BASE ACTUAL
>>> | | |
>>> | v v
>>> +-README BASE ACTUAL
>>
>> This isn't quite what I had in mind (nor how the branch is currently
>> implemented). Recall from above when we ask for README's base:
>>
>> $ svn pl -v -rBASE --show-inherited-props ./doc/README
>> Properties inherited from 'file:///home/julianfoad/tmp/svn/inh/repo':
>> p
>> b1
>> Properties inherited from
>> 'file:///home/julianfoad/tmp/svn/inh/repo/doc':
>> p
>> b2
>> Properties on 'doc/README':
>> p
>> b3
>>
>> The properties inherited by README are not obtained from the WC at
>> all, but are from the repository (hence the URLs). What is happening
>> is really this:
>>
>> parent dir in repo NODE
>> | | \_____________
>> | | v
>> +-wc root dir repos ACTUAL
>> | parent |
>> | NODE |
>> | | |
>> | | v
>> +-doc repos ACTUAL
>> | parent |
>> | NODE |
>> | | |
>> | v v
>> +-README BASE ACTUAL
>
> OK, thanks for explaining. I think I follow.
>
> The difference with what you have just explained pertains mainly to a mixed-rev WC. Perhaps we could draw it like this, where the intention is to show, for every node, the chain of other nodes that this node inherits properties from:
>
> REPOSITORY WC-BASE WC-ACTUAL
> r10 r20 r30 (mixed-rev)
>
> parent (O) (O) (O)
> | |\\_ | __ | __________________
> | | \_ | __ | ________ \
> | v v v v v
> +-x (O) (O) (O) (@10) (O)
> | | | | \_______ |
> | v v v v v
> +-doc (O) (O) (O) (@30) (O)
> | | | \_ | ________ |
> | v v v v v
> +-README (O) (O) (O) (@20) (O)
>
> "(O)" just means a node; "(@10)" means a node from the specified revision.
>
> Does that diagram look right to you?
Yes, it agrees with my implementation and thinking anyway.
> (Why am I spending considerable effort on trying to draw a diagram to represent the semantics? Because I think it is a very powerful means of communication.)
>
> I'm seeing something in the above diagram that may be troubling. It says that, in a mixed-rev WC, if I have no local mods, nevertheless the full set of properties (including inherited props) in effect on an ACTUAL node is different from the full set of props that are in effect on the correcponding BASE node.
Yes, but when inheritance comes into play we are not dealing with
*single* nodes. We are talking about a tree[1] of nodes: Some target
'root' node, possibly with explicit props, and the props that target
inherits from its parent nodes (some of which might be in the WC but
some which might be located in the repository), we are not dealing
with single nodes located entirely within the WC. So in a mixed-rev
WC we have an ACTUAL tree located entirely in the WC and a "BASE
tree", which might effectively extend beyond the root of the
repository. But this BASE tree, taken as a whole, doesn't correspond
to anything in the repository because of the mixed-revisions.
Maybe this will make my thinking clearer: Say we have the WC described
by your diagram above (and assuming no local mods):
REPOSITORY WC-BASE WC-ACTUAL
r10 r20 r30 (mixed-rev)
parent (O) (O) (O)
| |\\_ | __ | __________________
| | \_ | __ | ________ \
| v v v v v
+-x (O) (O) (O) (@10) (O)
| | | | \_______ |
| v v v v v
+-doc (O) (O) (O) (@30) (O)
| | | \_ | ________ |
| v v v v v
+-README (O) (O) (O) (@20) (O)
In practical terms you are concerned that, for example, 'svn pl -v
--show-inherited-props doc' might show different inherited props than
'svn pl -v --show-inherited-props doc -rBASE' right?
But the properties a BASE node inherits should always be the same no?
My intent was that all of the following would produce the same set of
inherited porperties for parent/x/doc[2]
svn pl -v --show-inherited-props doc -rBASE
svn pl -v --show-inherited-props doc -r30
svn pl -v --show-inherited-props ^/parent/x/do_at_30
IOW In terms of iprops, I see the mixed-rev/no-local-mod WC as
equivalent to a local mod as far as inherited properties in the ACTUAL
tree are concerned.
[1] Albeit a tree where each node has only one child.
[2] Excepting the expected differences in the parents' path as URL vs WC paths.
> In other words, a diff that includes inherited props would show a difference even though (in another sense) there are no local mods. That seems unintuitive to me. How about you?
>
>
>>> (If at this point you're wondering what other picture I could possibly
>> have imagined, your "principle: Inheritance within the WC is within the
>> actual tree" made me wonder if you meant something like this:
>>>
>>> wc b1 a1
>>> | _____________/ |
>>> | v v
>>> +-doc b2 a2
>>> | _____________/ |
>>> | v v
>>> +-README b3 a3
>>>
>>> since I consider BASE nodes as well as ACTUAL nodes to be within the WC.)
>>
>> That's why I tried to emphasize in the recent wiki updates
>> (http://wiki.apache.org/subversion/InheritedProperties#Working_Copy_Inheritance_Rules)
>> that there is a difference between the "default" WC inheritance, which
>> occurs in the actual tree, and inheritance that occurs when we provide
>> a operative/peg revision.
>
> I see; I hadn't realized that 'default WC inheritance' referred to the inheritance that is seen when a revision specifier is defaulted on some command. Can we say "'actual' tree inheritance" or "'actual' props inheritance" instead of "default inheritance"?
Certainly.
> As a meta-observation, it is often useful to define behaviour in terms of tree states and such (a model of the WC, a model of the repository), and to mention command-line parameters only in illustrations and concrete examples.
>
> - Julian
>
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
(And yes, I am abusing the BASE tree concept here, but I believe it is
necessary given the nature of property inheritance).
Received on 2012-09-14 15:31:46 CEST