> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> If you don't understand the new NodeRevId schema, read no further. If
> you don't know what svn_fs_link() is, see svn_fs.h.
>
> --
>
> While debugging the new NodeRevId work in the filesystem, I came
> across an interesting situation.
>
> Assume that I have a repository at revision 1 with a Greek tree.
> Recall, too, that "mutability" in the new schema means nothing more or
> less than "this node's TXN_ID portion of his node revision id is the
> same as the current transaction's TXN_ID". Now, consider, if you
> will, the following sequence of filesystem commands:
>
> /*** Get a root object for revision 1. ***/
> svn_fs_revision_root (&rev_root, fs, 1, pool);
>
> /*** Begin a transaction based on revision 1. ***/
> svn_fs_begin_txn (&txn, fs, 1, pool);
>
> /*** Get a root object for my transaction. ***/
> svn_fs_txn_root (&txn_root, txn, pool);
>
> /*** Make a new file, "/A/foo". ***/
> svn_fs_make_file (txn_root, "/A/foo", pool);
>
> At this point, my transaction contains all immutable nodes
> except /, /A, and /A/foo.
>
> /*** Now, make a link from revision 1's /A in /B. ***/
> svn_fs_link (rev_root, "/A", txn_root, "/B/A", pool);
>
> At this point, my transaction contains all immutable nodes except /,
> /A, /A/foo, and /B. Now, /B's entries list contains a reference to
> the immutable version of /A that was present in revision 1.
>
> Now here's the problem. If I try to do anything that requires that
> /B/A be made mutable (like, add a new file /B/A/bar), I run into
> Badness. Why? Well, the node revision ID for the mutable version of
> /A has already been created (back when we made /A/foo, remember?).
> And there is only one Correct "mutable" node revision ID for any given
> node revision in the filesystem.
>
> This was not a problem in the old system because when we went to make
> /A/B mutable, we would not have been limited to only one Correct
> successor node revision ID (we would have branched the node-rev-id at
> this point...which was one of the problems the new system set out to
> solve).
>
> I am inclined to think that the solution to this problem might be as
> simple as the removal of svn_fs_link() from the filesystem interface.
> Currently, svn_fs_link() is used only by the repository layer's
> reporter vtable() implementations, and by some test code (I think). I
> wonder if perhaps svn_fs_copy() is sufficient for all places where
> svn_fs_link() is currently used?
>
I'm not sure why the reporter layer uses this. IIRC when analyzing the
places that called filesystem code this TXN_ID that the reporter vtables
are building are aborted anyway. This seems wrongheaded and performance
horrible eventually. (In non-BDB land the database might be on a
different machine, etc...)
Since I don't know why the reporter code uses this, it's hard to propose
a correct solution. I would repeat that a representation of a hard link
in our new schema should be something like: "link <src path> <src
NodeRevisionPK>"
The link itself would have a brand new NodeID, the correct CopyID from
the link's parent directory (/B), and the current TxnID.
> Or, if we wanted to allow the primary use-cases to benefit from the
> speed of svn_fs_link(), we could reduce its prototype to just:
>
> svn_error_t *svn_fs_link (svn_fs_root_t *from_root,
> svn_fs_root_t *to_root,
> const char *path,
> apr_pool_t *pool);
>
> Note that the FROM_PATH and TO_PATH are now just PATH. This way we
> guarantee that the only way that two different paths can point to the
> same node revision ID is if that node revision is the child of a
> copied subtree, which is fine from the perspective of child cloning
> because the clones will each earn different COPY_IDs.
>
Due to the parents being here and a vacation weekend, I'll forbear even
pretending to understand what the above is saying, and analyze it. We
can chat either on Monday if you're in on IRC, or something. Otherwise,
I'll talk with you on Tuesday. However, I think I'd prefer my solution
above better. (Assuming that the reporter vtable implementation doesn't
drastically change design.)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 25 05:43:31 2002