Forums : Suggestions for Ohloh 2.0
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
info@openhub.net
Issues with repositories using a different than standard repo layout (plain text patches and binary source tar ball)
It would be nice if you would be able to support the apparently non-standard layout used in some repositories that are provided to build Linux RPMs from, one of those examples is SME Server.
The repository layout is more or less like this:
- F/
- S/
- P/
Where:
- F/ contains a spec file used to build the RPM package
- S/ contains a zipped tar ball of the source (as a starting point)
- P/ contains patches against the zipped tar ball
I understand that this might be a bit harder than the more standard layouts containing plain text only.
But due to build bots historically preferring/depending this layout the layout of the SME Server repositories are set up like this.
Due to the nature of this layout code count seems to go wrong as well as a lot off code is marked as Erlang, which is not used at all in this project.
Judging from the code count libs this is most likely because of the patch files starting with a - or a + sign, just like some Erlang lines might.
I know it might be a lot of work but would it be able to fix this so our code count and code determination is more accurate?
Kind regards,
Jonathan
I don't think this is so much a question of directory layouts as it is an issue of using source control in a fashion entirely unexpected by Ohloh.
Ohloh doesn't understand any layouts. You give us a directory, and we count everything in it. We never do any special handling based on the layout of the directory.
The key is that Ohloh expects to be pointed at a source control repository containing original, ongoing development on ordinary source code files.
The problem with, for example, SME Server is that these repositories are sort of a "meta" source control system. The original development work is done elsewhere, and the CVS repository is used merely to archive the artifacts. Usually, a source control server generates patches. Here, the repository is used to store patches.
The last thing Ohloh expects to find in a source control system is a tarball of the source code. All of the code in the patch will go uncounted by Ohloh, because we don't expand the tarball. We just see a *.tgz and move on.
You can restrict your Ohloh reports to a particular subdirectory. When prompted for a CVS module name, you can append a path. For instance, instead of entering the module name anaconda, you can enter anaconda/F. This might help.
If we are incorrectly identifying Erlang code, it's almost certainly because of file extensions. Does your project contain files name *.erl or *.hrl? You can try running our Ohcount tool against your local code repository to figure out which files Ohcount thinks are Erlang. If there's a bug here, we of course would like to fix it.
Thanks for the explanation on the differences bewteen our/SME Server repository layout and the expected/default layout for Ohloh.
I guess there will be no change that you will be redesigning your method to check out our meta repo (including tarball), extract the tarball, apply patches and the count code lines. :-)
I will try and see if I can get the Ohcount application up and running myself and so some testing.
AFAIK there are no files in the repository having .erl or .hrl extensions, but perhaps running Ohcount locally might indicate some I am unaware off.