Forums : Technical Issue Help
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.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
[email protected]
negative lines of code
The code analyses at https://www.ohloh.net/p/sage/analyses/latest claim -15,284 lines of C, and the 39,234 is too large by over an order of magnitude. Any idea what's going on?
Hmm, well, it seems you may have uncovered the first major bug in our new Mercurial adapter. This will take some digging.
Stay posted.
Thanks,
Robin
FYI: I've seen something similar at Netbeans code analysis.
Thanks for looking into this. And kudos for getting Mercurial support up and running!
I figured the process was update your local repository and then run the same LoC analysis you do for everything else, but I guess it's more complicated than that.
Hi robertwb,
I've found the cause of the problem (and actually, I sort of expected this), but the solution is not going to be simple.
This post won't be very short, either :-).
The problem occurs when the same change appears in more than one commit. This happens during merges.
For instance, consider file sage/rings/padics/README/README.tex.
It was added in commit 0c8b6c57d935, but then it was deleted in three different merge commits: 19593a276cbf, d30f7e16c7b1, and 3241133b000f.
The end result is that Ohloh adds 255 lines of TeX once, and subtracts 255 lines of TeX three times.
We have the same problem with Git, which is why I anticipated this problem with Hg.
The question of what to do about this is a bit tricky.
The right
answer is to only use the main line
when computing the total lines of code for a project, and to not count branch activity when computing the net lines of the project. That is, when we traverse the commit tree, only follow first parents for purposes of computing total lines.
Ohloh doesn't currently have this ability. Every commit in the log gets counted.
To fix the total line counts, we would have to ignore all of the branch activity, and not add those commits to Ohloh. However, that seems just as bad as getting the total line count wrong.
Historically, all of the Ohloh code was written to work with CVS and Subversion, which have nice, linear commit histories that don't display this branching and merging trouble.
I'm about to embark on a full rewrite of our analysis engine, which should solve the git and hg branching and merging issues. However, this won't come quickly.
Until then, there might be some hacks
we can do to improve the line totals. In Git, we ignore merge commits. Perhaps something similar will work in Hg?
This is the main issue I am coding towards today, but it might be a long time until a proper solution is online.
Thanks,
Robin
Yeah, I can imagine all this branching and merging would make these systems more complicated (but that's what makes them so powerful too).
I'm pretty sure not counting merge commits would still be off, but it would probably be a much closer estimate. Following only the main line of course is the only sure way to do it.