[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-03-14 02:13:43 CET

So after (hopefully) making the history tracing code work correctly in
the face of moves last week, I started out today trying to figure out
what other APIs in the fs layer are potentially broken for them.

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.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 02:14:11 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.