Upgrading Subversion
From 1.1 to 1.3
So that we might abandon the Berkley back end and switch to Subversion's own fsfs back end. The Berkely installation has been a constant source of grief, requiring "svn recover" far too often. At least fortnightly, and it needs to be done by someone with root privelege on the repository server which is, of course, me. Always seems to happen on those days when I sank down gratefully for an extra hour or two of sleep.
If they give you root access to one of their servers: do NOT give them your mobile number in return !
Anyway: currently commiting revision 2805, 6, 7, ... in dumping old repository to the new. About 4000 to go. So I reckon I have a few minutes with nowt to do.
Ar an lámh eile, it's not all that different to be working late - it's just unusual to be doing it in the office, that's all.
I did the MSc presentation a few weeks (days? months?) back, and have felt kinda liberated about coding since then. A small idea about debugging in vim has been blossoming over the last few nights.
Later:
Upgrade still slow, but smooth, currently remaking swig. That one was a bitch while upgrading on my own PC: ./configure complained that ..., oh hang on, I did it again.
Bitch. So anyway, upgrade is slower, and less smooth. Currently re-building Subversion, again. You have to do the swig install first, that's what it was.
At least I did get the version right this time. Good rule of thumb for installing from source: Follow the instructions to the letter, and especially to the number. If the Subversion guys say they'll work with swig-1.24, then only use 1.24. 1.27 is not "better", for configure and make: it is not even "as good as".
I do hope the Subversion book is right about the respective crashiness - I'd hate to go through an upgrade like this for no benefit. Still on Subversion, ViewSVN to ViewVC (actually an upgrade, despite the name change), and Roundup still to go.
"Name change" my ... intelligent design !
No, calm down, shouldn't blame the nice people at ViewVC:
Why, oh why, did the intelligent designers at Subversion decide to put their Python modules in /usr/local/lib/svn-python ? What's so terrible about /usr/lib/pythonX.Y/site-packages ? Of course such a non-standard location doesn't show up as an error for subversion itself, just anything else that wants to use it, such as ViewVC. That one cost me over 40 minutes.
And the non-standard fix (simply copy them over to site-packages), will probably cost me another 40 minutes when I do the upgrade from 1.3 to ... Ooh look 1.4 is nearly out, and will be faster. Gotta get it, ...
Bright side: We now have round-trip clicking ! Been trying to get that for a while - I can now see the list of commits on a Roundup issue page, which are linked to the correct revisions/diffs/annotations on ViewVC pages. And on the ViewVC revision pages all the log messages have "issue 999", which links back to the Roundup pages (for two extra lines of code in viewcvs.py)
Oh well, let's try getting Roundup from 0.7.11 to 1.1...
...
Well, that was relatively painless. Especially considering how many connections I've added between Roundup and Subversion. But I did cheat "a bit": I just parked all the new html pages in a temp dir, and restored the old ones. But it works, and I can pick the bits I like from the new html slowly next week. Anyway, I didn't spend 15 months customising that html, just to bring it back to the classic template again.
So, it's four in the morning, and once more the yawning brings out the wanting in me.
... and then one day you realise that the editor you're using can be scripted in the same language you're programming in, and regexps just don't understand such a dynamic language, and you can load the current text as module without saving it, and this is actually fun. I can debug the code before I've saved it. Cool.
If I ever get it good enough to release I shall make sure installation takes minutes, not hours.
Latenight Betty and the Bottle Blondes have started playing. Definitely time for bed.
So that we might abandon the Berkley back end and switch to Subversion's own fsfs back end. The Berkely installation has been a constant source of grief, requiring "svn recover" far too often. At least fortnightly, and it needs to be done by someone with root privelege on the repository server which is, of course, me. Always seems to happen on those days when I sank down gratefully for an extra hour or two of sleep.
If they give you root access to one of their servers: do NOT give them your mobile number in return !
Anyway: currently commiting revision 2805, 6, 7, ... in dumping old repository to the new. About 4000 to go. So I reckon I have a few minutes with nowt to do.
Ar an lámh eile, it's not all that different to be working late - it's just unusual to be doing it in the office, that's all.
I did the MSc presentation a few weeks (days? months?) back, and have felt kinda liberated about coding since then. A small idea about debugging in vim has been blossoming over the last few nights.
Later:
Upgrade still slow, but smooth, currently remaking swig. That one was a bitch while upgrading on my own PC: ./configure complained that ..., oh hang on, I did it again.
Bitch. So anyway, upgrade is slower, and less smooth. Currently re-building Subversion, again. You have to do the swig install first, that's what it was.
At least I did get the version right this time. Good rule of thumb for installing from source: Follow the instructions to the letter, and especially to the number. If the Subversion guys say they'll work with swig-1.24, then only use 1.24. 1.27 is not "better", for configure and make: it is not even "as good as".
I do hope the Subversion book is right about the respective crashiness - I'd hate to go through an upgrade like this for no benefit. Still on Subversion, ViewSVN to ViewVC (actually an upgrade, despite the name change), and Roundup still to go.
"Name change" my ... intelligent design !
No, calm down, shouldn't blame the nice people at ViewVC:
Why, oh why, did the intelligent designers at Subversion decide to put their Python modules in /usr/local/lib/svn-python ? What's so terrible about /usr/lib/pythonX.Y/site-packages ? Of course such a non-standard location doesn't show up as an error for subversion itself, just anything else that wants to use it, such as ViewVC. That one cost me over 40 minutes.
And the non-standard fix (simply copy them over to site-packages), will probably cost me another 40 minutes when I do the upgrade from 1.3 to ... Ooh look 1.4 is nearly out, and will be faster. Gotta get it, ...
Bright side: We now have round-trip clicking ! Been trying to get that for a while - I can now see the list of commits on a Roundup issue page, which are linked to the correct revisions/diffs/annotations on ViewVC pages. And on the ViewVC revision pages all the log messages have "issue 999", which links back to the Roundup pages (for two extra lines of code in viewcvs.py)
Oh well, let's try getting Roundup from 0.7.11 to 1.1...
...
Well, that was relatively painless. Especially considering how many connections I've added between Roundup and Subversion. But I did cheat "a bit": I just parked all the new html pages in a temp dir, and restored the old ones. But it works, and I can pick the bits I like from the new html slowly next week. Anyway, I didn't spend 15 months customising that html, just to bring it back to the classic template again.
So, it's four in the morning, and once more the yawning brings out the wanting in me.
... and then one day you realise that the editor you're using can be scripted in the same language you're programming in, and regexps just don't understand such a dynamic language, and you can load the current text as module without saving it, and this is actually fun. I can debug the code before I've saved it. Cool.
If I ever get it good enough to release I shall make sure installation takes minutes, not hours.
Latenight Betty and the Bottle Blondes have started playing. Definitely time for bed.
posted by Alan at 7:46 p.m.
0 Comments:
Post a Comment
<< Home