Re: cvs is slooooooow with large directories

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Jones <lawrence.jones@ugs.com> writes:

> Andrew Morton writes:
> > 
> > On a dual 2.7GHz power4, the cvs client has racked up an hour of CPU time
> > so far.  There's something in there which is quadratic (or worse) in the
> > number of files in a directory.
> 
> Yes, the fix for a release problem that Derek made a year ago
> (2004-02-25) is responsible for this behavior.  Prior to that fix, CVS
> would cache the Entries for a directory so that it wouldn't have to read
> (and possibly rewrite) the Entries file for each file being processed. 
> Unfortunately, it sometimes changed to a different directory without
> flushing the cache, resulting in one directory's Entries ending up in a
> different directory.  Derek's fix removed the cache, so each new file
> being checked out ends up reading the Entries file, adding the new file,
> and then writing it back out, which is indeed quadratic behavior.  We
> need to figure out a way to restore the cache without reintroducing the
> original problem, a non-trivial task.

As an added addendum to this problem, it seems that if your checked out
tree is large and is on an NFS server (a NetApp in one reported case)
and you are doing a 'cvs release -d' command, the release will usually
return a failure. The error message is this:

| Are you sure you want to release (and delete) directory `src': yes
| cvs release: deletion of directory src failed: Directory not empty

This is apparently related to cache problems with NFS itself getting
confused.

The only 'bug' reference I could find that seemed to be anything like it
was this one: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57696

So, for more than one reason, it would be good to get the cache fixed.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCIo6v3x41pRYZE/gRAmUPAKC4lLw0g9Ksy3B/FgsBFxDuF4lZkACeP68d
xKr8/OWD95yk73vX5DIR6cw=
=+HOW
-----END PGP SIGNATURE-----