I'm not certain that's really valuable to do, such a one-time list of trunk directories. Sure, I can spend 30 minutes writing a script that selects all trunk directories (not every subproject will be ... [More] divided into trunk/branches/tags). But: It will have limited historical value (quite a number will have their history truncated because a branch got copied to trunk). It is a one-time snapshot, so a maintenance nightmare if projects are added. You're guaranteed to miss stuff (as you already mentioned) on branches. I think something like the collective ought to wait for a later version of ohloh. All the data and knowledge about branches *is* inside the svn repository. Trying to do part of the work inside ohloh and part of the work outside ohloh (figuring out which branches to feed to ohloh) sounds error-prone to me. One tool should do it. What is counted? What not? What if there's an upgrade later on that does it in a different way? Must the list of 142 trunks be changed, then? Etc. It is not my intention to be negative. I already like the few statistics that I got out of ohloh. I'm just very much in favour of automating things so that they're reliable. So a non-maintainable one-time listing of trunks based on guesswork... no. [Less]

Robin, translating this to the "plone" project: It is right that the plone project didn't include just the full repository. But adding all the 40 or so individual smaller projects inside one project ... [More] is subobtimal. Plone ought to be split into 40 small projects. Don't add more than one branch/trunk to a project. To me, it starts to feel pretty cumbersome. And you're more or less guaranteed to get some black holes that aren't counted. I'll kill off the two full-repository-projects that I've submitted and await how it works out in practice. [Less]

Well, I started the archetypes project here and just added the whole repository. The download goes slow and is currently at 66%, but they'll get there. The collective gives an unspecified error. So ... [More] eventually the collective&archetypes repositories will get there. I actually wonder how good a picture the statistics of the plone project give now. "the code delivered in a plone .tgz" sounds ok, but only specific branches or trunk versions are listed: are those all trunks/branched ever included in a plone release? Or just the versions in the current releases? The same style of cherry-picking branches and trunks also happens in the zope project and there you see a very strange graph. 20% of the code disappears somewhere in early 2005, for instance. It can be a code cleanup, but in this case it is probably a branch that got moved (and subsequently ignored in the statistics). Does ohloh have an opinion on this? Do you want to be clobbered with full repositories yes/no? Is that preferred? Not? [Less]

I don't know who set up the plone project here, but was there any reason to just put individual trunks of sub-projects in there? I mean "http://svn.plone.org/svn/archetypes" would catch any branch and ... [More] any subproject. Adding individual "http://svn.plone.org/svn/archetypes/ArchGenXML/trunk" items seems like a lot of work (with apparently also the kind of drawbacks that Godefroid encountered). As I barely had any commits in the plone project, I assumed (without checking) that "plone" meant only the "http://svn.plone.org/svn/plone" repository and not the (related) "http://svn.plone.org/svn/archetypes" and "http://svn.plone.org/svn/collective" repositories where I did do a lot of work. So I registered them both two days ago as separate projects. Any suggestions? Remove the archetypes and collective projects and fold them under the plone project (which seems a good idea)? Remove all the individual small bits and pieces of repository and just add the three full svn repositories (plone, collective. archetypes)? I mean, I'm not even contemplating adding the 20 collective projects I'm working on (each probably including a trunk and two branches or so), which would make some 60 new submits. Yuck. Reinout [Less]

One small, but nice, feature of flickr.com is the option to customise certain URLs. Instead of flickr.com/photos/some12344553number you can customise it to flickr.com/photos/reinoutvanrees, for ... [More] example. Just psychologically I'd like to have this option for at least the user profiles, though it makes sense for projects, too. It just looks a bit nicer, that's all. Nice tool, btw. I like graphs :-) Reinout van Rees reinout@vanrees.org [Less]