Forums : Technical Issue Help
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
Migrating enlistment
The Higgins project has moved its repository from cvs at :pserver:dev.eclipse.org:/cvsroot/technology, org.eclipse.higgins to svn at http://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/
I added the new enlistment and the download steps completed, but none of the new commits from the svn repository were showing up the reports. Thinking it might be a problem with having two enlistments (one to the old repository and one to the new, I deleted the old enlistment. Now commits to the svn repository show up, but only the ones that have happened since we moved repositories (even though we exported/imported in such a way to preserve the old cvs history).
I re-added the cvs enlistment, but the download failed.
Any idea on why the historical commits in the svn repository aren't being seen?
For a start, your import seems to have not been ideal; none of those historical commits were to trunk/, but instead directories have been moved to trunk from outside it, presumably after the import to subversion. Try running 'svn log' on the subversion URL you provide, and you'll see only a handful of commits, which are presumably the ones which are showing up in your report.
Unfortunately, Ohloh has difficulties following subversion moves of any kind, inside trunk/ or not - it's a difficult problem to deal with. I expect one of the Ohloh staff will pop up in this thread to offer their suggestions, I just thought I'd explain the why
of why it's not working right now. :)
Ah, you're right. The import stuffed everything up much higher in the repository, so we had to fix it up.
Hi jimse,
I created an analysis which includes both the CVS and Subversion repostories. However, I believe we are now double-counting the codebase.
The best solution is to convert the entire CVS history into Subversion. Ideally, you could then delete the CVS enlistment from Ohloh, and the new Subversion repository would include everything.
It sounds like this is what you tried to do, but had some hiccups along the way and had to reorganize your directories once everything was in Subversion. Unfortunately, this is death for an Ohloh report, because we are unable to follow directory moves in Subversion. As Alyssa hinted, this is not a trivial problem to solve.
If you get your Subversion log using --stop-on-copy, you will see your repository the way Ohloh sees it.
Until we fix our Subversion troubles, there are a couple of options:
Include both the old CVS repository and the new Subversion repository in the Ohloh report. The total lines of code we display will be wrong, but at least you will have all of your historical commits correctly represented.
Re-migrate your repository from CVS to Subversion in such a way that you don't have to rename your directories afterward. Since you've done new work in this repository since the conversion, this is probably not a reasonable option.
Eventually we do plan to fix the Subversion problem, and then you can just drop the CVS repository from Ohloh and everything should be OK.
I hope I haven't gone on and on with some basic misunderstanding. Let me know if you have more questions.
Robin
Thanks Robin, for looking into this. I think we'll plow ahead with #1 for now. Unfortunately, the people doing the migration are different from the people who run the project, so fixing up the mess seemed easier than re-coordinating a new migration (little did we know).
Maybe we can leave the old CVS repository there, but delete all the source, thus at least returning our LOC to something approximating reality. In any case, we'll be happy to see the svn move issue fixed whenever it is.