Re: [PATCH 3/3] git-svn: use YAML format for mergeinfo cache when possible
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jun 13, 2012, 01:34 UTC
- Message-ID
- <20120613013446.GA3759@burratino>
- In-Reply-To
- <20120609223535.GG28412@burratino>
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.
Show 5 quoted lines
> 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