On Fri, 17 Feb 2006, C. Michael Pilato wrote:
...
> I had three options:
>
> (1) Always spool all REPORT responses -- this was inefficient for
> checkouts, updates, switches, etc.
>
> (2) Give the caller the option of spooling the responses -- I couldn't
> think of a good RA-method-independent, un-implementation-detail-y
> way of exposing this option thru the RA interface.
>
> (3) Exploit the knowledge that Subversion clients tend only to do
> the full-text fetching stuff in diff and merge operations, and
> only spool REPORT responses for svn_ra_do_diff* invocations.
>
> I went with option #3. #2 would have been ideal if I'd been able to
> expose that parameter in some non-hacky way, but...
...
Mike, though it's certainly still somewhat implementation-detail-y,
the communication you describe for #2 can be accomplished through
content negotiation similar to what Dan Berlin used for svndiff1. On
the HTTP side, this would probably involve a custom HTTP header
(rather than piggy-backing on an existing Accept header). On the
custom SVN protocol side, a new capability announcement (see section
2.1 of subversion/libsvn_ra_svn/protocol).
Given the problem/performance implications of this case, introducing
this type of content negotiation seems like a reasonable compromise of
ideal behavior over a completely decoupled design.
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Wed Feb 22 07:38:45 2006