4 months ago
We did an SVN move on Synapse when it became a Top Level Project at Apache. Since then your enlistment tool says the project has a short history, but if you look at (e.g) http://svn.apache.org/viewvc/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/Mediator.java?view=log
you will see the project is nearly three years old, not 5 months.
I don't really understand, because the SVN move preserved the history correctly in the SVN log.
4 months ago
Hi pizak,
Our Subversion importer has a pretty serious limitation around moves and branches: it simply cannot follow a directory move. If you rename or branch a directory, Ohloh will lose the trail at that point.
If you fetch the Subversion log using the --stop-on-copy option, you will see your repository the way Ohloh sees it.
I don't think there is any workaround on your end.
This is an old and serious problem for us, and today I'm happy to say that I am working on some code that may improve our position on this matter. A full fix is a long ways off, but we'll get incrementally better at parsing Subversion history as time goes on.
Thanks, Robin
3 months ago
Hi Robin,
The Apache Tuscany project has also graduated and faces exactly the same problem as the Synapse project.
In your post above, you mention that there is work in this area to solve this problem. I was wondering if you could give an update on progress so far.
Thanks for your help,
Mark
3 months ago
The more I think about this problem (and it's an issue for my greenstone project too), the more i think there might be a hack that users can do. Basically the user sets up a mirror of the repo immediately before the move and adds it as a new enlistment. Once it's processed it's deleted (it's only history, so it never needs updating).
Do you have a feel for whether that you work Robin? or would it break other stuff?
3 months ago
@Mark,
There hasn't been any recent progress on the Subversion issue. We've had to put source control improvements on hold while we work on some other (hopefully revenue-generating) features.
@Stuart,
Yes, if there is a mirror of the historical repository prior to the move, Ohloh can process that in order to get the commit history. The only problem is that the code at the "end" of the historical mirror will never be deleted, so the overall code size will be double-counted.
There is a simple feature in here somewhere to mark a repository in a special "historical" state, which could instruct Ohloh to (a) stop trying to sync to the latest commits, and (b) stop counting the code in the total code size. But again, we've sort of put all source control work on hold for now.
Robin