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]
Adium svn fetch failed (new enlistment)
I updated the Adium svn address (it had changed), and it appears to have failed to download. I just updated my local checkout from the same address, so I don't think it's a subversion-server-side problem. Thanks!
Hi evands,
Is this the exact same repository as the previous one, stored under a new URL? Or is this an entirely new repository?
The previous Subversion repository has a significant corruption problem which required some careful handling on our part to download. On that repository, it was not possible to check out any revision between 1790 and 4018 (I'm referring to some email I traded with another Adium developer) because someone had checked a hidden .svn directory into the repository itself. You can confirm this yourself by trying to check out one of these revisions:
$ svn checkout -r 1970 svn://svn.adiumx.com/adium/trunk@1790 --ignore-externals
svn: Failed to add directory 'trunk/adium/Plugins/SQL Logger/SQLLoggerPrefs.nib/.svn': object of the same name already exists
We originally managed to import Adium into our system by skipping every revision between 1790 and 4018. This means that our metrics report is incomplete -- we have no history from that time period.
I'm fairly convinced that your new repository is indeed the exact same repository, because our new download failed at the same revision number 1790.
If this is just the same repository stored under a new URL, then I can save some time and headache by simply renaming the code we've already downloaded to match the new URL, thus avoiding the need to completely re-download and re-patch the broken repository.
It's indeed the exact same repository, just moved over to a new server, with a follow-me address (svn.adiumx.com) rather than the server-specific hardcoded one which was being used here before. Let me take a look at an svn dump and see if I can correct the corruption at the source rather than leaving that hack in place, though; corrupted history is no fun at all. If I can't make it right and it's not hard to move the already downloaded code over, that sounds like a great second line of attack.
Thanks for your reply.
Wow, that checkout takes me back a long time. I never thought I'd get nostalgic just from file names.
svnadmin, sed, and I fixed the repository so it should have no problems related to hidden .svn folders (which, incidentally, subversion no longer allows one to add so far as I can tell). Can you try the import normally now please?
Time flies when you're having fun, eh?
I gave our download server another kick this morning, and it looks like the new Adium download is going smoothly. All systems are go for a new report using the cleaned-up repository.
I'm curious what tool(s) you used to fix the repository. When you've downloaded as many Subversion repositories as we have, you find a lot of little things to clean up....
Well, theoretically I would have used svndumpfilter to remove the offending corrupt directories.. except svnadmin as of 1.4.x and 1.5.x creates version 3
dumpfiles, and svndumpfilter for the same versions of the subversion package only supports up to version 2
. Based on reports elsewhere, it looks like svndumpfilter, if you can get it to run, even creates version 3 files... odd.
So I just resorted to good ol' sed. Here's what I ran, with the goal of turning those invalid .svn folders with 'valid' svn folders. Using svndumpfilter, I could have actually removed them.. so as-is, the report data is slightly invalid since modifications of those folders containing .svn will show twice as many lines changes as the .svn
s change, too, I think. Not a big deal.
The lines below are typed here, not grabbed from my bash history or anything, so any that wouldn't work!
bits are not, in fact, indicative of a glitch in the Matrix.
- svnadmin dump /opt/svn/adium > adium.dumpfile
- sed 's/\.nib\/\.svn/\.nib\/svn/' < adium.dumpfile > adium.dumpfile-no-invalid-.svn-folders
- mv /opt/svn/adium /opt/svn/adium-old
- svnadmin create /opt/svn/adium
- svnadmin load /opt/svn/adium < adium.dumpfile-no-invalid-.svn-folders
- mv /opt/svn/adium-old/conf/* /opt/svn/adium/conf
- mv /opt/svn/adium-old/hooks/* /opt/svn/adium/hooks
Once I saw the secret, I smacked my head and said, Of course!
Very cool. I'm sure this will come in handy. Thanks!