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.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
[email protected]
enlisting CVS branches... (missing out contributors and contributions)
Hello,
I've been out of ohloh for quite a while. I came back to voice out a suggestion that came up before. I search briefly the forum posts, and it seems the limitation on the HEAD revision is still there...
Over the course of past year and a half in my MARF project (http://www.ohloh.net/projects/3508) I had a few truly parallel branches in the CVS repo, with a lot of code and developers contributing just in those branches. Since Ohloh does not seem to follow the branches, the stats are missing out a lot of contributions and the contributors who made them, who may not appear in the HEAD, but nonetheless were instrumental. I saw some of the work was done about the Subversion directories and their renames, etc. What's the current state on CVS? Are there plans to allow enlisting CVS branches? I understand the issue of potentially counting the duplicate code with the HEAD, but just curious if there is some remedy (being worked on) in place for the non-HEAD branches? How feasible and soon would it be possible to enlist CVS branches?
As an example, I would enlist the following branches in MARF:
http://marf.cvs.sourceforge.net/marf/marf/
DISTRIBUTEDMARF030_INTEGRATION
INSE691A
INSE7120
MARF_PD
SOEN49020072008
Thanks,
-s
... and thus the suggestion (to bring it on topic) is to allow enlisting CVS branches from the enlistment interface (just like Subversion users can enlist stuff other than the trunk). Thanks :-)
Hi mokhov,
We are not currently working on branch support for CVS, although I would like to add this. I don't think basic branch support would be particularly difficult to implement -- it's just that we have many more features to work on than we have time to give them.
I know you've been waiting a long time for this... I can't make promises but I'll see if we can get this in sometime soon.
Thanks,
Robin
+1 to cvs branch support
+1 to cvs branch support
on libbt, I'm working on a separate branch and that means the project looks as good as dead for a few years, while i have numerous commits going on in a non-HEAD branch.
+1
on libbt, I'm working on a separate branch and
that means the project looks as good as dead
for a few years, while i have numerous commits
going on in a non-HEAD branch.
The same in AndroMDA.
robin: if you don't have the time, give me a tar or something and i'm fairly sure i can get it implemented quite quickly, i mean: if you make an enlist/branch, it's no more work than adding one parameter to the importer and one extra field on the website...
+1 on cvs branch support, but I don't think that is enough. If you look at the OpenOffice.org project (https://www.ohloh.net/p/openoffice) you basically miss most of the developers because their model works on every feature being developed on a branch, called a CWS (there are literally hundreds of those), and those CWSs are then integrated into the main branches by only a handful of developers.
So OOo would actually need every branch to be included (or just plain every revision) to pay the well earned respect to all contributors.
So Robin... it's been a year and the pressure is mounting ;-) CVS branch support is still in demand. Maybe you could hire up AL13N? ;-)
Actually, that's not a bad idea. I've done similar things before.
importer:
- in CVS fetch part, add parameter (HEAD by default), and search if it's used anywhere else.
- check errors
website:
- add a field and link to the parameter, fill in HEAD by default
- if no branch parameter, don't pass it to importer
- get the parameter from DB or let it be part of URL
- do testing
Since i don't know anything about it yet, gimme at maximum a workday. I'll even give you substantial discount, email me for quotation :-) .
I think this preliminary support is more than enough, since you don't plan on adding this soon anyway.
the thing is; several older (more established projects) use CVS and see no particular reason to switch.
and there's the matter of unvalidated past experience.
people won't brag about ohloh if they feel they've come up short or embarrassed.
A quick workaround could have been a periodic conversion from CVS to Subversion, where the scripts convert every CVS branch into a a Subversion directory (this a default for the scripts on SF.net, or so it was) and then in Ohloh import them as Subversion directories. And update the Subversion repo as a mirror from time to time from the CVS (in this scenario Subversion is not used as a main development medium, but rather with a sole purpose of feeding branches to Ohloh). Of course this is not everywhere possible and will occupy more resources to do, so it isn't optimal, but might work for some craving for Ohloh stats :-)
Actually, it’s MAIN not HEAD, which is the head of
the main branch ;-)
+1 from me
Using the Ohloh Suckwürstchen importer does not sound
like an option to me because both of them have bugs…
I wrote an svn2cvs.sh myself which helped me to fix
at least one “hung” repository enlisting.
+1
In the mean time we can use GIT. Just migrated my 16 projects to gitorious.org via git-cvsimport and then replaced CVS enlishments by GIT enlishments with branches. Is pretty easy.
Now I'm much happy because GIT is quite better than CVS and I can still commit to CVS repository with git-cvs.
1) Stop trolling.
2) git cvsimport wouldn’t work on, for example, MirBSD anyway.
Thorsten Glaser, please stop judging people, I'm not trolling.
And sorry for MirBSD, I just shared what worked for me.
Then please stop unsolicited advertising for a “stupid content tracker” / “patch management system” since it can never fully replace a real Version Control System.
Besides, sometimes changing VCSes is not a choice. This is specifically about CVS branches.
To having a different opinion does not gives you the right to be disrespectful with me. If what I said does not work for you, feel free to ignore it, you don't need offend me.
I'm sorry, I wasn't planning on reacting, but I have to say that your comment there is totally off the topic here...
This is not a discussion about what is the best VCS (or even if it is one). Branches can be imported or transferred everywhere; this is totally not what this is about.
It is about the fact that CVS is probably the longest used VCS ever. and will hold in it's branches the most code in total... think about all the projects originally on CVS, think about all the deadish or finished projects. Think about all the author for decades back, who contributed to projects...
Seriously, there's a ton of contributions not being able to be on profiles (that is, if you're born before 1985).
There are projects that still are in CVS. even quite a lot of them, even here.
But the amount of time required to have this feature versus the amount of code and contributions that just can't be put on a profile...
THAT is what this topic is about. And even though this might sound quite egotistic, I'd really, REALLY like this feature, so I can have the proper amount of code attributed to myself.
We're not asking much, just one extra field where we can change the default 'MAIN' to something else...
Thanks for the clarification AL13N, I have to recognize that was skimming and wrote that quick reply.
Considering what you said, it is right, so +1 for CVS branch support.
Yeah, Drupal's whole core/contrib community is still hosting on CVS.
There is a lot of nice code there hiding in cvs branches, old and current. :)
+1 for this feature!
Drupal (www.drupal.org) core/modules/themes are under CVS, using with a massive usage of branches! :)
+1 for this. Drupal modules are often developed in branches.
See https://www.ohloh.net/p/Drupal_OpenLayers/commits -- it misses the actual development thread
+1 All the interesting commits on Panda3D happen on branches, making ohloh rather useless for our project. I don't understand how this issue has been going on for 3 years. Is ohloh abandoned or maybe is the staff prejudiced against CVS? We can't easily move to other versioning system as the main contributor (Disney) uses cvs internally thorough their toolchain.
