Atomic renames TODO list

[Garrett Rooney <ro...@electricjellyfish.net>]

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

Re: Atomic renames TODO list

[Garrett Rooney <ro...@electricjellyfish.net>]

On 3/6/06, C. Michael Pilato <cm...@collab.net> wrote:
> 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.)

That makes sense.  I'm working on this part now FWIW.

One thing though.  I can see why we need a move type, but I'm not
convinced we actually need copy.  I can't actually find any places in
the current codebase where we do what you describe (look for add then
call svn_fs_copied_from) when we don't actually need the result from
svn_fs_copied_from for something or other.

As for storing the copy id, I imagine we can just have an optional
element at the end of the change skel to hold it, unless I'm missing
something it looks like that should work...

> >     * 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.

Ok, that makes sense.  I'll try to think about that part of the
problem some more.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Atomic renames TODO list

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand