On 10/12/07, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> Karl Fogel wrote:
> > 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.
>
> I was just trying to reduce code churn. Besides the new parameter, you
> would now have to call svn_ra_has_capability() every time you call
> svn_ra_do_update() (or switch(), diff(), ...) and
> svn_wc_crawl_revisions(). I think that's more intrusive than adding a
> new reporter function, and making svn_wc_crawl_revisons() use it directly.
While the exact solution to this particular situation could go a
different way, having general RA capability support is very exciting.
I can't count the number of times I've gone through the whole "we
could implement it this way, but there's no way for the client to know
if the server supports it, and it's easy to check with svnserve but a
pain with DAV" rigmarole...
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 13 07:57:45 2007