On Tue, Sep 30, 2008 at 8:09 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Tue, Sep 30, 2008 at 6:47 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
>> <sussman_at_red-bean.com> wrote:
>>>> A little confused by this last sentence. There are three points
>>>> included in it. Wouldn't the first one be the only one that required
>>>> mod_dav_svn? It seems like this new library could work as well, or
>>>> better with the other two.
>>>
>>> You're right. See the other thread with comments from gstein -- he's
>>> pushing for cacheability as a feature, and there's no reason a
>>> well-designed new protocol couldn't be designed for that (or write
>>> proxying).
>>
>> An advantage to the current ra_serf "GET-based" design, besides
>> caching, is access logging. It is very easy to see how often specific
>> resources are being accessed. Current REPORT-based operations mask
>> this. We had one customer (perhaps it will only ever be one) that
>> wanted this.
>
> I think this indicates that the logging should be pushed down into the
> fs layer, rather than living solely at the server-level.
>
> When somebody implements detailed logging for svnserve (inevitably),
> they're going to run into the same problem, and I'm pretty sure
> they're not going to redesign the protocol to make lots of little
> cacheable fetches, rather than single streaming responses.
There is logging for svnserve in trunk. To my knowledge it is the
same sort of operational logging that we have in Apache. But your
point is fair nonetheless.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 02:10:52 CEST