Essentially, "yes".
One annoying thing about FS is that we are really sloppy about whether
or not "node" refers to a "a particular node (vertex) on the DAG" or
"a set of such nodes which have historical relations to each other".
For the purposes of this message, I will use the former definition.
Also I basically refuse to refer to "X.Y.Z" node IDs when discussing
the abstract FS layer, since they are an implementation detail (and
differ between BDB, FSFS formats 1-2, FSFS formats 3-4, the Bigtable
backend, etc).
Whenever a new node is added to the DAG and committed, it is created
at a certain path (because it was created with svn_fs_make_file,
svn_fs_make_dir, svn_fs_copy, svn_fs_change_node_prop,
svn_fs_apply_text[delta], etc) and at a certain revision (because
that's when it was committed). These are the values returned by
svn_fs_node_created_path and svn_fs_node_created_rev: they are a
function of the *node on the DAG that you are looking at*. The
arguments they take (path and rev) are used to locate it. The path
used for locating the node and the node's created path differ in the
case of copies. For example, let's say we have:
r5: create trunk/foo
r8: copy trunk_at_6/ to branch/
Now the created path and rev of (branch/foo, 10) is (trunk/foo, 5)
since that *node* in the DAG hasn't been touched since then. If we
then have
r12: edit branch/foo
then the created path and rev of (branch/foo, 12) will be (branch/foo,
12) since we create a new DAG node for the edit.
The origin node rev means: first resolve the path_at_rev as usual to find
a node on the DAG. Then follow edited-from or copied-from links
backwards until you get to the "origin" node. The easy thing to
remember is: only svn_fs_make_file/svn_fs_make_dir matters for
svn_fs_node_origin_rev; everything else just copies the origin rev
from the predecessor node. This is really easy to see in FSFS formats
3 and 4, where the "origin node rev" is encoded directly in the "node
ID" (what you might refer to as the X in X.Y.Z, I think). You might
consider doing that if you're designing a new schema for a new
backend, though it does depend on the FSFS commit-finalization rewrite
step.
--dave
On Tue, Apr 28, 2009 at 11:49 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> Jon and I are trying to understand the difference between
> svn_fs_node_created_rev() and svn_fs_node_origin_rev(). From reading
> through code, I *think* I understand, but I'd like someone (cmpilato?
> pburba?) to verify that I've got it right.
>
> svn_fs_created_rev() is the "dumb" function. It just notices when a
> specific node first came into existence, paying no attention to
> "previous node" pointers or copyfrom metadata. In other words, it
> only notices the third component in the X.Y.Z id string and says, "oh,
> this node was created in transaction Z, which was committed as
> revision R. So the created-rev is R."
>
> svn_fs_node_origin() is the "smart" function which notices
> copies/renames. First it walks backwards through all the
> copyfrom-metadata that it can find, until it finds some ancestor which
> was *didn't* come into existence via a copy event. Then it walks
> backwards though the previous-node pointers until it finds the very
> first version of the object (presumably created by either an add or
> replace *without* copyfrom history.) It then returns that 'origin'
> revision.
>
> I suspect there's something slightly wrong with my explanation here,
> since I don't grok how svn_fs_node_created_path() fits into this
> universe: it seems to be paired with created_rev(), but that implies
> that those two functions (as a pair) are paying attention to
> copies/renames somehow...
>
> Can someone de-confuse us?
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1967056
>
--
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1967372
Received on 2009-04-28 21:16:17 CEST