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 :-)

+1 to cvs branch support

Hi,

same for us. Without branch support the commit statistics are completely useless. The same applies then for project comparisons etc. which is really a shame. Even if lines of codes are not counted, simply counting the commits in the other CVS branches would already be of great help. And, even better, this does not seem to be a really hard problem (at least it is much easier than preventing double counts of lines etc.).

I really would appreciate if this could be fixed.

Thanks in advance and also for your great work!

Cheers, Ingo

+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. :)