Error using git-svn on existing repository

[uecasm]

This may be because I was previously using msysgit 1.9.5, but I got this error when trying a "git svn fetch" from GfW rc4 on a repository that was initially cloned using 1.9.5:

Checking svn:mergeinfo changes since r53579: 148 sources, 1 changed
Byte order is not compatible at /usr/lib/perl5/core_perl/Storable.pm line 383, at /usr/share/perl5/core_perl/Memoize/Storable.pm line 21.

Could not unmemoize function `lookup_svn_merge', because it was not memoized to begin with at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1634.
END failed--call queue aborted at C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 49.

[uecasm]

Ok, I deleted .git/svn/.caches and that seems to have resolved it. Not sure if there are any adverse consequences to that.

[dscho]

Thanks for the analysis. It seems to be safe to delete .git/svn/.caches, after all it is just a cache and can be reconstructed. I wonder what we can do about this, though. Maybe it is possible to catch that error in git-svn, line 49, and simply remove the caches if a byte order change was detected?

[nalla]

This has to do with the switch from 32bit to 64bit. You have to clear the caches every time you want to use a different bitness.

[dscho]

Oh yes, of course, it is not really bit order but word size... Thanks for pointing that out!

[dscho]

Seems the code in SVN.pm is responsible: https://github.com/git-for-windows/git/blob/v2.4.5.windows.1/perl/Git/SVN.pm#L1597-L1628

Please note that this is probably only a problem if the Storable backend is used, not the YAML one. So maybe there is an easy way to detect with something like

if (-e "$path.db") {
    eval { retrieve("$path.db") }
    unlink "$path.db" unless ($@);
}

in https://github.com/git-for-windows/git/blob/v2.4.5.windows.1/perl/Git/SVN.pm#L1588

NOTE: this is just a sketch of a solution, @uecasm feel free to play with this, as I seem to be unable to find a Subversion repository with which that .caches file is generated (and this ticket does not contain an MCVE either, unfortunately).

[uecasm]

Sorry for the delay. I'm a bit wary of breaking my repo again since it has some important code in it and I wanted to get it safely committed first.

But I tried putting back the old caches folder from v1.9.5 (without applying the suggested fix) and I couldn't reproduce the problem with a git svn fetch or git svn rebase -- the old cache files are still there and have an old date, so I assume that git did not try to read or rewrite them so did not trigger the bug.

I may need to try again later when the SVN repo has had a few more third party commits or something. In case it helps discover what might trigger use of the files, the ones that I have from Git 1 are:

• _rev_list.db
• check_cherry_pick.db
• has_no_changes.db
• lookup_svn_merge.db

And the ones that were recreated by Git 2 (after I had removed the files the first time) were:

• check_cherry_pick2.db
• has_no_changes.db
• lookup_svn_merge.db

Since the original error was talking about lookup_svn_merge.db, I assume that means I'll need to wait for someone else to do a merge in SVN. Shouldn't be too long, this is a fairly busy repository.

(Unfortunately I can't make an MCVE because part of what triggered the migration to GfW 2 in the first place was that the rebase bug is stopping me from running GfW 1 any more.)

[dscho]

Thanks for coming back.

However, I think a bit more from your side will be needed than what you described to be your plan. Please note that it is quite possible with Subversion to initialize your own Subversion repository in a plain old directory! That way, you can experiment with all the operations you suspect are related to this issue, and even better: you can then .zip up the Subversion repository and make an MCVE out of it. Bonus: no meddling with your production system, and neither do you have to frustrate developers willing to help you by stating that they cannot have your repository because there are trade secrets in it.

Note: This is no longer a promise that I will help, but I feel that there is just no chance to motivate anybody else to jump in if they are asked to do all the experimenting themselves.

[uecasm]

I know I can make a local repository. As I said, that's not the problem. The problem is that reproducing the bug requires either that I use the cache files from my existing working copy that previously demonstrated the bug (which requires things to happen in that repository that will probably take a day or two), or that I make a new repo and reproduce the problem -- but the latter would require GfW 1.9 to actually work on my PC (since that's a precondition of the bug, to generate the old-format cache files in the first place), and it simply doesn't. There's not much that I can do about that (rebasing doesn't work). So it's either the waiting game, or see if someone else can reproduce it in the meantime.

[uecasm]

Ok, someone merged something in SVN, so git svn fetch started throwing this error again with the old cache files:

Checking svn:mergeinfo changes since r53912: 152 sources, 1 changed
Byte order is not compatible at /usr/lib/perl5/core_perl/Storable.pm line 383, at /usr/share/perl5/core_perl/Memoize/Storable.pm line 21.

Could not unmemoize function `lookup_svn_merge', because it was not memoized to begin with at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1634.
END failed--call queue aborted at C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 49.

There was a syntax error in the suggested fix, so I had to fiddle with the code a bit, but I eventually got something that appears to work. I'll submit a PR for the specific change in a moment.