So I'm looking at the todo list on the fs-atomic-renames branch, and
since the first two entries sound low level and complex, I decided to
look at number three, it being the first thing on the list that made
sense at first glance ;-)
* Add new copy and move changes table items. 'Move' is brand new,
so there's no compat code. For 'copy', code that today asks "Is
this a copy?" (by asking, "Is this an add with a non-NULL response
from svn_fs_copied_from()?") will be able to have quicker access
to that answer, and fall back to the old query where necessary.
The first thing that jumps to mind is what does a record for a move
look like? Are we just talking about the destination of such an
operation? Or do we really want two changes entries, one for move
source and one for move destination?
As for the other items on the list, I have a few questions...
* Teach the copy ID inheritance code how to deal with moves. Not
sure how easy/tricky this will be.
How is this different from what get_copy_inheritance is already doing?
It seems to deal with moves just fine now, or am I missing some edge
case?
* Make sure that we don't carry around delayed move ID information
on entries where not necessary.
In what case is delayed move information no longer necessary? Once
we've already been moved onto a new branch in the history tree by a
parent directory using it's delayed move ID info or something like
that?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 6 22:02:57 2006