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

Atomic renames TODO list

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-03-06 22:02:16 CET

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

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