I decided to take a look through some of the mod_dav_svn code to see if I
could find anything related to the mysterious FSFS issue Malcome and I have
been trying to track down. I ran across something interesting in
is_same_resource():
/* res2's fs_root object is now invalid. regenerate it using
the now-shared filesystem. */
if (res2->info->root.txn_name)
{
/* reopen the txn by name */
svn_error_clear(svn_fs_open_txn(&(res2->info->root.txn),
res2->info->repos->fs,
res2->info->root.txn_name,
res2->info->repos->pool));
/* regenerate the txn "root" object */
svn_error_clear(svn_fs_txn_root(&(res2->info->root.root),
res2->info->root.txn,
res2->info->repos->pool));
}
else if (res2->info->root.rev)
{
/* default: regenerate the revision "root" object */
svn_error_clear(svn_fs_revision_root(&(res2->info->root.root),
res2->info->repos->fs,
res2->info->root.rev,
res2->info->repos->pool));
}
It looks like the code is always expected to pass, or that we don't care about
the errors (I believe it's the first situation). However, I'm not sure that
the right thing to do is to proceed as if nothing had gone wrong. I assume
that res2->info->root.txn had something valid given it's previous file system
pointer. However, if we try to reopen the txn and fail for some reason, then
we attempt to use the txn tied to the original res2 file system pointer to
get the "root" object. I'm not sure whether that's an acceptable thing to
do. I assume not, otherwise there would have been no need to do this in the
first place. There are also other equally bad situations: the txn could be
opened, but opening the root fails; and we could fail to open the revision
root. All would pass this helper function claiming that they're the same
resource though.
Anyone with more mod_dav_svn foo able to comment on this? Seems like we're
counting on something happening, but we haven't documented that and I don't
believe that our APIs will guarantee success either.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 10 13:08:47 2005