% svk co //local/typo typo.new
  Syncing //local/typo(/local/typo) in /local/home/dom/public_html/typo.new to 1201.
  zsh: abort (core dumped)  svk co //local/typo typo.new

Thankfully, I can get a sensible stack trace out of it.

  (gdb) bt
  #0  0x2826febf in kill () from /lib/libc.so.6
  #1  0x2826fe5c in raise () from /lib/libc.so.6
  #2  0x2826eb6c in abort () from /lib/libc.so.6
  #3  0x2860fc0b in libintl_recursive_lock_init () from /usr/local/lib/libintl.so.8
  #4  0x2860fc79 in libintl_recursive_lock_lock () from /usr/local/lib/libintl.so.8
  #5  0x2860b6b3 in _nl_load_domain () from /usr/local/lib/libintl.so.8
  #6  0x2860b617 in _nl_find_domain () from /usr/local/lib/libintl.so.8
  #7  0x2860e940 in libintl_dcigettext () from /usr/local/lib/libintl.so.8
  #8  0x2860b37b in libintl_dcgettext () from /usr/local/lib/libintl.so.8
  #9  0x2860b3a0 in libintl_dgettext () from /usr/local/lib/libintl.so.8
  #10 0x28633353 in not_found () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #11 0x2863468b in open_path () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #12 0x28634701 in get_dag () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #13 0x286349ff in fs_node_id () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #14 0x28634a71 in svn_fs_fs__check_path () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #15 0x28322cc5 in svn_fs_check_path () from /usr/local/lib/libsvn_fs-1.so.0
  #16 0x289785e1 in _wrap_svn_fs_check_path (cv=0x87d8dcc) at svn_fs.c:3847
  #17 0x280f6274 in Perl_pp_entersub () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
  #18 0x280ef259 in Perl_runops_standard () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
  #19 0x2809ec3e in perl_run () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
  #20 0x08048fe2 in main ()

I’m guessing that this is gettext related, yet I’ve rebuilt both gettext and subversion to no avail. Drat. This is all on FreeBSD, BTW.

Aha! An insight! This works:

  % LC_ALL=C svk co //local/typo typo.new
  Syncing //local/typo(/local/typo) in /local/home/dom/public_html/typo.new to 1201.
  A   typo.new/test
  A   typo.new/test/unit
  …

Weird and annoying. But at least I can work around that now…

• (pdcawley)++
• (svk)++

I now have the fixed version of typo (soon to be 4.0.2), around an hour after it was committed.

As to the whole “full disclosure” thing by the rails team? They handled it pretty badly. As somebody else commented, it didn’t work for OpenBSD a while back and if anybody could do that, OpenBSD could.

Normally, I track bits of software I might want to hack on in a vendor branch in subversion, and use svn_load_dirs.pl to update to new releases. This works extremely well with wordpress at work, for instance.

Sadly, svn_load_dirs.pl couldn’t cope with the typo trunk, as a directory got replaced by a symlink. Ooops. I tried working around it, but eventually, it was easier to give up and start afresh, redoing the changes I’d already made in subversion. I suppose it would have been a lot easier with SVK.

Unfortunately, a number of things haven’t caught up with the latest typo changes. In particular, the origami theme that I was using needs some loving attention. So it’s back to the default theme, “azure” for the moment, until I can spend some time on it.

Also, I couldn’t figure out how to make the google sitemaps patch work, so that’s another “gone for now” feature.

Please let me know if you spot anything else…

Update: Comments now enabled. Sorry about that.

Update#2: I’ve now fixed the comments feed a bit. It turns out that one of the migrations missed out on creating guids for all the comments…

  % ruby script/console production
  >> comments = Comment.find_all
  >> comments.reject { |c| c.guid }.each { |c| c.create_guid; c.save }

I committed a change on a local copy of a mirror of XML-Genx. I then said svk push and saw the changes go back from the mirror to my master repository. I ran svn update in a working copy attached to the master repository and there were the changes. This rocks. Everybody needs SVK!