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

Re: Atomic renames TODO list

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-03-06 22:21:19 CET

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

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