Karl Fogel <kfogel@red-bean.com> writes:
> Vlad Georgescu <vgeorgescu@gmail.com> writes:
>> When I suggested a server_supports_depth() function, I was thinking of
>> putting it in the reporter vtable, so that svn_wc_crawl_revisions
>> wouldn't have to be revved to take a 'depth_compatibility_trick'
>> argument. Instead, it would call reporter->server_supports_depth().
>
> For everyone, here's what Vlad and I discussed in IRC:
>
> [...]
Vlad, I've thought more about this, and I'm uncomfortable putting a
new callback into the reporter vtable for this.
The situation is that libsvn_client (and thence libsvn_wc) need to
know whether or not the server supports depth; depending on whether it
does or not, they will drive the report in a slightly different way.
Although the reporter is sort of involved here (since it's being
driven), I'm not sure this new vtable callback would be consistent in
spirit with what the reporter does. Every other callback in the
reporter is unidirectional: it pushes data *to* the server. Now we'd
be adding a callback that gets information from (or "about") the
server. But I feel like we'd just be doing it just to avoid adding a
new parameter to svn_wc_crawl_revisions3(), rather than because it
makes architectural sense.
Since svn_ra_session_t is the client-side representation of the
server, that's what libsvn_client/libsvn_wc should query for
capabilities, IMHO.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 13 01:59:22 2007