Hi, It seems one of the enlistments for InspIRCd has stopped updating. We were doing some server maintenence due to high demand a month or so ago, and we had some spotty availability. That has since ... [More] been fixed. Is it possible to reschedule a download? w00t [Less]

Spamspamspam. Someone kill this?

Nice work Robin. I would have posted earlier but I've been travelling for the past few days. I hadn't considered the effort to download large projects, but even ignoring the bandwidth for e.g. KDE's ... [More] repository - I'd hate to imagine how long just fetching the histories take. I'll put some thought into that myself, and see if there's anything I can come up with, but short of nicing the downloads, throttling the bandwidth use (it would be nice if you could somehow throttle per-project, don't know how possible this is... firewalling isn't my forte) and killing (and resuming) periodically I don't think there's too much more that can be done to assist that. You could perhaps consider stopping and resuming at a lower interval though, as projects that are taking 8 hours are obviously already having problems. What kind of contention do your servers encounter? IO locking? Memory limitations? Bandwidth? The more I (and others :-)) know, perhaps the more advice we can offer. [Less]

Hi, I note that you've had some more minor hiccups with update queues, and had a few thoughts as to how they can potentially be addressed. In the shorter term, the problem you of course are ... [More] encountering is that you are continually adding more projects as well as trying to update existing ones whenever possible. Of course, this takes server resources for each project, so updates cannot be in real time - probably. What I'd suggest is a few small things, with a third in the future. Allow projects to specify update intervals For example, I have a number of projects enlisted in Ohloh (InspIRCd, ircc, obsidian, svnbot, etc) - most of these recieve incredibly infrequent updates or I simply don't care about them that much, so I'd be willing to set an update interval of a month on all except the active ones. This might be a sensible default for people to change, too. Building on this, it would/should then be possible to decrease update checking if a project decreases in activity, and re-increase the updates as it increases in frequency - so their interval would be hit with a fuzzy modifier to balance things out a bit. Diffs Modify counting to only count changes on diffs, e.g. read each changeset individually via svn diff (or equivilant) and do counting on that, applying the delta to the overall project statistics. You may already do this, I confess to not yet having read ohcount's source. Notificaition Instead of (or possibly in addition to) this, you could operate the updates on a notification basis: that is, the projects that notify you of updates (via a post-commit hook in SVN or whatever) get bumped further up the queue - or perhaps the queue could be entirely comprised of this, but I am not sure how well other VCS support hooks like this. Advantages are that it would update projects that most "need" updating, possible disadvantage being that it continually bumps a really huge project which means frequent recounts of something large. Time based Schedule delays in updates depending on how long it takes to line count src - sure, you'd be talking small amounts, but they all add up - so more frequent updates of more projects is going to be beneficial. Downside is that this is rather a superficial stopgap to the problem. Future: Either allow client-based (as in the people that use ohloh) distributed counting (probably not the most practical of ideas, and perhaps prone to over/under reporting), allow projects to supply their own count data (via a callback HTTP page or something?) - more suitable, but again prone to people doing stupid things for a laugh, so perhaps correct with a periodic ohloh recount (once per month/two).. -- Just some random thoughts on helping scalability. I do a lot of scalability based stuff at work, though mine is in a slightly different arena of the web, so it was interesting to put my brain to use like this :) [Less]

Oh - I wasn't aware. Thanks very much, and best of luck in getting things resolved! :)

Hi, I enlisted ircc a few days ago - pretty much the same day as I'd started the project. It read successfully, and is currently sitting on r16, which is nice, but I'm now almost at r100, and it ... [More] doesn't seem to be updating. Have I made a mistake somehow? As far as I'm aware my server is operational fine. Thanks! Robin [Less]

Actually.. Now I look at it again, it does seem to have changed, but now I have no idea what caused those huge LOC jumps earlier on in the project..

Hi, It's me again. :-) I removed a number of source repositories from our project listing (InspIRCd, ID 5114) yesterday, and was told that analysis of the project would update automatically in ... [More] about an hour - but this does not seem to be the case, as shown on http://www.ohloh.net/projects/5114/analyses/latest - the massive jumps in LOC being caused by branches of the project being created. Is it possible to have this fixed? Thanks :) Robin [Less]

Not that I know of at least.. as far as I know I'm the only (very) active developer right now that would take an interest in this. Strange :-) Thanks very much for the update though. I guess I'll just be patient :)

Hi, Our project (InspIRCd) appears to be experiencing some difficulties in updating: Step 3 of 3: Counting lines of source code (Failed) Is this a problem on your end? Or ours? Also, I've removed ... [More] a number of branches that were also listed under our source repositories for some reason as I know you just prefer to count from the 'trunk'. Will our history update accordingly? Or do you need to review the whole project for that to happen? - it would look weird for us to suddenly drop by about 80% of our LOC ;p. Thanks, w00t. [Less]