I have a [possibly dumb] question about the compression done over http[s]
connections with subversion and apache. I searched and read the manual,
but still couldn't find an explanation. I browsed the source as well.
Compression from the server to the client seems to use mod_deflate, set up
with a SetOutputFilter DEFLATE in the svn Location section (according to
the subversion INSTALL). However, the docs don't say anything about using
the SetInputFilter DEFLATE option, which would seem to be necessary for
client to server compression, if it's done through the same
mechanism. Also, neon only seems to have a decompression facility, not
compression unless I missed it (even though the file is called
ne_compress.c). The libsvn_subr directory has a bidirectional compressed
stream object, to thicken the plot.
So, is compression done on the subversion side, or on the neon/http side,
and is it different for server->client vs. client->server?
Hope that question makes sense. Basically, I'm wondering why I need to
SetOutputFilter but not SetInputFilter, or if subversion and mod_dav_svn
are compressing themselves and then I'm double-compressing server->client
with mod_deflate.
Confused,
Chris
PS. Thanks for what looks to be a great revision system. I've got it
built and running over https on an Alpha server running Debian and the
build went fine. The only hitch was the mod_authz_svn got plopped in the
httpd.conf ahead of the mod_dav_svn line, which obviously didn't
work. Hopefully I will be able to replace CVS post haste. I worry a bit
about CPU/memory load on the server relative to CVS, since the machine is a
bit wimpy by today's standards.
PPS. Special bonus question that I haven't had time to look in the source
to answer: for the Win32 client, is there any way to use the
%HOME%\.subversion directory rather than \Documents and Settings\blah blah
blah\Subverion directory. Maybe if the latter doesn't exist but the former
does or something...it's much more convenient to use %HOME% if you're
already using it for a lot of other stuff.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 08:12:04 2003