git svn rebase resulted in byte order is not compatible error

Question

Following is the error I am getting when I tried 'git svn rebase':

Byte order is not compatible at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 380, at /usr/lib/perl5/5.10/Memoize/Storable.pm line 21

The version of perl I am running is:

$ perl --version

This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
(with 12 registered patches, see perl -V for more detail)

When I searched the web for "Byte order is not compatible" and I get numerous hits that shows the Perl doc that says:

What this means is that if you have data written by Storable 1.x running on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux then by default this Storable will refuse to read it, giving the error Byte order is not compatible. If you have such data then you you should set $Storable::interwork_56_64bit to a true value to make this Storable read and write files with the old header. You should also migrate your data, or any older perl you are communicating with, to this current version of Storable.

What I don't know is, how to set this '$Storable::interwork_56_64bit' to true. Can you please let me know how to do it?

Answer 1

This happened to me recently on my Mac. I'm not sure what caused it, but the standard git-svn "fix" of blowing away the metadata and updating worked for me:

% mv .git/svn .git/svn.bak
% git svn fetch
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
        .git/svn
        (required for this version (1.7.1) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
Rebuilding .git/svn/refs/remotes/bg-threads-1.1/.rev_map.a5d90c62-d51d-0410-9f91-bf5351168976 ...
r5758 = 545e176a13e87d44a2750ff5f06959088efc9e5b
...

Answer 2

I suspect one potential cause of this is using a git repository with svn data that's been fetched on one machine and then subsequently archived up and downloaded for use on another machine.

In my case it was fetched on CentOS and then transplanted to an Ubuntu machine - both 64-bit installs but perhaps some little detail of their Perl configuration is different. Or perhaps a package update changed something.

Answer 3

I started getting this error message. I'm using a git repository that lives in a Max OS X partition. I sometimes access it from OS X (64 bit), and sometimes access it from a VM that's running a 32 bit version of Linux. It looks like there's a cache file that is stored in a machine-dependent format.

After doing some digging, I believe you can work around the error by blowing away all of the .db files stored in .git/svn/.caches. This should be a slightly more surgical approach than blowing away the entire svn directory.