rsync - Nov 2007 - Rsync shouldn't display a meaningless speedup on a dry run

On a dry run, rsync displays a speedup value calculated from the total
size of the source file data and the amount of data sent over the
connection, but this value is meaningless and grossly misleading because
the file data is not sent over the connection.  Example:

[matt@mattlaptop2 test]$ rsync -avi -n
~/eclipse/releases/eclipse-SDK-3.3-linux-gtk.tar.gz .
sending incremental file list
>f+++++++++ eclipse-SDK-3.3-linux-gtk.tar.gz
sent 74 bytes  received 15 bytes  178.00 bytes/sec
total size is 144352015  speedup is 1621932.75

I think rsync should omit the speedup on a dry run.  The attached patch
makes it do so.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dry-run-no-speedup.diff
Type: text/x-patch
Size: 759 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20071105/21745eed/dry-run-no-speedup.bin

> Date: Mon, 05 Nov 2007 13:17:32 -0500
    > From: Matt McCutchen <matt@mattmccutchen.net>

    > I think rsync should omit the speedup on a dry run.  The attached patch
    > makes it do so.

I worry about those trying to write things that parse rsync's output;
if -n changes the output format, such things will have to be tested on
live data.

Is it possible (e.g., without ridiculous amounts of code-massaging) to
have -n output the speedup (or some more-reasonable estimate) anyway?
Sure, all kinds of differences haven't been computed, but...  Or maybe
just have it report a speedup of 1.00 instead?  Still misleading, but
it preserves the output format and is trivial to write (but still,
alas, confusing for the user, so this doesn't fill me with glee).

Or we can just assume that such parsers might be looking at the file
list, but it's dubious that applications exist that care about the
speedup data and hence would be throwing away such lines anyway (and
would not break if it doesn't appear).