On Tue, Apr 13, 2010 at 11:57, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>...
>> As you note layer, operations on a node cannot be layered/stacked. You
>> can modify the operation at a node, but you can't layer over it.
>> Columns like copyfrom_* and moved_* are about the operation, rather
>> than the node's data. It says *how* the node got there, rather than
>> talk about the node itself.
>
> I'm confused by the copy of a mixed revision working copy, say a
> directory a revision N and a file at revision N+1. We need a working
> node for the directory, to store N, and a working node for the file,
> to store N+1.
Yes.
> Now delete the copied file and replace with something
> else, that overwrites the N+1 in the working node. Now reverting the
> replace cannot restore the original copy since the N+1 is gone, so
> what does the copied file look like, revision N?
That is the only option, and it would be presence=excluded since we
don't have revision N of the thing. (or maybe presence=absent)
Oh hell... we don't even know if the file exists at N.
Consider:
$ svn cp D T # at rev N
$ svn up D # D/f now appears
$ svn cp D/f T/f # at rev N+1
vs
$ svn cp D T
$ svn rm T/f
$ svn up D
$ svn cp D/f T/f
When using *two* copy operations, we have enough information in
WORKING_NODE to restore file_at_N (or omit it because it wasn't there).
But with a copy of a mixed-rev subtree, the *source* doesn't have
enough information for us do perform the kinds of reverts above.
I'll also note that we can run into similar problems with a switched
source. The repos_relpath changes, rather than the revision; thus, the
WORKING_NODE would need to generate some additional copyfrom roots to
denote the changes.
> I suppose that is
> acceptable, the original copy, prior to the replace, was not a simple
> copy. We could argue that the copy of a mixed revision working copy
> is already a bunch of roots. Suppose I delete the copied file at N+1
> and then revert. Does it go back to N+1 or N?
Reverting a replace or reverting a delete are the same thing, in this
scenario. You're reverting an operation, but the ancestor operation
doesn't have enough information to reconstruct a node.
Okay. I think that I have an idea.
I originally suggested the following columns for NODE_DATA:
kind, [checksum], changed_*, properties, [symlink_target]
The repos_id, repos_relpath, and revnum columns from BASE_NODE were
omitted because WORKING nodes do not have a location in the repository
(yet). However, what if we put those in? For nodes corresponding to
the BASE_NODE table (op_depth==0), these are the *true* repository
locations. For op_depth>0, these are copied/moved-here source
locations.
This would enable us to represent a mixed-rev and switched copy/move
source, and a single operation root in the WORKING_NODE table.
In the above scenarios, if you replace a child, then it creates a new
operation root (which is later revertable), and it establishes a new
layer in NODE_DATA (preserving the original mixed/switched source).
>...
> So if I copy a directory with children is there a working node for
> each child?
I would say "yes", so that we have a place to store translated_size
and last_mod_time. Not entirely sure.
I think we need every child for deleted nodes. We can't alter the
presence in NODE_DATA to record a delete, since we need that original
info to revert the delete (e.g. NODE_DATA.presence may indicate
excluded/absent/not-present nodes).
Your thoughts on this piece would be welcome. I'm pretty sure we need
them, but am not (yet) fully confident. Some more brain-percolation
time is needed...
Cheers,
-g
Received on 2010-04-13 18:42:16 CEST