Hi Bob,
I spent some time digging into this problem this morning, and I think I was able to get to the bottom of it.
First, the big picture. Our CVS importer is fairly brute force: we request each revision, in chronological order, and we convert the local CVS working tree into a Git repository as we go.
For efficiency reasons, we do not do a CVS checkout of the entire tree with each revision. Instead, we do individual CVS update commands on the individual directories that are affected, according to the log.
Sometimes something goes wrong (usually a network hiccup or other transient effect), and we get an error of some kind during an update. When this happens, we wipe our working directory clean and do full checkout of the entire tree. This should only happen rarely.
However, with the VisualMagick enlistment it seems to be happening with every single update, which is why this download has degenerated to an enormous amount of wasted time and bandwidth.
The issue seems to be that the CVS module name you provided, VisualMagick, is not the actual directory path of this module. Instead, it looks like there is some kind of symlink or redirect which occurs to reach this module name.
In order to do updates of individual directories, our CVS code internally does some string operations on the CVS paths, assuming that the provided module name is the same as the actual path in the CVS repository. But in this case, they aren't, and so we end up requesting some non-existent directories during CVS update. When the update fails, we wipe and checkout the full tree. This happens every time.
Ironically, all of this fancy string operating and update juggling is an attempt to dramatically reduce our burden on CVS servers, but in your case it has backfired.
I did a local test on my development box this morning using the actual CVS path platforms/VisualMagick, and the download worked correctly, with very quick updates of the deltas between revisions.
I imagine that this same problem afflicts modules TclMagick and BCBMagick, since the module names given for these also do not match their actual paths in CVS.
So the remedy is to remove the current enlistments from Ohloh, and replace them with ones in which the module name is the actual CVS path.
Out of curiosity, since I've done very little CVS hosting myself, how are these CVS redirects or symlinks or whatever they are accomplished? After 18,000 CVS modules, these are the first that have stumped us.
Thanks,
Robin
