All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Eric Wong <normalperson@yhbt.net>
Cc: Junio C Hamano <gitster@pobox.com>, Jason Gross <jgross@MIT.EDU>,
	git@vger.kernel.org,
	Sandro Weiser <sandro.weiser@informatik.tu-chemnitz.de>,
	Bdale Garbee <bdale@gag.com>, Andrew Myrick <amyrick@apple.com>,
	Tim Retout <tim@retout.co.uk>
Subject: Re: [PATCH 3/3] git-svn: use YAML format for mergeinfo cache when possible
Date: Tue, 12 Jun 2012 20:34:46 -0500	[thread overview]
Message-ID: <20120613013446.GA3759@burratino> (raw)
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.

> 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

  reply	other threads:[~2012-06-13  1:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-22  2:17 [PATCH] git-svn: Destroy the cache when we fail to read it Jason Gross
2011-08-22  4:04 ` Jason Gross
2011-08-22  4:10 ` [PATCH] Add tests for handling corrupted caches Jason Gross
2011-08-23  2:27 ` [PATCH] git-svn: Destroy the cache when we fail to read it Jonathan Nieder
2011-08-23  2:36   ` Jonathan Nieder
2011-08-23  5:51   ` Jason Gross
2011-08-23  8:15 ` Eric Wong
2011-08-23 17:05   ` Junio C Hamano
2011-08-23 19:58     ` Eric Wong
2012-05-27 19:25     ` [RFC/PATCH] git-svn: use YAML format for mergeinfo cache when possible Jonathan Nieder
2012-05-27 19:48       ` [RFC/PATCH 2/1] fixup! " Jonathan Nieder
2012-05-27 20:14       ` [RFC/PATCH] " Eric Wong
2012-05-28  0:39         ` Jonathan Nieder
2012-05-28  6:57           ` [RFC/PATCH 0/2] git-svn: give SVN::Git::Fetcher its own file Jonathan Nieder
2012-05-28  7:00             ` [PATCH 1/2] git-svn: rename SVN::Git::* packages to Git::SVN::* Jonathan Nieder
2012-05-28  7:03             ` [PATCH 2/2] git-svn: make Git::SVN::Fetcher a separate file Jonathan Nieder
2012-05-29  0:25           ` [RFC/PATCH] git-svn: use YAML format for mergeinfo cache when possible Eric Wong
2012-05-29 20:48             ` Junio C Hamano
2012-06-09 22:20         ` [PATCH v2 0/3] " Jonathan Nieder
2012-06-09 22:25           ` [PATCH 1/3] git-svn: make Git::SVN::Editor a separate file Jonathan Nieder
2012-06-09 22:28           ` [PATCH 2/3] git-svn: make Git::SVN::RA " Jonathan Nieder
2012-06-09 22:35           ` [PATCH 3/3] git-svn: use YAML format for mergeinfo cache when possible Jonathan Nieder
2012-06-13  1:34             ` Jonathan Nieder [this message]
2012-06-10  9:00           ` [PATCH v2 0/3] " Eric Wong
2012-06-10 10:04             ` Jonathan Nieder
2012-06-11 15:06               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120613013446.GA3759@burratino \
    --to=jrnieder@gmail.com \
    --cc=amyrick@apple.com \
    --cc=bdale@gag.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jgross@MIT.EDU \
    --cc=normalperson@yhbt.net \
    --cc=sandro.weiser@informatik.tu-chemnitz.de \
    --cc=tim@retout.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.