On Thu, Feb 02, 2012 at 03:15:29PM +0100, Steffen Daode Nurpmeso wrote:
> 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
I like to say that long delays I have seen when using cvs had to do
with multiple different values of CVS/Root files in my local tree.
Those different entries can be created when doing a cvs up -d that
creates a new dir. If a cvs -d option is used at the same time, the
CVS/Root entry for tht dir wil be different than the other's.
The exact cause of the slowdown is not known to me. But when you are
switch repositories once in a while it's easy to get this case.
I repair this by find . -name Root | xargs rm and using a explicit cvs
root.
-Otto
