Subject: Re: [PATCH 3/3] git-svn: use YAML format for mergeinfo cache when possible

From: Jonathan Nieder <[email-masked]>
Date: Tue, 12 Jun 2012 20:34:46 -0500

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