Don’t let your branch get stale
If you follow TWIO, you might have noticed that I’ve resurrected the reporting feature that I was working on a while back. There’s a lot of useful management information waiting to be unlocked in the database, and at the moment it’s difficult to do that in a way thats tightly integrated with the rest of OpenNMS.
The general idea is to make the database reporting part of OpenNMS (at the moment, really just the Availability Reports), pluggable. Instead of having just a few reports that are almost impossible to customise, we would like to embed a reporting engine such as BIRT into OpenNMS. This would come with some standard reports, and include the capability for the community to simply add their own.
I’ve been making reasonable progress over the last few weeks (given that I’ve had limited time to work on it), and so I thought that now would be a good time to merge trunk back into the branch I’ve been working on. If only it were that simple.
I’ve had run-ins with svnmerge.py before, but this time was really a hoot. To cut a long story short, never, ever, let your branch get more than a couple of weeks behind trunk. I suspect it’s worse if. like me, you’re at the end of a rural link to the exchange and 1Mbit/s is all you can expect from your DSL circuit. Sourceforge kept resetting my connection during SSL negotiation, necessitating a revert and start again. I got about 5% through the updates from trunk in 2 hours before I threw the towel in. In the end I’ve reverted the changes and gone back to working in splendid isolation.
When the time comes, I’m going to have to merge the old-fashioned way, rather than via svnmerge. Not ideal, but it keeps me working.
So, heed the Old Geezer’s Warning. If you have a feature branch open and you’re using svnmerge, it’s probably best to do a merge weekly, even if you haven’t committed any changes yourself. OpenNMS has a fast moving codebase, infrequent merges could leave you behind.