Versions Compared

Old Version 54

changes.mady.by.user Paul Burba

Saved on

compared with

New Version Current

changes.mady.by.user Julian Foad

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Delete my questions and Paul's answers from the WC Inheritance Rules section, as I understand the rules now and I don't think the Q&A helps anyone.

...

  • Inheritance within the working copy is a bit more complicated. For a given property 'PropName' there are three basic cases of WC inheritance:
    1. If the peg and operative revisions
      Footnote

      See args to svn_client_proplist4 and svn_client_propget5 in the new APIs section. These are the primary APIs for getting inherited props from the WC.

      are for the path in question are anything other than unspecified
      Footnote

      svn_opt_revision_unspecified or svn_opt_revision_working.

      , then the respository is contacted to obtain the path's inherited properties. This is analogous to the repository inheritance model.
    2. If the peg and operative revisions are unspecified, then the working copy child path inherits properties from its parents in the actual
      Footnote

      The working tree plus property and text changes.

      tree, up to nearest working copy root (this is termed "default working copy inheritance"). Once the working copy root is reached, a WC child path may also inherit properties from repository parents via the inherited properties cache, which caches the properties inherited by the base node at the WC root (see the Inherited Properties Cache section). "Working copy roots" here are defined as:
      • A directory whose parent directory is not a working copy.
      • A directory or file which is switched relative to its immediate parent.
      • The root of a directory external.
      • A file external.
        These default WC inheritance rules have some important implications:
    3. A path, in an unmodified working copy at a uniform revision N, inherits the same properties that the base of that path would inherit in the repository at revision N.
    4. A path in a modified working copy effectively inherits properties from the proto-revision that any modified WC represents (a set of changes that could potentially be committed as a new revision).
    5. Mixed-revision working copies are similar to #2 except that there is no proto-revision. So unlike svn:mergeinfo and like tsvn:auto-props, inheritance across mixed-revision boundaries in the working copy is allowed by default.
      Leaving Julian's questions for now...
      Info

      [JAF] What is the unifying principle behind the set of rules? For example, a principle could be:

      "Inheritance occurs separately within each revision, and the WC 'actual' tree is treated as an unnumbered prototype for a revision that could potentially be committed[1]. Thus, a WC base node inherits from its repository parent node in its own revision in the repository, no matter whether that is the same as its WC parent node; and an 'actual' node[2] inherits from the parent node that it would have in the repository if the current WC were committed in full, no matter whether that is the same as its WC parent node."

      I think that principle would match all your rules if the 'mixed-revision' rule applies to actual nodes but not base nodes.

      [1] This particular principle for how we treat the 'actual' tree of a WC is something I've had in mind for a long time and I think it can be very useful in guiding how we design several aspects of WC behaviour, not just for inheritable properties.

      [2] By 'actual' version I mean the 'topmost' (i.e. MAX(op_depth)) version of the node in the WC, no matter whether that is different from or the same as the base version.

  • Info

    [PTB] JAF - I was envisioning a much simpler principle: Inheritance within the WC is within the actual tree[1]. This is easy for a user to explain and easy to understand. For example, no matter what the state of the WC a user can always say, "I see that 'my-WC/trunk' has the inheritable property 'InhPropName=PropVal'. That means that 'my-WC/trunk/README' inherits 'InhPropName=PropVal'. That makes sense!" If I understand correctly what you suggest, a user could face the case where a child path inherits a property value that differs from its actual WC parent's value (if it inherits anything at all). That strikes me as a recipe for user confusion.
    [1] By actual tree I mean the topmost (i.e. MAX(op_depth)) version of the node in the WC, pretty much the same thing your 2nd footnote means(question). I thought we differentiated actual vs. working such that the former included property and text changes? ([JAF] Yes, sorry for confusing terminology; I've adjusted my note to use 'actual'.)

    Info

    [JAF] At each WC path there is potentially a base node, potentially some intermediate layers, and potentially an actual node. Each of the nodes has properties, which may include inherited properties. When you say "Inheritance within the WC is within the actual tree", precisely what do you mean? It seems clear you mean each actual node should inherit from its (WC path parent) actual node, but do you mean each base node should inherit from its (WC parent path) actual node as well? The latter sounds terribly wrong because a base node is supposed to represent a repository node, but now it would have a different set of inherited properties depending on the state of the WC.

    In what I suggest, a child path base node would inherit from its repository parent, no matter whether that is the same as its its WC parent base node, because that maintains consistency, guaranteeing that particular node has the same set of properties no matter when and where you find it. As for the WC actual tree, our ideas are different but similar, but never mind that until we're clear on the basics.

Inherited Properties Cache

...