Garrett Rooney wrote:
> 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?
Our existing schema is lacking here. I think we only *need* to store
the destination (just as we do with copies) and the copy ID (as we can
fetch the source indirectly from the copies table). But we don't really
have a "column" for the copy ID. (Copies simply use the copy-ID
component of the changed node's node-revision-ID, but moves don't change
their target's copy-ID immediately.)
> 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?
I ... uh ... can't remember enough about my frame of mind when composing
that TODO item. Sorry.
> * 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?
I don't know all the cases, but it was stuff like the following that had
me thinking about this (and worrying about its complexity):
move .../some/subdir .../some/new-subdir
copy .../some .../other
The move would leave "some" with an entry for "new-subdir" that has a
delayed move ID. When we then copy "some" later, what happens to that
delayed move ID? I haven't the answers.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Mar 6 22:25:34 2006