Forum Posts

[edited] Sorry, read your message wrong the first time and see now that you added the reverse alias for us. I see now that rbowers is listed in the "will be attributed to" list, but just not in the ... [More] "Contributions by" list. I'd missed that detail because we wanted the attribution to go the other way: rbowers -> ronaldbowers I'm not sure I see the committer vs ohloh ID distinction, though, because most of our other "Contributions by" aliases are most definitely not pointing to ohloh IDs. Moreover, rbowers is a "committer" as shown by the 68 commits so I'd think he should be listed, no? [Less]

Wow, been a while since I've gotten to report (what seems to be) a bug! Thanks for all the great features! On to our problem, it seems that the Aliases list for BRL-CAD is missing a username that ... [More] Ohloh sees in other places: https://www.ohloh.net/p/brlcad/contributors?query=rbowers&sort=latest_commit This user is not listed when we go to https://www.ohloh.net/p/brlcad/aliases/new The only hint I have is that the user's commits under that old username are to a portion of our source tree that no longer exists (hierarchy was rearranged several years ago). Cheers! Sean [Less]

Ahh...so close. As (it says) you are already aware, our SVN enlistment failed on step 2 after several hours of processing. If it's something we can review/fix on our end, please let me know. ... [More] Otherwise, I'll be (patiently and quietly) waiting to see the results. :-) Cheers! Sean [Less]

Okay, I've investigated the differences between the CVS and SVN enlistment, compared them to my notes before the SVN enlistment, and think I now have a pretty good grasp of all the differences ... [More] possibly even explaining the 7% increase (34 years) of overall effort that is reported for the SVN repository. None of the differences are of concern, fortunately (kudos!), but I did think you might find the differences interesting as they pertain to how Ohloh indexes and attributes commits for an enlistment -- there are some rather interesting differences between having a CVS repository and an SVN repository. In brief, the things I noted are as follows: SVN property changes are being attributed as source code changes. This is possibly the bulk of the 7% difference as it adds minimally a +1-1 change to every commit due to the CVS revision numbers being stored as SVN properties (an option we opted for during cvs2svn). With 28700 SVN commits, that's minimally -28700+28700 line changes being counted. Ohloh does a much better job at collapsing related CVS commits into one change event (presumably based on time and commit message) than cvs2svn does. Ohloh counted 27661 CVS commits and reports approximately 28689 SVN commits. I would presume you're taking SVN commits "as-is" given SVN performs atomic commit transactions, so you don't need/try to collapse them. Might be useful to do the same collapse for all repository types based on the log/timeframe for consistency, though it's certainly a minor difference. Perhaps entirely unrelated to another change that was just made, but Ohloh now correctly "finds" our BSD licensed files. All of our file counts doubled perfectly except for our BSD license count. Before with CVS, it counted 2 (which was quite wrong). Now it counts 171 files, presuming Ohloh's BSD detection didn't change this week. That number is a bit higher than my back-of-the-envelope quick grep counts, but it's within the ballpark. As already noted, it's interesting that the SVN commit log messages all seem to include a trailing newline whereas the CVS commit log messages do not. The "Lines Modified" metric was one that I really couldn't account for but did find it exceptionally interesting in the magnitude of the differences. Most of the user commit counts were about +3% and line change counts were about +- 3% different. Would hypothesize that the difference is simply the uncollapsed SVN commits. The only one that raised an eyebrow was where one user (johnranderson) gained an astonishing +269K lines credited to them, where everyone else was over or under by a few thousand lines or less for the SVN enlistment. Cheers! Sean [Less]

So far everything is going well and I should be adding the svn enlistment in a few hours as soon as the upload to Sourceforge completes. We've had several relatively minor issues to sort out in our ... [More] repository on the whole, a few bugs in cvs2svn uncovered that seem to be unique to the age of our CVS repository, but no show stoppers (just tedium). Our log, checkout, and spot tests have all passed just leaving ohloh enlistment comparisons remaining. I've just had to perform the conversion a couple times over to ensure mime types, permissions, and deal with one checkout validation failure. Having all .tcl files import with the mime-type of application/x-tcl and Subversion treating it as binary was really not helpful.. :-) I'll drop a note when the enlistment completes, hopefully with good news. Either way, thanks again for your advice and support. Cheers! Sean p.s. For others running across this thread, our conversion efforts are being documented here on our website. [Less]

Well, Andy -- thank you very much for your help. The enlistment looks to be complete and a complete success. One interesting side-effect, though.. If I recall correctly, our CVS enlistment report ... [More] summarized to 485 years of effort while the SVN repo is coming in at roughly 510 years of effort. Granted the SVN update includes a commit that touched all files (copyright update), but I doubt that counts for 25 years of effort.. ;-) It's also interesting to note that the SVN and CVS commit log messages handle the commit log message differently (or was changed via cvs2svn). The SVN commits seem to all have a trailing newline, the CVS ones do not. That still wouldn't likely account for the total effort difference either. Is there a way to compare the difference between the two enlistments, why one would be greater/less than the other -- particularly since the commit counts do seem right overall. Cheers! Sean [Less]

