Forums : Ohloh General Discussion
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
info@openhub.net
Support for mercurial
+1 for hg support
Hm, funny. Everytime I get a mail about a new post in this thread I am deep in my heart hoping that there's finally support for mercurial. ;)
You're not the only one, Christoph. ;)
I always come here with hoje too ;)
I always hold high hopes while I scan the subscription mail for the text :)
Anyone interested in counting the number of votes Mercurial support already has? :)
46, but I might've missed a few.
I just hope they haven't forgotten us..
It looks like it will eventually happen .. when it does will hg repositories be imported like subversion, i.e. a few years worth of commit histories?
I've been using hg ever since Xen switched over from Bit Keeper, it would be great to get all commitments tracked. If not, no worries :) I'm just happy to see it eventually happen.
The Subversion issue is a problem with parsing Subversion's shorthand logs, which makes it very difficult to reverse-engineer the full history. I can't think of any reason why Mercurial would suffer the same problem.
Although, having not studied Mercurial in depth, I can't say there won't be other surprises lurking within :-).
Correction: I feel I should clarify what I just posted regarding Subversion, before it gets me into trouble. While it's true that the Subversion logs do make it hard to parse the full history, our real issue is in how we create a local mirror of the Subversion code.
In many cases, we use svnsync to simply pull a full clone of the repository. However, a lot of servers don't support this, so in those cases we have to systematically check out every revision in the log. It's during this iterative process that we run into trouble when a directory changes names. It's too esoteric and trivial for this thread, but the main point is that it's highly specific to Subversion.
Because Mercurial is distributed by nature, there shouldn't be any problems creating local mirrors of the repositories.
Ehm sorry, but I don't get the point?
We already know that Mercurial is superior to Subversion, that's why we would like to see support in Ohloh. ;)
But it's a bit sad that you still hadn't the time to look at Mercurial after a year of discussion..
What about the several offers of people in this thread that would like to help?
Hi Christoph,
I was just trying to respond to Tim's jab about our Subversion support.
Yes, it is a bit sad that we still don't have Mercurial support (and that we also haven't fixed our Subversion importer).
We haven't forgotten about Mercurial.
It's very encouraging to hear that people want to help, but we're simply not in a position to accept help right now. I know this is a dissatisfying response, but we do have to prioritize where we spend our resources.
Hi Robin,
thanks for your reply again. The problem is the copyright of the code? Well, guess you don't have to show the whole code, just the svn importer should be enough to (hopefully) rebuild it for mercurial. ;)
For me I would even sign a NDA to get this support. ;)
Hi Robin - You would not have to go through all of those crazy steps in order to get the full history .. you'll get it the first time you clone a repository. You can then go back to the initial revision and work your way back to the tip. Mercurial is a little heavy handed
if the diffs between revisions are huge .. but no more than Subversion. All in all, I think you'd find it easier to track :) Looking forward to it in months to come!
Then maybe I can add one reason, why Mercurial support could provide something for ohloh it doesn't yet have:
With it you can do things like The weekly code_swarm of selected free software projects
.
It's a current project of mine to visually track the development of different free software projects. I use Mercurial to easily aggregate code and to create the logfiles for the codeswarm.
It might be a bit too heavy in terms of CPU usage right now, but it could become a future feature once you get the funding stuff: An Ohloh livestream for the people who always want to track how their projects progress, seeing commits in almost realtime (i.e. depending of the update-cycle). It's a different kind of news, but quite addicting :)
Or perhaps, cannot it be hacked using tailor to convert to git and then analyze?
Oh.. When I got the mail I first thought it's time for the monthly mercurial reminder in the ohloh forum. ;)
Does anyone here use tailor/git-export-stuff to keep your project on ohloh in sync?
I worked with Ohloh during the Google summer of code and after completing my main project (rewriting Ohcount to use a faster parser), I submitted code for tracking Mercurial repositories. Obviously the devs just don't have the time to integrate it. (I don't blame them with the workloads they have.) It'll come when it does.
@Christoph,
I thought about tailor/etc however it seemed to be a little too much work and headache just to have stuff tracked.
#1 - I would have people sending patches against both trees, which I really don't want to deal with.
#2 - When hg support arrives, I'd have to switch everything over .. or continue to maintain two repos per project (I maintain 11+).
For me, the value of Ohloh is mostly ohcount (although the networking is cool). Since I can just ohcount -s myrepo.hg ... I'm quite content to wait :)
oh good grief sorry about the text .. I forgot about the markup :)
@mitchell: Cool! I hope we'll see it soon!
@tim: People send patches only for the mercurial tree, I use the git-export-stuff only to keep it in sync from time to time. ;)
@mitchell: Oh - that sounds promising!
@Christoph
I've tried it.. even when maintaining an independent hg tree for stuff in the trunk of a large svn repo. It just doesn't work for me.
I'll enjoy the 30+ commits (vs over 1000 actual commits) that Ohloh tracks.. and keep my fingers crossed. I know they have to keep the business end going.. but so many hg users = so many new users .. ah well.
It will happen when and if it happens (despite assurances it seems to be a big if).. I'm not going to set up and keep up two repos per project just so I can be tracked by Ohloh :)
Ohloh is for profit, I make $0 from what I produce.. I see no reason to spend more time to 'just be tracked' .. rather its easier to point out that Ohloh just doesn't track even 5% of what I do :)
+1 once more I use Mercurial for