Some time ago I wanted to find projects at Ohloh with largest codebase, which use Git enlistement/repository (Git as their version control system). But neither search operator for limiting searching ... [More] to projects using specified type of version control system used by repository, nor sorting by total LoC, is implemented currently. [Less]

Not any kind of URLs shortening. Not the unnecessary kind: first, the URL is not that long that it needs shortening; second it makes URL less readable, which goes contrary to for example replacing ... [More] project numbers by their shortnames. I'd rather have redirection in the opposite direction... [Less]

You can always switch to Git, which is distributed SCM, and allows for disconnected operations. You can import your history from Subversion using git-svn (and even interact with Subversion ... [More] repository). You can host generic git repositories on Savannah (if your code is GPL) and on repo.or.cz [Less]

(...) Historical trends in licensing would also be very interesting. For that you would need I think licenses timeline, similar to known timelines for Unices or timeline of Linux distributions ... [More] , where would be marked when given license was created, when given license was obsoleted, and which license is derivative / inspired by which. I could not find such timeline. [Less]

What I wanted to say was that you can do it now for (almost) free with Git, now. You can simply create repository which have all projects repositories as alternates, e.g. git --bare init, put absolute ... [More] paths to project repositories in $GIT_DIR/objects/info/alternates, then for each repository do git remote add , then do git remote update. As all objects are available via alternates mechanism, fetch (called by git remote update) would only update refs (branches and tags info). Then you would have to track only this common repository, which would gather all the history, automatically collating it and removing duplicates. Edit: This of course only reduces the problem of multiple repositories to the problem of multiple branches. I have not tested this setup personally [Less]

One of things that are shown in project summary is number of comment lines in the code (ratio of comments to code). Some developers think however that best documentation is well written code. What ... [More] Ohloh currently doesn't show is information about commit messages, and size of changeset introduced by commit. Well written commit messages together with good division of changes into well-contained parts helps enormously for example when finding bug by bisecting history. I had longer version of this suggestion, but unfortunately lost it in webbroswer crash [Less]

It looks like it failed again: Step 1 of 3: Downloading source code history (Failed)

Thanks to work of Ohloh developers (Robin Luckey) it is now corrected. Thank you very much.