On 3/14/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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().
Ok, I can sort of see that argument. Perhaps a
svn_fs_previous_location() or something like that. Closest copy could
be svn_fs_last_significant_relocation()... Although I'm more iffy on
that idea, since in that case it seems to clearly be more of a naming
problem than a "this function is not intended to do this" type
problem. The closest copy code seems to me to be clearly just as
interested in moves as it is in copies. Actually, now that I think
about it, I'm not convinced that copied_from should ignore move
information either, it seems like the question it asks ("What was the
previous location of this item?") is just as valid in the face of
moves as it is with copies, and we're simply dealing with the fact
that we named it poorly. Everyone who currently calls it would still
have to switch to the hypothetical new function that understands
moves, wouldn't they?
> 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.
That would be interesting, although to truly make svn_fs_copied_from
obsolete you'd also have to include info like the actual path/rev you
came from.
> 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?
I'm not sure about the discrepancy, but I do agree that merging the
data into the stuff you're given when you call into history makes
sense to me. Every place we consume history output and care about
copies we immediately call copied_from anyway.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 15 01:42:11 2006