Jonathan Nieder wrote: > Unfortunately the format is *not* independent of the perl version --- > new perl versions will write files that very old perl cannot read. True and documented. > Worse, the format is not independent of the size of a perl integer. > So if you toggle perl's use64bitint compile-time option, then using > 'git svn fetch' on your old repositories produces errors like this: > > Byte order is not compatible at ../../lib/Storable.pm (autosplit Weird and contrary to documentation. First, why byte order? Wouldn't the problem be word size, if anything? nstore implies network-endian, after all. Examining the cache file explains it: $ xxd <.git/svn/.caches/lookup_svn_merge.db | head -1 0000000: 7073 7430 0408 0831 3233 3435 3637 3804 pst0...12345678. The byte order is "12345678", which reflects both endianness and word size. Notice that the format is not network-endian. That is because Memoize::Storable ignores the 'nstore' option, for silly reasons: https://rt.cpan.org/Public/Bug/Display.html?id=77790 Ah. (Thanks to Tim Retout for noticing.) Avoiding this arcane and fragile facility when possible still seems to me like a reasonable behavior for git-svn, but it's also nice to see that the problem will eventually fix itself. Sorry for the confusion. And until then, using a renamed cache with a format (YAML) known to be platform-agnostic means git-svn can keep working on repositories that have caches written by unfixed versions of perl. Ciao, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html