I have a patch (just about ready to commit) which makes
svn_ra_check_path() return a full svn_dirent_t, rather than just an
svn_node_kind.
I've had to tweak all three RA layers for this, as well as tweak 17
callers in libsvn_client to use 'dirent->kind' rather than just 'kind'.
The reason for this change is
* it makes svn_ra_check_path() into a real stat-like call, which is
Nice Thing.
* it makes 'svn info URL' (and 'svn ls URL') more efficient. No
need to fetch a thousand sibling dirents just to learn about one
object.
In any case, I've run into several problems. In the case of ra_dav, it
turns out that all we need to do is send a depth-0 PROPFIND request...
it's guaranteed to succeed. In the case of ra_svn, it may or may not
get back an svn_dirent_t from the server. If the server is old, then
we just don't get the thing. What to do in this case?
There are two possible things that could happen:
1. Have ra_svn return a "feature not implemented" error, and then
make 17 libsvn_client callers deal with this possiblity... presumably
by making all of these callers run svn_client_ls(parentURL) to
inefficiently fetch the dirent.
2. Teach ra_svn_check_path() to return the dirent unconditionally, by
falling back on some similar strategy. It would need to call
ra_svn_get_dir() on the parent URL. This is certainly less coding
work.
Both strategies have ugly implications for users. If they use a 1.2
client to talk to a 1.1 svnserve, suddenly a bunch of common commands
are now fetching bunches of dirents under the hood, just to stat a
single URL item. If a directory is large, common commands might be
noticeably slower. :-(
Also, the specific problem with strategy #2 above is that if the RA
session is already opened to a file-URL, there's no way to "re-anchor"
the RA session on the parent URL. It would mean ra_svn_check_path()
would be internally creating a whole new RA session (calling
ra_svn_open()). Pretty icky.
I seem to be in a twisty maze of dead-ends. Can anyone help me find my
way out of here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 2 22:27:49 2005