git svn rebase 导致“字节顺序不兼容”错误

发布于 2024-09-07 21:31:30 字数 867 浏览 4 评论 0原文

以下是我在尝试“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

我正在运行的 perl 版本是:

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

当我在网络上搜索“字节顺序不兼容”时,我得到了大量的点击显示 Perl 文档:

这意味着如果您有 由Storable 1.x运行写入的数据 在 perl 5.6.0 或 5.6.1 上配置 Unix 或 Linux 上的 64 位整数 默认情况下此Storable将拒绝 读取它,给出错误字节 顺序不兼容。如果你有 那么你应该设置这样的数据 $Storable::interwork_56_64bit 到 使此可存储读取的真实值 并使用旧标头写入文件。 您还应该迁移您的数据,或者 您正在通信的任何较旧的 Perl 与,到当前版本 可存储。

我不知道的是,如何将这个 '$Storable::interwork_56_64bit' 设置为 true。你能让我知道该怎么做吗?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

棒棒糖 2024-09-14 21:31:30

我开始收到此错误消息。我正在使用位于 Max OS X 分区中的 git 存储库。我有时从 OS X(64 位)访问它,有时从运行 32 位版本 Linux 的虚拟机访问它。看起来有一个缓存文件以与机器相关的格式存储。

经过一番挖掘后,我相信您可以通过清除 .git/svn/.caches 中存储的所有 .db 文件来解决该错误。这应该是比炸掉整个 svn 目录更外科手术的方法。

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.

长伴 2024-09-14 21:31:30

最近我在 Mac 上发生了这种情况。我不确定是什么原因造成的,但是标准 git-svn “修复”删除元数据和更新对我有用:

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

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
...
美羊羊 2024-09-14 21:31:30

我怀疑造成这种情况的一个潜在原因是使用带有 svn 数据的 git 存储库,这些数据在一台计算机上获取,然后存档并下载以在另一台计算机上使用。

就我而言,它是在 CentOS 上获取的,然后移植到 Ubuntu 机器上 - 都是 64 位安装,但也许它们的 Perl 配置的一些小细节是不同的。或者也许软件包更新改变了一些东西。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文