Hi Robin, thanks a lot for the elaborate response. It would be really cool, if you could replace the current enlistment by the SVN root. I doubt that it will cause significant load to your servers ... [More] , because the whole library currently has less than 2000 lines of code ;-) We're at the moment doing some major refactorings and therefore might need a branch (we didn't create it yet - still working on trunk). If we temporarily need a branch, we'll very likely delete this work-in-progress branch when the refactorings are done. If we find out later, that branches are regularly used, we can still delete the current root-enlistment and register trunk instead. Till then trunk is aged and the project doesn't look as if it was created yesterday ;-) Additionally, till then ohloh.net will probably have become more mature and likely the current issues have been fixed... Best regards, Marco :-) [Less]

Hello *, today, I added an enlistment for the project Mime Type Detection Utility. Since the project was directly in the root of the SVN repository and we're now needing branches, I created a "trunk" ... [More] folder and moved the project there. Thus, the source code history is now 1 day long (instead of 2 years) and all the code is listed as being mine (even though it's not much code, it should be assigned to the right contributors). In order to solve this problem, I deleted the enlistment https://mime-util.svn.sourceforge.net/svnroot/mime-util/trunk and wanted to add the base URL https://mime-util.svn.sourceforge.net/svnroot/mime-util. This, however, didn't work. Whenever I tried to re-add the enlistment, ohloh.net added the URL with "trunk"-suffix (even though I specified another URL). After my last try, it even automatically added "MimeUtil" (i.e. a sub-project under "trunk") instead of the "trunk" base URL. Is there a way to get the old repository information, which was https://mime-util.svn.sourceforge.net/svnroot/mime-util/MimeUtil into ohloh.net together with the current and future information from https://mime-util.svn.sourceforge.net/svnroot/mime-util/trunk (all subdirectories - not only "MimeUtil")? Best regards, Marco :-) [Less]

Hello Robin, thanks a lot for your fast reaction and your help! It seems to have worked fine. All enlistments are updated successfully. Best regards, Marco :-)

Hello *, the download of one enlistment in each of the 2 projects failed and the other enlistments have been updated 13 days ago: https://www.ohloh.net/projects/pdfviewer/enlistments ... [More] https://www.ohloh.net/projects/jfire/enlistments Could you please take a look? Thanks a lot! Best regards, Marco ;-) [Less]

Hello Robin, thanks a lot! I just took a look at the enlistments and all of them have been successfully updated within the last 10 hours. Best regards, Marco :-)

Hello ohloh-team, the JFire repository svn.jfire.org has not been updated for a few days: http://www.ohloh.net/projects/jfire/enlistments Could you please take a look at it? Best regards, Marco :-)

Hi Robin, thanks a lot for your quick response! Yes, I searched our forum for "Patemino" and saw that he has posted a few times. He signed our "contributor license agreement", too, and therefore, I ... [More] think it's OK to leave him in the list. I hope he'll contribute some code, soon ;-) Best regards, Marco :-) [Less]

Hi Robin, thanks a lot! I saw that you already removed the 2nd occurance of "chairat". Great. Another question about the contributors listing: What about this "Patemino" who has 0 commits, too? Even ... [More] though he's not listed twice, I wonder why someone without any commit is listed at all. Is that some manual contribution declaration? Or did I stumble over another illegal state? Best regards, Marco :-) [Less]

Hello *, already for a while, the developer "chairat" is listed twice on: http://www.ohloh.net/projects/jfire/contributors Once on the first page with more than 900 commits and once on the second ... [More] page with 0 commits. Why that? I first thought, it's a temporary problem while some index data is updated, but the 2nd didn't disappear. Best regards, Marco :-) [Less]

Hi Robin, thanks for your quick reply. We'll probably put the JavaScript code into a zip as a workaround. Our build process can unpack it. That should prevent ohloh to parse it. I'll discuss this ... [More] with the person responsible for this sub-project - I hope zipping is a solution (at least temporarily). Concerning the "choose one" licenses: Do you have multiple parsers (i.e. one searching for each license - not knowing the others) or is it just one parser that searches for multiple things in one pass? In the latter case, it would know that its the same file having multiple licenses and that it therefore must be a choice. But well, I understand that you are very busy... is that part open-source? I guess the people who are directly affected (e.g. fckeditor) might feel some motivation to fix it themselves. Best regards, Marco :-) [Less]