[Fwd: Re: Atomic renames TODO list]

Inadvertantly mialed this to Garrett only. Sorry 'bout that.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

attached mail follows:

Garrett Rooney wrote:
> 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.

Okey dokey. If we don't need it, we don't need it.

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

Oh, yeah, of course it works. Just a shame our schema is so tortured
that we can't even convincingly pretend it has a shred of a clue about
good relational database design principles. :-)

In a similar vein, we need to be thinking about more than just change
actions, but about how they get collapsed. The code is designed to
collapsed all the changes that occur on a path to a single code, right? So:

   D + A = R
   A + D = (nothing)

Presuming we have a new 'V' for "moVe", what is D + V? It's an 'R',
really, but we need to carry that "is-a-move" info around, too. Perhaps
the svn_fs_path_change_t needs to grow a new field or two?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand