svn_fs_link: incompatibility with new NodeRevId schema?
Date: 2002-05-24 23:52:03 CEST
If you don't understand the new NodeRevId schema, read no further. If
-- 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: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Fri May 24 23:54:08 2002
This is an archived mail posted to the Subversion Dev mailing list.