git svn rebase a entraîné une erreur « ordre des octets n'est pas compatible »

Suite est l'erreur que je reçois quand j'ai essayé git svn rebase ':git svn rebase a entraîné une erreur « ordre des octets n'est pas compatible »

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

La version de perl Je suis en cours d'exécution est:

$ 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)

Quand je cherché sur le web pour « ordre des octets n'est pas compatible » et je reçois de nombreux succès qui montre le doc Perl qui dit:

Cela signifie que si vous avez données écrites par 1.x stockable en cours d'exécution sur perl 5.6.0 ou 5.6.1 configuré avec 64 bits entiers sur Unix ou Linux puis par défaut, ce Storable refusera à lire le, en donnant l'erreur Byte ordre n'est pas compatible. Si vous avez de telles données alors vous devez définir $ Storable :: interwork_56_64bit à valeur réelle pour que ce Storable lise et écrire des fichiers avec l'ancien en-tête. Vous devez également migrer vos données, ou tout ancien perl vous communiquez avec, à cette version actuelle de Storable.

Ce que je ne sais pas est, comment placer ce '$Storable::interwork_56_64bit' à vrai. Pouvez-vous s'il vous plaît laissez-moi savoir comment le faire?

Source

2010-06-28 yasouser

Les deux réponses de @ Dave-Goodell et @Jacques fonctionne bien. Mais la méthode proposée par @ Dave-Goodell prend beaucoup de temps surtout si le repo svn est énorme. Dans de tels cas, l'élimination du dossier '.git/svn/.caches' aide. J'ai récemment rencontré le problème. Je ai essayé la réponse de @ Dave-Goodell, mais il a fallu une éternité, donc je l'ai tué. Restauré le dossier '.git/svn' sauvegardé, puis essayé la réponse par @Jacques. Il a résolu le problème dans beaucoup moins de temps. – yasouser

J'ai commencé à recevoir ce message d'erreur. J'utilise un dépôt git qui vit dans une partition Max OS X. J'y accède parfois à partir d'OS X (64 bits), et j'y accède parfois à partir d'une machine virtuelle qui exécute une version 32 bits de Linux. Il semble qu'il existe un fichier cache stocké dans un format dépendant de la machine. Après avoir creusé, je crois que vous pouvez contourner l'erreur en supprimant tous les fichiers .db stockés dans .git/svn/.caches. Cela devrait être une approche un peu plus chirurgicale que de balayer tout le répertoire svn.

Source

2010-10-11 19:03:56 Jacques

A travaillé comme un charme! +1 –

bug de suivi des racines http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587650 –

Cela a également résolu mon dépôt git Windows-> Ubuntu transplanté, mais mon erreur était 'taille de l'entier long n'est pas compatible avec /usr/lib/perl/5.14/Storable.pm ligne 379, dans /usr/share/perl/5.14.2/Memoize/Storable.pm ligne 21 Impossible de démonter la fonction 'lookup_svn_merge ', car elle n'a pas été mémoisée pour commencer par/usr/lib/git-core/git-svn line 3588 END a échoué - la file d'attente d'appel a été abandonnée sur/usr/lib/git-core/git-svn ligne 39. ' C'est perl 5, version 14, subversion 2 (v5.14.2) construit pour x86_64-linux-gnu-thread-multi A pris environ 10 minutes, mais cela peut avoir été le téléchargement exceptionnel de svn. –

Cela m'est arrivé récemment sur mon Mac. Je ne sais pas ce qui a causé, mais le git-svn standard « fix » de souffler loin les métadonnées et la mise à jour a fonctionné pour moi:

% 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 
...

Source

2010-07-22 17:44:30

je soupçonne une cause potentielle de ce utilise un dépôt git avec svn les données qui ont été récupérées sur une machine puis archivées et téléchargées pour une utilisation sur une autre machine.

Dans mon cas, il a été récupéré sur CentOS et ensuite transplanté sur une machine Ubuntu - les deux installations 64 bits, mais peut-être un petit détail de leur configuration Perl est différent. Ou peut-être qu'une mise à jour de paquet a changé quelque chose.

Source

2010-08-25 08:43:45 Adrian

git svn rebase a entraîné une erreur « ordre des octets n'est pas compatible »

Répondre

Questions connexes