Hi IBBoard, This is a reasonable, easy recommendation, and one that we've heard before, so I went ahead and made the change. Thanks for the idea, Robin

Hi Eclesia, Ohloh does not recognize duplicate code. If two repositories contain the same content, then Ohloh will count it twice. It may be better to split the code into two separate Ohloh projects, if that creates better reports.

Hi Steven, Is there still a problem? From looking at the latest report this morning, it seems like the commits from the Git repository have been picked up. For instance, this one. There can ... [More] occasionally be quite a bit of lag between the time when code is fetched and new reports are available. The various parts of the system are all asynchronous, and sometimes a few days can go by between steps. Also, even after a single repository has been updated, the commits won't appear in the report until all of its other repositories have been updated as well. It's a bit messy to try to recreate what might have been the state over the weekend. Let me know if there are still missing commits -- we should be current up to 2009-07-03 20:46:40 at this point. [Less]

Hi Ivan, I don't doubt that this is spam; I agree that it is just an advertisement masquerading as a review. We implemented the "helpful/not helpful" buttons as a hedge against spam. We could go one ... [More] step further and actually conceal reviews that reach a certain number of "not helpful" clicks -- it's still a feature-in-progress. I hesitate to put on my dictator's cap and summarily delete content from the site, unless it really becomes obnoxious. I'd be happy to hear how others feel about this. [Less]

Hi Roman, It looks like there are some files in these projects with names like 'conf.d', which our parser is misinterpreting as D files. I have opened a ticket for this fix. Let us know if you have ... [More] some ideas about how to correctly differentiate these files from D. Thanks, Robin [Less]

Hi Roman, You cannot create this alias because Ohloh is not aware of anyone named "roman" in this project. You can only use aliases to combine existing committer names. While investigating, I ... [More] noticed that this project has been enlisted in the Subversion repository svn://archlinux.org/home/svn-packages. However, this repository does not exist. What is the correct Subversion URL for this project? [Less]

Hi Chris, I was able to determine your committer name was "zx", but I still need to know which repositories you committed to. Thanks, Robin

Hi Chris, Do you know which repository contained your commits? What committer name did you use? We did remove the gentoo-x86 CVS module from Ohloh, because it was impossibly large -- too large for ... [More] Ohloh to process with our current technology. However, I'd be surprised if this is where your commits were lost, because I don't Ohloh ever successfully processed this module in the first place. [Less]

Hi jpike, I've opened a ticket for this feature request. Our counter is currently in the midst of a rewrite, so it's a tricky time to be adding new features. However, once the rewrite has been merged in this should be easy to add. Thanks, Robin

Hi David, Ohloh's Mercurial interface does work, but we still have some performance issues to solve that make it very difficult for us to process extremely large repositories. We extract source code ... [More] files from Hg in pretty much the same way that we do Subversion and Git, but for some reason this strategy is very slow with Mercurial. The NetBeans "main-golden" repository has received several months of server time already, and it is only about 80% processed. I've been keeping an eye on this repository for a long time now, but I just haven't had time to dig in and fix the performance issues. The current NetBeans report on Ohloh is very old, and is based on a subset of the old CVS repositories. It does not include any of the new Hg repositories, which we are still waiting to complete. I think the negative lines of code for Java is caused by a known, old bug: when lines of code are removed, they don't always get counted the same way as when they were originally added, which leads to non-zero net totals. However, we've fixed this, so after the new report (finally) finishes, that should correct the problem. I don't want to simply delete the existing NetBeans analysis, even though it's incomplete, because we are still finding a lot of commits and code in there, and the contributors deserve credit for at least that work. Unless I can find the time to solve the Hg performance issue, it will probably be at least another month before the NetBeans report is up-to-date. I'll be keeping an eye on it. Thanks, Robin [Less]