Lock contention executing cvs log

[MacDonald, Ian]

Hi Folks,

I'm sorry if this posting might appear twice.  I first posted this to the NNTP group gnu.cvs.help but was not sure my posts were actually making it.

Here's my problem:

We have an automated build environment (CruiseControl) running on multiple hosts that poll for changes in a cvs repository using the cvs log command.  We are seeing a

problem that seems to be resulting in an inordinate amount of time executing
the log command.

When to two or more of the hosts are executing "cvs -q log -N -d upperdate >
Lowerdate -b" on the same module they seem to get stuck in a lockstep mode of
waiting for each others locks with each module taking upwards of a
minute.  For our respository this adds up to 30 minutes to each build cycle scanning for changes.

Shouldn't cvs simply be using "read" locks while executing the log command?
If that's the case, why is there a contention for the "read" locks?  Perhaps there is a write lock getting created?

Any assistance would be appreciated.

Thanks,

-- Ian MacDonald