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
info@openhub.net
BZFlag enlistment is stuck (on download)
BZFlag migrated from CVS to SVN on sourceforge, so we removed the existing CVS enlistment and added our SVN enlistment a few months ago. To date, the enlistment has still not completed and I'm just now getting around to making this request to give it a kick.
I remember there being a thread many months about having to manually accept sf https svn certificates manually, but of course dont' know if that's still an issue or if it's simply because the original enlistment failed and it's just been stuck ever since. We would, however, really like to see the stats back in sync.
BZFlag's enlistment is at http://www.ohloh.net/projects/189/enlistments. As always, thank you very much for your help and for providing such a great resource to the community!
Cheers!
Sean
Hi Sean,
Thanks for asking about BZFlag.
We did download about 80 revisions before failing, so it looks like it was something other than the certificate. I gave it a kick, but it's a huge project (in terms of changes) so it might take a while to download or fail.
Hi Sean,
We're running into a problem with the SVN repository. When doing:
svn checkout https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk@1789
the result is:
svn: Failed to add directory 'trunk/pybzflag/.svn': object of the same name already exists
I get the same thing running this command locally on a workstation in an empty directory.
Hi Andy and.. hrmph. Well, good to know -- thanks. I'm not sure what that error exactly means just yet, but I'll look into it and see if we can't fix whatever is causing that result.
Cheers!
Sean
I've seen this before.
Somehow, someone managed to check the hidden subversion files (.svn folder) into the repository itself. Subversion really doesn't like this because now in order to check out the repository you'd have to overwrite the .svn folder, which isn't permitted.
Administrator tricks might be able to remove the offending files from the repository -- I know of at least one other project that was able to fix this. See this post.
It's a bit of a pain, but we can work around this manually. The workaround is for us to skip ahead to revision 1793, after the mess was cleaned up. That means we'd be missing a few revisions.
Let me know if you can clean up the repository, or whether you want us to skip ahead.
Robin
Robin,
Thanks for the link to that post with the trick to fix our svnroot. Our repository is hosted on Sourceforge so there's a bit of an indirection that I have to work around to get at the svnroot in order to fix the files, but I think that is the way we should go so that it works down the road. It'll just be a while, but I'll post a note here when it's ready for reenlistment.
As for how the .svn dirs got in there -- someone working on code in an local svn repo committed a checkout of their files (including the .svn dirs accidentally, of course) to our CVS repository when it came time to bring it in. CVS of course doesn't care, and when our repository was converted over to SVN, cvs2svn didn't care. The history was actually preserved even though the other svn commands don't like it.
Nice forethought on getting him to report the trick he used so you'd know for others. Given the breadth of details you're seeing across a landscape of thousands of projects, you guys could probably write an interesting book.
Cheers!
Sean
Andy/Robin,
Our SVN root should now be fixed. We applied pretty much the same technique as the Adium guys, except as it applies to a Sourceforge repo. Please give our enlistment another kick and hopefully it should complete this time. I tested with version 1789 and had no problems. Thanks again for pointing out the problem in our repository as well as to the fix! It'll be nice to have our stats online again.
Cheers!
Sean
Hi Sean,
The download has been running well for about an hour now. It looks like we are past the trouble spot, and I'd expect it to finish up sometime late today.
Robin/Andy,
Thank you again so much for your efforts in getting our stats back on-line. Looks like the report took about 12-18 hours total but it did complete and we seem to be good to go now. It's also comforting to know that our root is now repaired
for future operations. We'll probably want to sort out a few incorrect license detections later, but for now I'm quite satisfied and glad to see it tracking project stats again. Let me know where to send the beer.
Cheers!
Sean
Heh, thanks Sean. If only more developers had the grace and wisdom to offer free beer while requesting help.... :-)
I hear you on the license detections. I'm hoping we'll have more hands on the Ohloh code soon, and we'll finally have cycles to drill into this feature and harden it a bit.