On Tue, Apr 13, 2010 at 11:57, Philip Martin <[email protected]> wrote: > Greg Stein <[email protected]> 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 f...@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
