svn_fs_link: incompatibility with new NodeRevId schema?

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?
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.
Karl?  Bill?  Greg?  Brane?  Anybody?!  Help...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org