Forums : Feedback Forum

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]

one CVS repo, two projects

Hey

Within the curl repo (http://www.ohloh.net/projects/3676), we have a sub-directory that is actually only used for the c-ares (http://www.ohloh.net/projects/5701) project and library.

For c-ares we can make ohloh check out a separate CVS module and all is fine, but for curl there's no way we can mark files as not-part-of-this-project-yes-yes-we-promise.

Is there any way we can adjust to this without actually moving out the directory from our repo, since that's really not an option for us right now?

Edit: I should note that currently the c-ares is left without source because of this, and alas curl lists a little more code than it actually is...

Daniel Stenberg almost 17 years ago
 

Hi Daniel,

I'm not 100% sure I understand you correctly, but it sounds like you are trying to add a single sub-directory of the curl CVS module to the c-ares project.

If this is what you are trying to do, our system does allow it. It's more by happy circumstance than by design, but you can do this by specifying a partial path after the module name on the enlistment form.

For example, you could add a module called 'curl/ares' to the c-ares project, and then only the 'ares' sub-directory of the curl module would be added.

Does this help?

BTW the ability to ignore files or folders within an enlistment is near the top of our requested feature list, but I can't promise when we will have time to implement this.

Robin Luckey almost 17 years ago
 

The problem is not for the c-ares case, since for that we can fix it with a CVS module (it already exists). The reason I haven't done that yet is that then we get the same code counted in both curl and c-ares and I wanted to just check with you first if I had a way to work around it...

Yes, I basically want to ignore a folder within the enlistment for curl.

Thanks for your reply. I'll add the code to c-ares for now and hopefully filter it out in curl in the future when that ability is added.

Daniel Stenberg almost 17 years ago
 

Is there some kind of advanced duplicate check for files in multiple projects? I added c-ares now, which then has all the files already present in the curl repository.

The odd outcome is that the system says I've done 7 commits to c-ares, none of them in 2007. While a quick 'cvs log' in that very same dir against the CVS server reveals that I've committed at more than 100 different dates:

$ cvs log | grep bagder | awk '{print $2}' | sort | uniq | wc -l

133

(edit: formatting)

Daniel Stenberg almost 17 years ago
 

Hi Daniel,

I must admit that your post gave me a lot of puzzles to solve today. There were a lot of things going on all at once.

First, if a change doesn't affect recognized source code, then our system ignores the change. This means that edits to files like README, which don't contain code, are ignored by our system. You've made a lot of such changes.

Next, there are many languages our system doesn't yet recognize, and unfortunately this project uses several of them. We don't process troff or m4 files. You've done a lot of work in these languages, and Ohloh doesn't see any of it. The languages look easy to parse, so I'll put them on our growing queue of languages to implement.

Third, we ignore white space changes. I found at least one C file edit that was strictly a white space change ... although I can't seem to find it again now.

All of these reasons will cause many of your commits to be ignored by our system. However, as I kept digging deeper into this, I found something very fundamentally wrong with our report.

The problem is that the module name you gave us, c-ares, appears to be virtualized or a link to another actual directory -- that is, if you fetch an rlog for 'c-ares', the log comes back with filepaths to 'curl/ares', not 'c-ares'. This mismatch between the module name and the rlog filepaths caused a lot of confusion in our downloader.

I took the liberty of removing the 'c-ares' module and replaced it with 'curl/ares'. The new report is online, and you can see that his greatly improved the quality of the report. However, many of your commits are still missing, for the reasons above.

Robin

Robin Luckey almost 17 years ago
 

Thanks for your swift work and reply. I have the deepest respect and understanding for that not everything ends up exactly as I would have guessed.

Daniel Stenberg almost 17 years ago