So I've been looking at issue #2398, since asserts in fsfs seem like a
bad thing, and I've wanted and excuse to get to know some of that code
for a while now...
The issue, is that something is calling svn_fs_copy with fs roots from
two separate fs objects, so the assert on line 1932 of
libsvn_fs_fs/tree.c fires. How could this happen you ask yourself?
Well, it turns out that it's because the URLs used for checkout and
later for merge don't match, specifically the case of the names of the
repository don't match.
So we go on a chase for callers of svn_fs_copy, to see where they're
getting their fs roots from. Since this is over DAV, it seems likely
that the cause is one of the direct calls to svn_fs_copy that happen
in mod_dav_svn.
So where do the fs roots come from for that? Well, they're created
from the filesystems in some dav resources. Where do those come from?
I mean since there are two separate resources each with their own
filesystem, you'd think they would be != all the time... But no, it
turns out they're almost always equal because they come out of a cache
(see lines 1406-1425 in mod_dav_svn/repos.c for details) which is
keyed off of the path to the repository, so if you end up with two
paths that point to the same repos (via case insensitivity, symlinks,
whatever) you can end up with different instances of the same
underlying filesystem.
I'm not entirely sure how to deal with this problem... If I knew this
was a case insensitive filesystem I could lowercase the paths before
using them as a cache key, but that's hard to know. I'd love to use
the UUID for the key, but I don't have the UUID when I need to do the
lookup, so that sort of defeats the purpose of having a cache in the
first place...
Maybe the assert needs to be smarter about comparing the two fs
pointers? That would require a svn_fs_equals or something, but we
don't seem to have anything like that now...
Any ideas?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 10 23:12:40 2006