bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs server/client protocol inefficiency and privacy violations


From: Bruno Haible
Subject: Re: cvs server/client protocol inefficiency and privacy violations
Date: Sun, 28 Jan 2007 21:56:25 +0100 (MET)
User-agent: KMail/1.5.4

Hi Mark,

> > If you wish to play with it, you may download a copy here:
> 
>   cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/cvs co ccvs

Compiles fine on Linux/x86. But the first checkout (against savannah.gnu.org,
which runs cvs 1.12.9) leads to an error:

$ cvs update ChangeLog 
P ChangeLog
cvs [update aborted]: No signature for `ChangeLog'.

I need to use the --no-verify option to get it going.
(Btw, the documentation of the CVS_VERIFY_CHECKOUTS environment variable
in appendix D does not say what are the possible values for this variable.
Should I do
   CVS_VERIFY_CHECKOUTS=
or
   CVS_VERIFY_CHECKOUTS=no
or
   CVS_VERIFY_CHECKOUTS=--no-verify
or what? IMO the doc of each environment variable should state
  1. what the variable is good for (general description),
  2. what are the possible values for the variable, and their respective
     effects,
  3. what is the default value.)

> I would be interested in learning the differences in timings you may
> find.

There are none. Still the same ratio of 6 sec. versus 29 sec.:

$ time cvs --no-verify update ChangeLog
cvs update: warning: `ChangeLog' was lost
U ChangeLog

real    0m5.922s
...
$ cp ChangeLog.modified ChangeLog
$ time cvs --no-verify update ChangeLog
M ChangeLog

real    0m29.272s
...

Look at this too: ChangeLog.modified is not in the CVS, but the cvs program
needs 29 seconds to detect this:

$ time cvs --no-verify update ChangeLog.modified 
cvs update: use `cvs add' to create an entry for `ChangeLog.modified'

real    0m29.219s
...
$ time cvs --no-verify status ChangeLog.modified
cvs status: use `cvs add' to create an entry for `ChangeLog.modified'
===================================================================
File: ChangeLog.modified        Status: Unknown

   Working revision:    No entry for ChangeLog.modified
   Repository revision: No revision control file


real    0m29.202s
...

This means that before the cvs client asks the cvs server whether the file
exists at all on the server side, it sends the complete locally created
file to the server!!

> Yes, CVS 1.11.x and versions through CVS 1.12.13 will uploading the
> entire locally modified file to the server and do the diff there.

And what about privacy? Did I give "cvs" permissions to send files from
my hard disk over the network? No, I asked cvs to *pull* updates from the
server to my hard disk. There is no relation of trust between me and the
admins of those machines from which I checked out a copy of some source
code (especially anonymous checkouts).

> It assumes that the CVS server has better provisioned resources for doing
> the merge.

Hah! For two years the CVS operations with sourceforge.net have been becoming
painfully slow. I was assuming that the hardware at sourceforge.net was not
sufficiently dimensioned. This may certainly be a factor. But the other factor
is that the "cvs" programs voluntarily moves the load to the server!!

Sadly, my conclusion for today is that the cvs client/server protocol needs
a complete redesign if it wants to
  - match today's expectations regarding privacy,
  - minimize network bandwidth, esp. uploads,
  - minimize server load.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]