Perl revision history 4+ months old

G'day awesome ohloh team!

It looks like the enlistments for the perl project aren't in great shape. The last update for most of the enlistments is 4 months ago, and some of them appear to have failed entirely.

I know the ninja ohloh spiders run automatically when they find themselves with free capacity, but I fear that the Perl repository may have become stuck.

A lot has changed in the Perl source in the last four months. I know, because I'm coordinating the release notes for 5.8.9. ;)

Many thanks,

Paul

You're awesome, Robin. Thanks for handling all my enlistment problems for me. ;)

Aha! All the dos batch scripts that other people no longer have to write are being included in Perl's metrics. ;)

On a more serious note, Perl is currently using perforce as a source control system, but we're in the process of moving over to git. The git repos that ohloh are indexing are courtesy of Sam V, who has magic that tracks the perforce commits and turns them into git commits.

When the move to git is completed (and I don't have a date for this), the location of the "official" Perl 5 repos may change again, so I'm not going to ask you to go digging through the history to see what's happened.

I will let Sam know of the funny results, in case he feels inclined to pursue things furter.

Many thanks again for your always quick and very helpful responses!

Paul

Yes. Well, the problem here is that this comment simply makes no sense:

the source control history is inconsistent. There are probably duplicate commits, or commits that delete code that didn't actually get deleted.

What does "inconsistent" mean?

There are no duplicate commits; they all have unique identifiers (the commit ID). It is possible that there are multiple commits that introduce an identical change; this is called "cherry picking" and are an inevitable consequence of working with branches.

That being said, there are multiple enlistments which share history because OHLOH currently only allows tracking of one branch in a given repository.

The final part of the comment is a non-sequiter.

I am forced to draw the conclusion that your conceptual model of git is deficient. I suggest reading chapter 7 of the user manual which outlines the object model, and consider where in your code the error lies.

Oh, those dreadful, dreadful conversion tools. How dare they test the edge cases of your code.

Look, at the end of the day, the repository is simply not corrupted in any way at all, and your insistence that this implies some kind of error in the conversion introduced by the conversion tool is categorically wrong. Like I say, this will be obvious to you if you simply read the chapter that describes the object model.

If you can point to the source to the importing tool, perhaps I can have a look.

Robin, I'm just wondering if the import might be choking on changes happening in parallel branches. If so perhaps passing '--first-parent' to whichever 'git log'-type command you're using to get the list of commits might be useful; it will linearize the history and make sure that you don't get any confusing changes.

Ohloh now sees only one create commit, but two delete commits. This leads to negative line counts.

Oh dear, this sounds completely familiar to me :)

I wrote a tool years ago called cvsmonitor (that FishEye later "cloned" and made much better).

I had a fundamental bad assumption in my math that could be described as the following.

"The line total at a desired point in time is equal to the known line totals at a given point, plus the sum of the deltas between the known time and the desired time"

This works just fine on the trunk, but leaves you in a quandary of two choices.

EITHER

a) Track "line total over time" for only the trunk, ignoring all work occuring on branches.

b) Track "line total over time" including the branches but have incorrect totals.

Most people choose b) because it gives maximum credit for work done, and if it artificially inflates the apparent size of a project, well then most people are happy to quietly turn a blind eye.

It only really gets noticed when the totals go blatantly out of sync, or during branched deletes.

The solution, really, is that you need to track contributions, rates of change and total change DIFFERENTLY to the running line totals, because in a situation with multiple timelines the two unhook from each other.

You keep tracking change over time on branches and crediting them to contributors, but you derive the project line totals over time ONLY from the subset of changesets that occur on the trunk.