Neels J Hofmeyr wrote: > I remember someone talking of a hole. It went something like: If a folder is > copied-here, all its children have locally added status, and I understand > they refer to the op-root of the add to find out their history, i.e. that > they are copied. Now what if I replace such a child node with a fresh, new > node -- it will still think that it's part of the copy-here. Just vague > memory, haven't verified. This one should be fixed if it turns out to be so.
Turns out we are aware of this problem. My noob shot at a solution would be to have an indicator whether a WORKING node is the op-root of an add. Then we can have an op-root of an add within another op-root of an add without confusion. We might indicate on the inner op-root that they are not the root of all locally added nodes, but just the root of an add operation. (Or have scan_addition() find out by also scanning the parent of each add-op-root, which it does anyway when asked to find the repository path of the add, which it derives from the op-root's parent's BASE tree node ('s ancestors).) Because this indicator is only really needed for non-copy adds within a copy, it is tempting to abuse some other table row that is only used for copies. But I think we can do ourselves a favour by having an explicit indicator instead. Overloading values with special-case meanings is Not Good (tm). That case with svn_opt_revision_working I described in my original post is a good example of the snake pit that overloading can become. But ok, if we can hermetically seal off the special-case-overloading in internal API, that would be fine with me. (In a side note, with an explicit indicator we would not need to "fall off the top of the NG-WORKING tree" to detect the op-root. Not that it matters / whatever.) [...] > - The first place is svn_client__get_revision_number() with a revision of > svn_opt_revision_working or _base. This function returns a (much overloaded) > revision number, which is derived from the parent in some added-cases. In > above case (switched-away parent from a locally added child), deriving from > the parent is not possible anymore. Regardless, we do not want to look up > parents at all. > ... But chances are good that we can eliminate this case by refactoring a > few callers, properly defining svn_opt_revision_*'s meaning for added nodes > to be SVN_INVALID_REVNUM, and coining it an API error, or something. [...] ~Neels
signature.asc
Description: OpenPGP digital signature