cvs server/client protocol inefficiency

[Bruno Haible]

Hi,

When the CVS protocol was designed, the structure of the Internet was such
that an upload and a download of the same amount of data took roughly the same
time.

Nowadays, CVS servers are often located on publicly accessible servers and
users are often connected via DSL or similar technologies which have
asymetric network bandwidths. For example, for me at home, my cable provider
gives me 280 KB/sec download (receive) bandwidth compared to 35 KB/sec
upload (send) bandwidth. At work for me, with an ADSL line, the figures
are similar.

In this situation, look at what it takes to perform a "cvs diff -c3".
I have a file 'ChangeLog', 914 KiB large, in the CVS. Here are the
results of measuring the execution time and the network traffic of
two CVS commands. (The execution time is measured with the "time" command,
taking real time. The network traffic is measured by subtracting two
subsequent runs of "netstat -s", more precisely the TCP traffic part.)

"cvs diff -c3 ChangeLog", where the ChangeLog has only a 1-line modification:
Time: 29 sec.
Network traffic, first run:
  416 segments received
  784 segments send out
Network traffic, second run:
  411 received
  675 send out

"rm ChangeLog; cvs update ChangeLog":
Time: 6 sec.
Network traffic:
  665 received
  384 send out

You can see here that the time to download the 914 KiB is 6 seconds.
The "cvs diff -c3" could therefore be 5 times faster if it would download
the 914 KiB and do the diff at the client side. Instead, it appears to be
uploading significant amounts of data, which causes a big slowdown.

$ cvs --version
Concurrent Versions System (CVS) 1.11.6 (client/server)

Bruno