Forums : Posts

Hi Hagen, We use the URL as the key for recognizing repositories. If you moved this repository to a new URL, then in Ohloh's opinion it is a completely new repository, and we will not try to do an ... [More] incremental update. Go ahead and just add the new enlistment. If you add the new Google repository and remove the existing one, you will get a completely new report. Googlecode is pretty fast for us, so you should see your new statistics soon. Robin [Less]

Worked like a charm. Thanks a lot for your fast answer ^_^

seems like it failed again..

Here is another one similar but only from a single committer

Great tool, I love it! Thx

Hi Robin, thanks for your efforts. Ask if you need help with i.e. asking the admins of the repo. Stefan

Any logged in user can edit the details of projects. It's just a matter of adding new repositories (and keeping the old ones, unless you move all the history to the new repository). But there, I ... [More] added them for you. Or maybe are you talking of some problem you had with the repositories? (EDIT: fixing URL) [Less]

Due to the nature of open source projects, packaging (rpm, deb, etc.) has become more and more important. Gone are the days when you were forced to do the ./configure, make, make install and hope for ... [More] the best. Instead, today we have packaging systems making it easier for the not-so-technical system administrator or home user to use the multitude of open source project available. In the Edit->Links section of an Ohloh project, there's a fixed set of categories (Tutorial, Manual, Forums) available. I would like to see more categories there, especially Packaging. [Less]

I didn't realize the incremental nature of the analyses; that does make this difficult. It would still help to know the current Ohcount version used for new analyses, though. Meanwhile, how about ... [More] somehow logging the Ohcount version in the project edits log, like the existing message showing an update of bestanalysisid? For the Ohcount version number, try git-describe. If the current revision has a tag, git-describe will output that tag; otherwise, git-describe will output a version of the form tag-${NUMCOMMITSSINCETAG}-g${SHA1ABBREV}. (You can adjust the length of the abbreviated sha1 with the --abbrev option to git describe; you often want to use the full sha1.) As for actually releasing a new version, the value of that varies. If you release on nearly every commit, that decreases the value of a release over pulling from the repo; if you release too infrequently, that will also decrease the value of a release over pulling from the repo. Ideally, a release should represent some increased level of stability due to testing, and pulling straight from version control trades some of that testing for freshness. If nobody tests the releases, and nobody goes to any extra effort to make releases more stable, then releases have no value, and you shouldn't bother making them. :) If you do decide that releases have value, I'd suggest deciding on a convention for version numbers in advance. Something along the lines of x.y.z, where you increment z for bugfix-only releases, increment y for new features (such as new languages), and increment x for incompatible changes to the interfaces (meaning breakage in existing interfaces, not just the addition of new interfaces). [Less]

Add mercurial support.