Forum Posts

Hi all, I'm updating some KDE projects that got moved from SVN to git, but didn't get their ohloh enlistments updated. Unfortunately they're proving pretty hard to find. I'd like a list of ohloh ... [More] projects that have failing enlistments with kde.org in their URL. Could some ohloh admin make such a query and let me know the list? In addition, maybe even more important, I'd like to know projects with enlistments whose URLs start with "svn://anonsvn.kde.org/home/kde/trunk/KDE/kdeutils", whether they're failing or not, since kdeutils is going to move to git real soon. Thanks in advance. [Less]

This page says the SVN download failed 1 month ago: boinc enlistments These pages say BOINC hasn't had a commit for the past 3 years: boinc commits, boinc code analysis But the project is active: ... [More] BOINC Trac timeline ohloh seems to be missing a few thousand revisions. What's going on with this enlistment? [Less]

I found a way to fix the repo, stay tuned. EDIT: wait, it looks like ohloh was already working by now?! Oh well, too late. Repository already reset and I'm uploading the fixed version.

I don't think there is a way to fix that in the repository. The problem is that someone committed with a non-standard tool that didn't obey svn:eol-style, and now that file has some CRLF newlines on ... [More] the server side, even though eol-style is "native" (which means newlines are LF server-side). The only way to fix it would be to do a local svnsync dump, somehow fix the data, wipe the repository in Google Code, and upload it all back with svnsync. And I have no idea how I'd do the second step... Is there any way you can just skip that broken revision? [Less]

I think generated files shouldn't be in source control anyway. runs away before this becomes an argument

So you want coverage? Well, given all the features that people report so often and developers "have no time to work on because of so many other features in the list", add me on the survey as "wouldn't ... [More] (yet) recommend Ohloh to other open source projects". Every feature I'm interested in seems to be low on list compared to others. Wonder which are the others? [Less]

Thanks for the spam.

Thanks for the spam.

A question: how fast is the recount, in lines per second (or even better: KB/s)? If it's slow enough, you could look at distributed volunteer computing: have your users re-count the code :) Now, if ... [More] the problem isn't that it's slow, but it's way too much data... Then the only way to speed it up is having more CPU power on your side, which means $$$... [Less]

(I searched the forum for similar threads, but only found requests for ignoring files; which btw I'm also interested in) In the project 'synecdoche', Ohloh thinks I wrote a few hundred thousand ... [More] lines. Actually, I just fixed line endings on the whole repository. I probably wrote less than a hundred lines for the (quite new) project so far. There should be a way to mark individual commits so that ohloh doesn't count them, neither to the project (like in the "re-write cost estimation") nor to the contributor. The most common case for this is the initial code checkin. Even more important if that initial code isn't just code written by the project before they started using a VCS; but code forked from another project. It shouldn't show as written by a single person (in a day :P). Here is the whole list of commits I'd mark as ignored for synecdoche: r2: thousand files added, hundred thousand lines. This was the actual "initial commit". Ohloh seems to ignore r1, but that was just the structure (trunk, branches, tags). The actual code (forked from another project) was committed in this rev. Ohloh thinks user 'didactylos' wrote a hundred thousand lines in a day :) In addition, this initial commit had DOS line endings (CRLF) in all the text files, which made Unix builds break (no /bin/sh^M found). I fixed it later; cluttering my "language experience" even more (see below). r4: added 25 automake files that were missed in r2. These are also from the forked project. r5: 34 files (4739 lines) modified. I fixed line endings in shell scripts, which were breaking the build. Ohloh now thinks I wrote four thousand lines of shell script and that that is the language I know the most. r8 had more line ending fixes on the build system, 460 lines. Yet more on r9, 4900 lines (a single file!). r25: the very worst. I fixed the newlines on every single text file in the repository. 887 files modified, 101514 lines modified. I don't want all that attributed to me. r26: 1569 more CRLFs converted to LFs. And everything is fine now, I don't think there will be any other massive automated change to do, just real code to write :) But that real code, real work, will show as minor stuff compared to all the newlines I changed using a script. (Oh actually... I may do a tab -> four spaces conversion on every file some day; but I'll wait for this feature to be added on Ohloh) [Less]