On Fri, Feb 03, 2012 at 12:47:02PM +0100, Otto Moerbeek wrote: > 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 >
My experience is identical to Otto's. Including his fix. :-) .... Ken