Robin, AHA!.. that explains a lot .. and no need to apologize. I'm sure there are constant fires that need to be put out on top of all of this trouble-shooting, support, all while actually trying to ... [More] still provide new and improved features. The detailed response is, however, incredibly appreciated and I think will actually be rather enlightening to both of us for several reasons. I should have thought to check if you were using cvs log -b myself -- t'was an oversight as we actually rarely use branches for active development. What it did unveil, however, is what could be construed as a bug with "cvs log -b" or at least a somewhat unexpected and probably undesirable behavior. To put it in other terms "I don't think that means what you think it means." .. to explain .. The -b option provides information about the latest revision on the default branch. Most projects only have one revision (numbered 1) and the default branch is of course usually HEAD. More to the point, if you have a project that utilizes RCS version numbers, "cvs log -b" will not report previous revisions even for HEAD developement. I'd call it a bug myself in the cvs log command, but it's more one of those detail behaviors of CVS that is carried over from it's RCS heritage/limitation days. While in general I do agree that I probably would want even branch efforts to be represented somewhere in the statistics, and there's certainly questions and design complications on how to go about that, I can appreciate limiting the statistics to HEAD development for now. That's not the case here, though, as the predominance of activity is HEAD activity. It's noticeable with BRL-CAD since our sources were in RCS for years and then later imported into CVS so that history was be retained. That import process preserves RCS revision numbers too and with RCS, it was somewhat more common practice to actually use the RCS number for various purposes. For example, you could have it imply api compatibility, simply serve as a means to denote new development phases, or even just to "reset" the minor revision number. You can actually even still do this with CVS, though it's done via flags during commit that will bump the major revision or via dreaded cvs admin commands. All of this mucking with revision numbers actually has really nothing to do with branching as it just increments the major revision number. To see an example of this in BRL-CAD, you see in the same log you mentioned for jove, i.e. "cvs log jove/jove.h", that the head revision is currently set to 11 (with the latest version before it was moved showing revision 11.8), but that there have also been revisions 10, 2, and 1 as well for that particular (bad example) file. Those are all on HEAD. This can be seen on just about every file in our repository where the RCS major revision number has been incremented over time and other numbers can be seen. If you were to check out HEAD using timestamps going back in time, you will get all of those other revisions as they existed. To truely get "all activity on HEAD", the "cvs log -b" command isn't really sufficient as it not only ignores branches, but it also ignores previous revisions. Instead of -b or at least in addition to it, you can get all HEAD activity by specifying that the revision range should start from RCS revision 1. cvs log -b -r1: I threw in the -b just to make it (doubly) explicit that the logs should be limited to the default branch, though it's actually redundant when you specify a major revision range. The "1:" basically means from major revision 1 to whatever the latest major revision number there is, which limits results to those found on the default branch. Perhaps this -r1: could be added? :-) I bet you'll find at least a handful of (older) projects where this will make a significant difference in the statistics being reported. I updated my script tables at http://ftp.brlcad.org/statcvs/cvs.html using "cvs log -b -r1:" and you can see there is a difference, but not nearly as substantial (which is what I would expect). In any regard, thanks again for the insight into the processing being used as well as for the productive discussion. Hope to see the revision numbering taken into account... :-) Cheers! Sean [Less]

Robin/Andy, Thank you again so much for your efforts in getting our stats back on-line. Looks like the report took about 12-18 hours total but it did complete and we seem to be good to go now. It's ... [More] also comforting to know that our root is now "repaired" for future operations. We'll probably want to sort out a few incorrect license detections later, but for now I'm quite satisfied and glad to see it tracking project stats again. Let me know where to send the beer. Cheers! Sean [Less]

First off, thanks to all of the ohloh team -- this is an excellent resource. We're having fun it. There have been several issues noticed, however, that I hope will be looked into at some point. The ... [More] biggest issue I noticed is that the processing doesn't seem to take Attic/deleted/moved files into account at least when computing the years contributions of developers. Our project, BRL-CAD -- http://www.ohloh.net/projects/3996 -- has almost 25 years of CVS history (potentially one of the longest retained project histories in revision control system) but the counts on our project page don't reflect this. For example, it list the project's original author (mike) at only 7.0 years contribution when that should be 17 years. There are commits from him all the way back to 1983 through 2000. One possible cause for the 7.0 year contribution is that in 2004, our repository was vastly reorganized changing from a top-level heavy repository to a more hierarchical organization. This resulted in a ton of files and directories moving around in CVS (via delete/readd). If our repository is checked out unpruned or even if Attic files for existing directories were considered, the logs are massively more extensive. Since our reoganization was so extensive, the years contribution is pretty much wrong for all but the newest contributors (since we went open source in 2004) which is no noticeable given the major discrepancy for all our devs. If it is taking the Attic into account .. then I can only imagine there is some other bug/assumption in the years contribution calculation. Example statcvs report that shows our reorganization and extent of history: http://ftp.brlcad.org/statcvs/ Speaking of statcvs.. one of the coolest aspects of the statcvs report is their authorship speckle graph.. that would make for a great ohloh feature, especially if it took the magnitude of the commit into account (which statcvs doesn't). Example, red graph near bottom: http://ftp.brlcad.org/statcvs/authors.html Other feature requests (not that you probably don't have more than enough to do already): * Include BSD-style licenses in "Licenses" section file count * Allow specification of exclusion paths to not process (e.g. our src/other is entirely 3rd party dependency codes, shouldn't be included in our statistics) Account for Attic changes in project costs Update enlistment reprocessing more frequently (perhaps once a week or at least on request) Add an "age of project revision history" metric (even our non-attic files go back almost 20 years) Thanks again for the great site. Look forward to seeing more improvements! Cheers! Sean [Less]

Hi! The problem isn't credit but, rather, that "rbowers" does not show up in the list of commit usernames that can be aliased to another name even though 68 commits are found, I'd like to alias ... [More] "rbowers" to his later "ronaldbowers" name but cannot because it's not listed. Cheers! --Sean [Less]