[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fourth tree: "INHERITED"

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 13 Apr 2010 12:41:44 -0400

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.


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


$ svn cp D T # at rev N
$ svn up D # D/f now appears
$ svn cp D/f T/f # at rev N+1


$ 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

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

Received on 2010-04-13 18:42:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.