On 3/6/06, C. Michael Pilato <cmpilato@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
Received on Tue Mar 7 00:48:00 2006