Merging Subversion Repositories

For a while now I’ve had a number of Subversion repositories that contain more or less related code. They should each, individually, contain less related code than they do, but I find that if I’ve only got a checkout of one of them on some random machine I’m fare more likely to check something into whatever repository I’ve already got checked out than I am to checkout the proper repository. If I later want to move it to the correct repository I lose (or at least scatter all over) any revision history.

Enough of that… for a while I’ve been meaning to merge the repositories together so that even if I don’t have the entire repository checked out and decide to check something in where it shouldn’t be I can later move it within the repository layout and keep the revision history in tact. I’ve figured this should be an easy task to accomplish and now that I’ve finally gotten around to doing it, I was pleasantly surprised to find that it is indeed an easy task to accomplish. Here’s how:

  • shutdown svnserve / block access to the repos / don’t let anyone alter the repos while you’re doing this / whatever
  • from each repos’ parent directory dump each of the repos that you want to merge together into their own dump files using svnadmin dump repos-name > DumpFile-repos-name
  • use svndumptool to merge the repos using a command something like this: svndumptool.py merge -i DumpFile-repos1 -r / /repos1 -i DumpFile-repos2 -r / /repos2 -i DumpFile-repos3 -r / /repos3 -o DumpMerged -d repos1 -d repos2 -d repos3
  • create a new repository somewhere using svnadmin create new-repos
  • load the merged repos into your new repos using svnadmin load DumpMerged
  • Sweet. I love it when things are as simple as they should be… it’s usually a sign of competent designers.

    Add comment August 29th, 2007

    Apache SpamAssassin 3.2.3 released!

    We released Apache SpamAssassin 3.2.3 two weeks ago. So far there have been only a couple people who have indicated they’ve had problems with this release, so I’d say that the current stable branch is back to normal. Along with fixes for things broken in the last couple of releases, 3.2.3 also improves some rules to avoid false positives on ham sent from some Windows Vista mail clients, avoids FP’ing on static clients in the rule RDNS_DYNAMIC, and makes sure that code isn’t run for eval rules when their score is zeroed saving you CPU time.

    2 comments August 27th, 2007

    Apache SpamAssassin 3.2.2 released!

    In our on-going efforts to break something in the stable branch every couple of months, we released Apache SpamAssassin 3.2.2 this week. It fixes a few bugs, including the inability to install SpamAssassin 3.2.1 via CPAN using sudo — at least for some Perl versions on some platforms. On some platforms with some Perl versions, most commonly Perl 5.6.1, spamd might not be able to setuid (ie., drop root privs) and proceed to continuously kill its children when they end up attempting to run as root. So if you want to upgrade to 3.2.2 make sure that you can run “make test” as root before installing the software. If make test as root fails you’d be best off waiting for 3.2.3.

    7 comments July 28th, 2007

    Blocked by Hotmail? Use a Microsoft mail client instead.

    After being told that “SmartScreen technology” had blocked his server from sending mail to Hotmail, this guy found that if he used Outlook 2003, rather than Thunderbird, he could get his mail delivered. Not that you should be surprised by that. It’s not like Microsoft client headers appear in a whole lot more spam than Mozilla headers. Oh wait a second, Microsoft headers do appear in at least half of all spam.

    http://www.theregister.co.uk/2007/06/15/spam_nothotmail/page2.html

    “I started playing around with clients rather than concentrating on server setup, and I’ve had some interesting results. I can send to Hotmail without a problem using Outlook 2003, but no cigar with Mozilla Thunderbird. I think that this suggests that the headers the email clients add to an email also play a crucial role in determining if the mail gets through or not. This is BAD news because as a system admin there is generally very little you can do about this.”

    2 comments June 20th, 2007

    Toronto Colocation Recommendations Anyone?

    I’m currently looking into colocation for a few of my critical services. 1U with 50 GB a month of transfer would be more than sufficient right now, but growth to 100 GB a month within a year would be a good thing to plan for.

    Does anyone have any recommendations for reliable colocation in the Toronto, Ontario area (or the unlikely availability of reliable colocation in the Barrie, Ontario area)?

    If anyone has any suggestions and knows of pricing, please post here or send me an email.

    2 comments June 14th, 2007

    Apache SpamAssassin 3.2.1 and 3.1.9 released!

    We released new versions of SpamAssassin for both the 3.1 and 3.2 branches on Monday. 3.1.9 pretty much just includes the fix for CVE-2007-2873 (which only affects people who using the spamd –allow-tell or -l option) while 3.2.1 has a few additional fixes. Specifically 3.2.1 fixes a bug that caused the included URIBL.com (who are still under a severe DDoS attack, BTW) tests from working along with a handful of things that affect various non-default setups. Some more fixes (for problems most people will never see) to the spamd pre-forking server are also included.

    Unfortunately you can’t successfully run make test as root in 3.2.1 due to the fix for bug 5480. This makes installing SA 3.2.1 via CPAN, um, difficult. I never noticed this since I always build from source as a non-root user. I don’t think any vendors, like RedHat, noticed it either since they probably all do the same thing.

    If you normally install SA via CPAN, my advice would be to stick with 3.2.0 for now, avoid doing anything that triggers the local symlink vulnerability described in CVE-2007-2873 and just run sa-update to get most of the rule fixes included in 3.2.1. I expect that there will be a 3.2.2 release in a month or so.

    Add comment June 13th, 2007

    Determining reel number by reading DTS timecode on 35mm film

    In case you ever find yourself the lucky recipient of a used 35mm print with leaders that may or may not be on the correct reels and with no ID frames to verify which reel is which you would be well served to know how to read the DTS timecode. 99.99% of mainstream film has DTS timecode on it. Some smaller art/other films have it too.

    The last four bits of the 20 bits between mark positions indicate the reel number. Look for a series of frames that the first bit toggles between 0 and 1 and use one of those frames. If you find a frame that has more than one bit difference it’s the title serial number.

    A one is indicated by a transition (a small white dot before or after a slightly longer black spot) while a 0 is indicated by no transition (a long white OR black spot). A sync mark is indicated by the combination of a really long white and black spot.

    Decoded DTS timecode

    2 comments June 8th, 2007

    URIBL, SURBL and Spamhaus suffer SYN floods

    In case you ever needed evidence that URI blacklists are effective or that spammers don’t like Spamhaus, you’ve now got a DDoS SYN flood attack to back up that argument.

    The web mirrors for the three sites have been down for most of the day due to what’s reported by URIBL as “heavy syn floods for anyone operating a web mirror for uribl, surbl, or spamhaus”.

    The SpamAssassin Rules Emporium (SARE) website is also down. It is hosted on one of the URIBL mirrors.

    As of tonight, Spamhaus’ website is back up and running on a new IP.

    I’m really surprised that this didn’t happen a lot sooner.

    Add comment June 6th, 2007

    D-Link DHP-300/301 BoPL adapters = junk

    Maybe I won the SPC challenge and got the bad one, but it’s D-Link so there’s a pretty good chance you could win too.

    One of the D-Link “HD” BoPL adapters that I got for my wireless link to bridge the network between the guy’s house (where the cable connection is) and his garage (where the antenna and radio are mounted) called it quits a couple of weeks ago after 6 weeks of use. When I first got them and plugged them in they ran so hot that I immediately assumed that D-Link’s BoPL adapters are the force behind climate change.

    The thing got so hot that it managed to reflow the solder around the pins of header J2 on the board opposite the one with the heat sink.

    D-Link DHP-300 over heated

    Even ignoring the fact that the thing ultimately failed, it sucked anyway. Typical latencies of 80ms were just acceptable given that it was just a bridge to a cable internet connection, but frequent occurrences over multiple consecutive hours of 3000+ ms latencies just blew. More than once I got pissed off enough waiting that I switched to using my dial-up connection. The problem was probably noise from something, but there was nothing different running off of his electrical panel when it happened. It could have been a neighbor that shares the same transformer, but given that the signal doesn’t seem to make it past where the neutral is bonded to ground I’d hope that they’ve got enough signal headroom to overcome outside noise.

    So with one of the units non-functional (the BoPL side of the unit is non-responsive) I’ve now run some indoor cat5e across the guy’s yard (which is both cheaper at about $10 of cable as opposed to 2 of the $100 DHP-300s and a heck of a lot more responsive with <1ms latencies) until he digs a hole to add onto his house this summer (at which point I’ll bury some outdoor cat5e). I don’t even really have a use for them anymore (nor want to use them anywhere with their sucky 3000+ ms latencies) I’m not even sure if I’m going to bother dealing with getting D-Link to warranty them. Perhaps I can convince them to send me some network cards instead. If you work for D-Link give me a shout!

    In any case, I guess I’ll go back to my assertion that pretty much the only reliable thing that D-Link sells is their DFE-538TX 10/100 PCI network cards.

    28 comments May 30th, 2007

    Apache SpamAssassin 3.2.0 released!

    For those of you who missed it, we released Apache SpamAssassin 3.2.0 on May 2nd after a few RCs and a bit of pestering people to test it out. Most of the bugs people encountered in the final release were with their integration software not adhering to API requirements that haven’t changed in ages. There’s a few other bugs that will be fixed in a soon to be released (I hope) 3.2.1… nothing of major concern to most people that would prevent you from upgrading to 3.2.0 now though.

    Justin Mason outlined a number of key features introduced in 3.2.0 in his posting here. Two other things I’d add off the top of my head are the support of Mail::SPF which is the current SPF reference implementation (it does away with a lot of legacy crude present in Mail::SPF::Query and generally works a lot better) and the new “whitelist_auth” option that allows a user to whitelist a sender that passes any of DKIM, DomainKeys or SPF. It’s basically whitelist_from_dkim, whitelist_from_dk and whitelist_spf all rolled into one. The benefit is that an end-user doesn’t have to know which (or keep track of changes in which) form of email auth a user/domain is using.

    It looks like I was pretty close on calling the release time frame too. In this post, on September 1, 2006, I guessed at late winter or early spring. I went skiing the last week of April and we released during the first week of May. Can’t get much better than that! I just hope I didn’t delay the release on some subconscious level.

    Oh, the newest release of SpamAssassin will catch more spam (than older versions) for you too. Go figure.

    Add comment May 27th, 2007

    Next Posts Previous Posts


    Categories

    Links

    Feeds

    Ohloh profile for Daryl C. W. O'Shea

    LinkedIn

    Apache SpamAssassin