You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Kimdon <dw...@debian.org> on 2003/10/19 22:55:22 UTC
[RFC] : full-text instead of vdelta against empty bytestream
Hi,
The included patch removes vdelta calculation when we are sending the
full text of the target. I'm still not sure of the over-all benefit
of this and stat_tests.py 10 is failing, not sure why yet. There is
definately a dramitic CPU-time savings wherever the vdelta no longer
needs to be calculated, but we aren't always CPU-bound. I left some
data and the script I used to create it up at
http://people.debian.org/~dwhedon/svn-tests/ for those who are
curious.
Comments and critisism welcome,
-David
--------------------------------------------
For assorted operations don't create a vdelta against an empty byte stream.
Instead, send the full text directly to the consumer. Note that this doesn't
require any changes on the consumer side and as such doesn't introduce any
client-server incompatibilities.
* subversion/libsvn_delta/text_delta.c
(send_string) : New function. This function does most of what
svn_txdelta_send_string() needs to do with the notable exception of sending
the final NULL to the window handler.
(svn_txdelta_send_string) : Use a new helper function send_string to do most
of the work and then send the final NULL to the window handler.
(svn_txdelta_send_stream) : Rather than creating a diff against an empty
byte stream send the stream directly to the handler as new data for
the target.
* subversion/libsvn_repos/delta.c
(delta_files) : If there is no source file send the target full-text using
svn_txdelta_send_stream().
Index: subversion/libsvn_repos/delta.c
===================================================================
--- subversion/libsvn_repos/delta.c (revision 7448)
+++ subversion/libsvn_repos/delta.c (working copy)
@@ -583,26 +583,48 @@
if (c->text_deltas)
{
- /* Get a delta stream turning an empty file into one having
- TARGET_PATH's contents. */
- SVN_ERR (svn_fs_get_file_delta_stream
- (&delta_stream,
- source_path ? c->source_root : NULL,
- source_path ? source_path : NULL,
- c->target_root, target_path, subpool));
- }
+ if (source_path)
+ {
+ /* Get a delta stream that turns SOURCE_PATH into a file with
+ TARGET_PATH's contents. */
+ SVN_ERR (svn_fs_get_file_delta_stream
+ (&delta_stream,
+ source_path ? c->source_root : NULL,
+ source_path ? source_path : NULL,
+ c->target_root, target_path, subpool));
+
+ SVN_ERR (svn_fs_file_md5_checksum
+ (source_digest, c->source_root, source_path, subpool));
- if (source_path)
- {
- SVN_ERR (svn_fs_file_md5_checksum
- (source_digest, c->source_root, source_path, subpool));
+ source_hex_digest = svn_md5_digest_to_cstring (source_digest,
+ subpool);
+
+ SVN_ERR (send_text_delta (c, file_baton, source_hex_digest,
+ delta_stream, subpool));
+ }
+ else
+ {
+ /* Send TARGET_PATH full-text, no delta needed. */
+ svn_stream_t *stream;
+ svn_txdelta_window_handler_t delta_handler;
+ void *delta_handler_baton;
+
+ /* XXX -This handler will understand when we send it full-text,
+ * the apply_textdelta name is a bit misleading. */
+ SVN_ERR (c->editor->apply_textdelta
+ (file_baton, NULL, subpool,
+ &delta_handler, &delta_handler_baton));
+
+ SVN_ERR (svn_fs_file_contents (&stream, c->target_root,
+ target_path, subpool));
- source_hex_digest = svn_md5_digest_to_cstring (source_digest,
- subpool);
+ SVN_ERR(svn_txdelta_send_stream (stream,
+ delta_handler,
+ delta_handler_baton,
+ NULL,
+ subpool));
+ }
}
-
- SVN_ERR (send_text_delta (c, file_baton, source_hex_digest,
- delta_stream, subpool));
}
/* Cleanup. */
Index: subversion/libsvn_delta/text_delta.c
===================================================================
--- subversion/libsvn_delta/text_delta.c (revision 7448)
+++ subversion/libsvn_delta/text_delta.c (working copy)
@@ -522,11 +522,11 @@
/* Convenience routines */
-svn_error_t *
-svn_txdelta_send_string (const svn_string_t *string,
- svn_txdelta_window_handler_t handler,
- void *handler_baton,
- apr_pool_t *pool)
+
+static svn_error_t *
+send_string (const svn_string_t *string,
+ svn_txdelta_window_handler_t handler,
+ void *handler_baton)
{
svn_txdelta_window_t window = { 0 };
svn_txdelta_op_t op;
@@ -545,6 +545,18 @@
/* Push the one window at the handler. */
SVN_ERR ((*handler) (&window, handler_baton));
+ return SVN_NO_ERROR;
+}
+
+
+svn_error_t *
+svn_txdelta_send_string (const svn_string_t *string,
+ svn_txdelta_window_handler_t handler,
+ void *handler_baton,
+ apr_pool_t *pool)
+{
+ SVN_ERR (send_string (string, handler, handler_baton));
+
/* Push a NULL at the handler, because we're done. */
SVN_ERR ((*handler) (NULL, handler_baton));
@@ -557,29 +569,41 @@
unsigned char *digest,
apr_pool_t *pool)
{
- svn_txdelta_stream_t *txstream;
- svn_error_t *err;
+ apr_size_t len = SVN_STREAM_CHUNK_SIZE;
+ apr_md5_ctx_t context;
+ svn_string_t string;
+ char *buf;
+
+ if (digest)
+ apr_md5_init (&context);
+
+ buf = apr_palloc (pool, SVN_STREAM_CHUNK_SIZE);
+ string.data = buf;
+
+ len = SVN_STREAM_CHUNK_SIZE;
+ SVN_ERR (svn_stream_read (stream, buf, &len));
- /* ### this is a hack. we should simply read from the stream, construct
- ### some windows, and pass those to the handler. there isn't any reason
- ### to crank up a full "diff" algorithm just to copy a stream.
- ###
- ### will fix RSN. */
-
- /* Create a delta stream which converts an *empty* bytestream into the
- target bytestream. */
- svn_txdelta (&txstream, svn_stream_empty (pool), stream, pool);
- err = svn_txdelta_send_txstream (txstream, handler, handler_baton, pool);
-
- if (digest && (! err))
+ while (len)
{
- const unsigned char *result_md5;
- result_md5 = svn_txdelta_md5_digest (txstream);
- /* Since err is null, result_md5 "cannot" be null. */
- memcpy (digest, result_md5, MD5_DIGESTSIZE);
+ if (digest)
+ apr_md5_update (&context, buf, len);
+
+ string.len = len;
+
+ SVN_ERR (send_string (&string, handler, handler_baton));
+
+ len = SVN_STREAM_CHUNK_SIZE;
+
+ SVN_ERR (svn_stream_read (stream, buf, &len));
}
- return err;
+ if (digest)
+ apr_md5_final (digest, &context);
+
+ /* Push a NULL at the handler, because we're done. */
+ SVN_ERR ((*handler) (NULL, handler_baton));
+
+ return SVN_NO_ERROR;
}
svn_error_t *svn_txdelta_send_txstream (svn_txdelta_stream_t *txstream,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2003-11-04 at 17:48, C. Michael Pilato wrote:
> > > That may be the reason, but I don't think it actually speeds up read
> > > operations to use a plain text.
> >
> > Sorry, but I've read this three times, and I can't find an immediate
> > reason why this statement would be correct. I can only assume that
> > you mean that in the overall cost of hitting the database, perhaps the
> > additional overhead of reading from a delta-versus-empty-file is lost
> > in the noise?
>
> 1) As mbk points out, we'll be reading fewer blocks from the database.
> Undeltification is cheap; disk I/O is expensive.
>
> 2) If we're retrieving any revision other than the head revision, we
> already have to perform an undeltification operation. I think "combine
> N deltas and apply the result to plaintext P" is probably about as slow
> as "combine N+1 deltas and apply the result to the empty string."
>
> 3) If David succeeds in his work, we will save a deltification step for
> checkouts of the head, without having to sacrifice compression. Since
> deltification is relatively expensive, and checkouts of the head are
> common in many contexts, that's a big win.
>
> Actual measurements would be better than my speculations, of course.
Ah. Now, see, that's the kinda data that makes an otherwise
unintuitive claim seem quite rational! Thanks, Greg.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-11-04 at 17:48, C. Michael Pilato wrote:
> > That may be the reason, but I don't think it actually speeds up read
> > operations to use a plain text.
>
> Sorry, but I've read this three times, and I can't find an immediate
> reason why this statement would be correct. I can only assume that
> you mean that in the overall cost of hitting the database, perhaps the
> additional overhead of reading from a delta-versus-empty-file is lost
> in the noise?
1) As mbk points out, we'll be reading fewer blocks from the database.
Undeltification is cheap; disk I/O is expensive.
2) If we're retrieving any revision other than the head revision, we
already have to perform an undeltification operation. I think "combine
N deltas and apply the result to plaintext P" is probably about as slow
as "combine N+1 deltas and apply the result to the empty string."
3) If David succeeds in his work, we will save a deltification step for
checkouts of the head, without having to sacrifice compression. Since
deltification is relatively expensive, and checkouts of the head are
common in many contexts, that's a big win.
Actual measurements would be better than my speculations, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2003-11-04 at 16:27, kfogel@collab.net wrote:
> > David Kimdon <da...@kimdon.org> writes:
> > > The next idea is to use the fact that we have deltified youngest
> > > revisions
>
> > I thought we *don't* have deltified youngest revisions
>
> We don't; the first part of his mail was about changing that.
I follow that.
> > and the reason we don't deltify them is precisely to speed up read
> > operations.
>
> That may be the reason, but I don't think it actually speeds up read
> operations to use a plain text.
Sorry, but I've read this three times, and I can't find an immediate
reason why this statement would be correct. I can only assume that
you mean that in the overall cost of hitting the database, perhaps the
additional overhead of reading from a delta-versus-empty-file is lost
in the noise?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-11-04 at 16:27, kfogel@collab.net wrote:
> David Kimdon <da...@kimdon.org> writes:
> > The next idea is to use the fact that we have deltified youngest
> > revisions
> I thought we *don't* have deltified youngest revisions
We don't; the first part of his mail was about changing that.
> and the reason we don't deltify them is precisely to speed up read operations.
That may be the reason, but I don't think it actually speeds up read
operations to use a plain text.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Nov 05, 2003 at 12:22:20AM +0100, David Kimdon wrote:
>
> Another theory is to keep the revisions in a form that is easily
> digestable by certain operations that we would like to speed up[1].
> The expectation is that other operations will not be inordinately
My theory is that disk is the slowest thing around, and that reading
50% fewer blocks off of disk is going to be roughly 50% faster.
If we get Daniel Berlin's delta routines in, the speedup would be
even more.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by David Kimdon <da...@kimdon.org>.
On Tue, Nov 04, 2003 at 03:27:06PM -0600, kfogel@collab.net wrote:
> David Kimdon <da...@kimdon.org> writes:
> > The next idea is to use the fact that we have deltified youngest
> > revisions to speed up checkout and export. I have a broken (but
> > complete, maybe . . .) patch that does this, still working through the
> > details.
>
> I thought we *don't* have deltified youngest revisions,
true.
> and the reason
> we don't deltify them is precisely to speed up read operations.
That's the theory as I understand it as well.
> Am I missing something?
Another theory is to keep the revisions in a form that is easily
digestable by certain operations that we would like to speed up[1].
The expectation is that other operations will not be inordinately
slowed thanks to the delta combiner. On checkout and export of head
(a fairly common operation?) or when a new file is added to update we
always create delta windows against an empty byte-stream. That delta
takes a lot of CPU cycles to calculate. If instead of needing to
create that textdelta we needed to only convert it from svndiff to
textdelta then CPU time spent on the server will be much less.
That's the theory anyway,
-David
[1] : I've also been toying with the idea of multiple representations
of the same node-revision. This idea might be too much along the
lines of representation undeltification, i.e. not as much of a
performance enhancement as hoped for. Anyway, the fs can choose
which sub-representation it wants to use based on the operation
requested, consider for a given node:
- update from r3 to r10 - fs doesn't have that sub-representation, it
calculates it and stores a new sub-representation, no speedup here
- update from r6 to r10 - fs calculated that yesterday, and saved the
svndiff sub-representation, a bit of conversion (into textdelta
format) and it is off to the consumer more quickly than if it needed
to do the calculation from scratch
- checkout, export of any version - fs always keeps a
sub-representation of the file against an empty-bytestream so this
can be speedy too, but every version fulltext, ouch, that's a lot of
space.
etc.
In this case we are using more disk space and saving CPU time. There
would need to be a process of pruning sub-representations that haven't
been used in a while to avoid repository bloat, or course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by kf...@collab.net.
David Kimdon <da...@kimdon.org> writes:
> The next idea is to use the fact that we have deltified youngest
> revisions to speed up checkout and export. I have a broken (but
> complete, maybe . . .) patch that does this, still working through the
> details.
I thought we *don't* have deltified youngest revisions, and the reason
we don't deltify them is precisely to speed up read operations.
Am I missing something?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by David Kimdon <da...@kimdon.org>.
On Tue, Oct 21, 2003 at 09:47:19PM -0400, mark benedetto king wrote:
> I wish I could take credit for this idea, but Greg Hudson pointed out
> on IRC that we could store the youngest revisions of files as deltas
> against the empty bytestream.
>
> Then there would be no CPU cost to the compression; it would be already
> done, and the one-time-per-commit cost amortized over the many checkouts.
>
> I think this would also cut down repository size, since the fulltexts would
> not exist anywhere in the repository. The smaller size could conceivably
> improve performance, since there would be fewer pages to read for certain
> operations, higher chance that any particular page would be in cache, etc.
I have now two different patches[1] to store the youngest revisions as
deltas against the empty bytestream.
Approach 1: Do the youngest rev deltification inside
deltify_mutable(), that is when the rest of the deltification occurs.
This means the representation is first stored as fulltext, then later
compressed (deltified).
Approach 2: Never creates a fulltext, rather the youngest revision is
a delta against an empty byte stream from when that representation is
created (the beginning of that node revision's life) so nothing needs
to be done when the rest of the deltification occurs. This one is
conceptually cleaner but my implementation currently has some rough
edges.
Approach 2 saves on disk space over the current full text storage.
Approach 1 does not, I think it has something to do with the way the
database works, the fulltext hangs out in the database file (though
not actually as part of the database, i.e. db_dump doesn't show the
fulltext strings, but a hexeditor does) for a revision or so after it
isn't needed (if anyone can explain that, I'm eager to know the
details).
Neither approach has a very negative effect on performance, but
neither approach has a very positive effect, a mixed bag in both
cases.
The next idea is to use the fact that we have deltified youngest
revisions to speed up checkout and export. I have a broken (but
complete, maybe . . .) patch that does this, still working through the
details.
David
[1] : Neither of them are in a presentable form at present.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by mark benedetto king <mb...@lowlatency.com>.
On Tue, Oct 21, 2003 at 10:57:20PM +0200, David Kimdon wrote:
> On Tue, Oct 21, 2003 at 12:16:04AM -0400, Daniel Berlin wrote:
> >
> > On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
> >
> > >Hi,
> > >
> > >The included patch removes vdelta calculation when we are sending the
> > >full text of the target.
> >
> > Except that vdelta against an empty bytestream will be quite a bit
> > smaller.
>
> true. I did a few tests and the vdelta against empty bytestream
> compresses data to about one half the original size. This makes this
> optimization only interesting to a rather niche market. Anyone who
> wants to lower CPU load on the producer and send more data would like
> it, but I'm not sure who would want to double the data sent.
>
> >
> > This should probably be controlled by some option, since it's not
> > always a win for everyone (it depends on your network connection speed,
> > etc)
>
> At this point I'm thinking if it isn't an all around win then it
> should probably not happen. I spent some time looking at trying to
> get some less CPU intensive compression that the consumer would still
> be happy with, but as Greg already pointed out, there isn't an obvious
> way of doing that.
I wish I could take credit for this idea, but Greg Hudson pointed out
on IRC that we could store the youngest revisions of files as deltas
against the empty bytestream.
Then there would be no CPU cost to the compression; it would be already
done, and the one-time-per-commit cost amortized over the many checkouts.
I think this would also cut down repository size, since the fulltexts would
not exist anywhere in the repository. The smaller size could conceivably
improve performance, since there would be fewer pages to read for certain
operations, higher chance that any particular page would be in cache, etc.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by David Kimdon <dw...@debian.org>.
On Tue, Oct 21, 2003 at 12:16:04AM -0400, Daniel Berlin wrote:
>
> On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
>
> >Hi,
> >
> >The included patch removes vdelta calculation when we are sending the
> >full text of the target.
>
> Except that vdelta against an empty bytestream will be quite a bit
> smaller.
true. I did a few tests and the vdelta against empty bytestream
compresses data to about one half the original size. This makes this
optimization only interesting to a rather niche market. Anyone who
wants to lower CPU load on the producer and send more data would like
it, but I'm not sure who would want to double the data sent.
>
> This should probably be controlled by some option, since it's not
> always a win for everyone (it depends on your network connection speed,
> etc)
At this point I'm thinking if it isn't an all around win then it
should probably not happen. I spent some time looking at trying to
get some less CPU intensive compression that the consumer would still
be happy with, but as Greg already pointed out, there isn't an obvious
way of doing that.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by David Kimdon <dw...@debian.org>.
On Tue, Oct 21, 2003 at 09:00:26PM -0400, Daniel Berlin wrote:
> > in ways I shudder to suspect might be incompatible with older
> >clients/servers?
> If it is, something is designed wrong. You should be able to switch
> between them on a per-window basis if you really wanted to.
right, in theory (full-text is just an add and is already supported by
the consumer) and in practice (I tested old-server<->new-client and
new-server<->old-client just to make sure) there is no compatability
problem.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by Daniel Berlin <db...@dberlin.org>.
On Oct 21, 2003, at 7:58 PM, Jack Repenning wrote:
> At 12:16 AM -0400 10/21/03, Daniel Berlin wrote:
>> On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
>>
>>> Hi,
>>>
>>> The included patch removes vdelta calculation when we are sending the
>>> full text of the target.
>>
>> Except that vdelta against an empty bytestream will be quite a bit
>> smaller.
>>
>> This should probably be controlled by some option, since it's not
>> always a win for everyone (it depends on your network connection
>> speed, etc)
>
> /me 's teeth set on edge
>
> Eeerrrrraaaggggg ... an option? because the optimal behavior is too
> hard for the code to predict?
It isn't, actually, but that's okay.
It is streamy, and it can tell how long it's taken so far, so it can
tell whether the connection is slow and vdelta the rest of it in the
middle of the whole thing.
It just doesn't.
> so the poor user should take a guess?
Kinda like how cvs -z<something> it taking a guess?
> even though he has even less info?
People know whether they are on a modem or not.
> changing the server code, and the protocol, and the client?
Uh, It should handle fulltext and deltas equally well.
> in ways I shudder to suspect might be incompatible with older
> clients/servers?
If it is, something is designed wrong. You should be able to switch
between them on a per-window basis if you really wanted to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by Jack Repenning <jr...@collab.net>.
At 12:16 AM -0400 10/21/03, Daniel Berlin wrote:
>On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
>
>>Hi,
>>
>>The included patch removes vdelta calculation when we are sending the
>>full text of the target.
>
>Except that vdelta against an empty bytestream will be quite a bit smaller.
>
>This should probably be controlled by some option, since it's not
>always a win for everyone (it depends on your network connection
>speed, etc)
/me 's teeth set on edge
Eeerrrrraaaggggg ... an option? because the optimal behavior is too
hard for the code to predict? so the poor user should take a guess?
even though he has even less info? changing the server code, and the
protocol, and the client? in ways I shudder to suspect might be
incompatible with older clients/servers? this close to 1.0?
I'm thinking very "whoah" thoughts, here...
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
f: 650.228.2501
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
Daniel Berlin <db...@dberlin.org> writes:
>
> On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
>
> > Hi,
> >
> > The included patch removes vdelta calculation when we are sending the
> > full text of the target.
>
> Except that vdelta against an empty bytestream will be quite a bit
> smaller.
>
> This should probably be controlled by some option, since it's not
> always a win for everyone (it depends on your network connection speed,
> etc)
True, but even without the compression that vdelta provides:
- ra_dav users will still get the benefit of neon gzipping the data before
sending it.
- ra_svn users can leverage ssh compression.
- ra_local users should have plenty of bandwidth inside their machine. :-)
-Fitz
--
Brian W. Fitzpatrick <fi...@red-bean.com> http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] : full-text instead of vdelta against empty bytestream
Posted by Daniel Berlin <db...@dberlin.org>.
On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
> Hi,
>
> The included patch removes vdelta calculation when we are sending the
> full text of the target.
Except that vdelta against an empty bytestream will be quite a bit
smaller.
This should probably be controlled by some option, since it's not
always a win for everyone (it depends on your network connection speed,
etc)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org