hehe ... incidentally, I'm back :P

Hmmm, think it'd be possible to spit out some sort of graphing based on the Language Summary bit of the commit page? Or even expose it in the api so I can have a play with it? :P

*nod* it's a scope problem. The question is, should branching actually be supported? When someone adds an enlistment, they give the trunk directory ... and the history of the trunk and the history ... [More] of the folder are two different things. As a thought... you're doing svn log, then starting at the beginning and stepping through each revision in the log, right? Would it be a lot of work to change it about a little so it looks like this: svn log the enlistment (without --stop-on-copy) grep out files outside the enlistment url grep out empty revisions (could possibly be combined with the above step) start checking out as before It's not as pretty as the current method, but it might work? Though as I say, it begs the question of if the parser should be sticking to the url it's given, or following the history of the folder at that url :/ I can see arguments for both logics. (the new svn clone command features prominently in this plan). svn clone? that is new. Suppose if you can clone the repo that simplifies the problem greatly cause you then have the dump filter to play with. Edit: grrr, bug in formating code: before I added the escaping, the asterisks around nod made italics, but the ones around is didn't [Less]

thankie :)

Mmmm, I doubt extracting data from mboxes is on the cards ... interesting point though ... mailing lists may be one protocol, but mailing list archives aren't.

You can tell ohloh that a project uses an unsupported vcs ... not sure if you can say which though. You just remove the enlistments for said project (if they're not using them then it won't matter if ... [More] they're not there) and click the button marked this project uses an unsupported repository or something to that effect. This won't remove the existing code analysis, but it should stick a sign up saying ohloh doesn't support the vcs the project uses. You could probably also stuff any extra info in to the project description ;) [Less]

Ah, so that is why you've all been telling us not to delete and recreate enlistments when they fail? ;)

I've just completely rearranged the repos for Chained via svndumpfilter ... I nuked the old enlistment and added three new ones. Pwease could you clear out the code history? (http://www.ohloh.net/projects/5311/analyses/latest)

That'd be brilliant, thanks :D Gives me a couple of days to code my revenge against qmail lol

Yeah, I think it would be perfectly fair for developers of a project to update a page about said project, but dealing with wikipedia is like tap dancing in a minefield... you gotta be real careful ... [More] where you put your feet. The whole notion of notability is biased and totally perspective orientated. As I said, if someone can get IWC up for a delete on non-notability, I wouldn't put anything past them. All it seems to take for someone question the notability of something is for someone to have not heard of you. [Less]