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
