On Fri, 3 Feb 2012, 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
Hmmm. That doesn't seem to [fully] explain the slowdowns I've seen,
since I always use an explicit cvs root (following the FAQ) though I
certainly have switched repositories from time to time.
Dave
--
Dave Anderson
<d...@daveanderson.com>
