Henning Brauer wrote:
> there aren't all that many repositories the size of ours out there.
That's true.
But no Henning, i don't believe it's that;
you know, it's just that i don't have anything to say, because
i have no knowledge about the internals of cvs(1).
I always thought of this as some kind of misbehaviour in between
OpenCVS and GNU cvs, because i would think of cvs(1) as something
like this:
cvs up .
|
read CVS/Entries
|
for those files with diff. timestamps, checksum file
|
send list [+ checksums] to server
|
server compare revision/timestamp/[checksum]
- client unmodified: send diff (expected final checksum?)
- client modified: send full file (if size < treshold),
otherwise do blockwise checksumming etc. (i.e. rsync-like)
[I don't really believe cvs(1) does the latter though.]
|
integrate diffs / replace locally modified files
Wether cvs(1) does do some rsync-like block-checksumming for
locally modified files or not, uploading 10% of the repositories
size or more before any data is sent from the server just can't be
correct anyhow. Even more for my usage case because there were no
locally modified files at all.
And also the problem goes away if you do specify files directly,
as with a file glob, so it makes a difference wether you say
$ cvs -fz9 up -PAC .
or
$ cvs -fz9 up -PAC *.*
I don't remember wether i've used -d or not.
So for me this turned out as either "look into the code,
instrument some functions and try to fix it" or "turn over to
cvsync".
And GNU cvs is hard to look at, with a lot of comments which refer
to some (numeric or so) error reports. But it would surely be
interesting to know what is going wrong.
--steffen
