Re: fs-atomic-renames: what should svn_fs_copied_from do with a moved path?

Garrett Rooney wrote:
> My current question is about svn_fs_copied_from. Its current
> implementation is based entirely on looking at the node ids for the
> node in question and its predecessor. This gives the "wrong" answer
> for a moved node, since its node id doesn't actually change as part of
> the move, so the predecessor is in fact the grandparent in this case.
>
> So the question becomes, what answer should we be giving in this case?
> My instinct says that svn_fs_copied_from should give the same answer
> as we would have given in the case of a similar copy, but on the other
> hand this is a "move", not a "copy"...
>
> In addition, I'm kind of curious how to implement this efficiently.
> Currently we don't seem to have a good way to determine (from the
> available information) that a move took place without essentially
> doing the same sort of thing the history code does, but that seems
> awfully slow compared to what we're currently doing.

[Off-topic: Any chance you can recall the number of times I've frowned
lately on trying to wedge in atomic rename support to our existing schema
and API?]

So, I say move != copy. If svn_fs_copied_from is returning anything other
than [None, SVN_INVALID_REVNUM] for a moved path, that's wrong. We may need
a new API here, and might be in the same boat for svn_fs_closest_copy().

*** WARNING: I'll be, uh, thinking aloud from this point on. ***

In the past I was bothered that I didn't expose some bits from the
history interface that would indicate that a segment of history contained a
copy operation (this is a problem from the get_locations algorithm). Now
I'm wondering if the history tracing algorithm shouldn't grow the ability to
return not just the previous path and revision along a node's history when
traversed backwards, but also some indication of whether or not that
"interesting history point" is due to a copy or move, and/or just a simple
modification to the resource. That might make svn_fs_copied_from() obsolete.

Now, you might notice that calling svn_fs_copied_from() on a node, and
called the history code to find it's previous location, will not necessary
result in the same answer. Consider:

   r2: A /file.txt
        A /otherfile.txt
   r3: M /file.txt
   r4: M /someotherfile.txt
   r5: A /copiedfile.txt (from /file.txt, r4)

Calling svn_fs_copied_from() on /copiedfile.txt@5 will return [/file.txt,
4]. The history code will, however, claim that previous interesting history
point is [/file.txt, 3]. Of course, those two are the same node-revision,
but are we willing to allow this discrepancy?

(Note that for moves, this doesn't really come into play, because it is
impossible to "move" something from any revision except the previous one, a
detail ensured by the fact that a move is just a tweak to a parent
directory's entries list.)

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand